Self Hosting Revision

Self-hosting allows Revision to run entirely on an organization’s own infrastructure, without any external dependencies or required internet access.

The complete application, database, and background processing operate within the organization’s network and environment.

Self-hosted overview

• Deploys Revision using standard Docker containers on any infrastructure capable of running containers.
• Access to images from Revision image repository (ghcr.io/revision-org ).
• Stores all data — including diagrams, models, attachments, and logs — locally within the organization’s environment.
• Does not require any connection to revision.app  or other external services once deployed.
• Places responsibility for updates, backups, monitoring, and scaling with the organization’s IT operations.

Self-hosting provides full ownership of data, security, and operational control, making it suitable for environments with strict compliance, data residency, or offline requirements.

Requirements

A self-hosted deployment of Revision requires a container-capable environment and access to a few supporting services.

The setup is lightweight and can run on a single host or be distributed across multiple nodes, depending on scale and internal policies.

Specifications

• Container runtime: Docker Engine or a compatible runtime (e.g., Podman, containerd, OpenShift, Azure Container Apps, or Kubernetes).
• Compose or orchestration tool: Docker Compose (v2+) or equivalent orchestration support.
• Storage: Persistent storage volumes for database, attachments, and generated files.
• Network access: Internal network connectivity between all containers. Internet access is optional but recommended for image updates.
• PostgreSQL 14: Used as the main database. A standard Docker image or managed Postgres service can be used.
• SMTP server: Required for sending transactional emails such as password resets and invitations.
• Reverse proxy / SSL: An HTTPS endpoint for secure external access.
• Access to Revision container registry: Credentials to pull official images from ghcr.io/revision-org .

Architecture Overview

A self-hosted Revision deployment is composed of a small number of containerized services that together provide the full application stack.  

Each service runs independently but communicates over the internal network defined by the container runtime or orchestrator.

Core Components

Data Persistence

A self-hosted Revision deployment relies on persistent storage to ensure that data remains available across container restarts, upgrades, or host reboots.  

Persistent volumes are used to store critical application data, database content, and generated files.

Backup Recommendations

• Database backups: Use standard PostgreSQL tools such as pg_dump  or pg_basebackup .
• File storage backups: Regularly archive the attachment-data and image-data volumes.

Updates and Upgrades

Self-hosted installations of Revision can be updated by pulling the latest container images from the Revision image registry and restarting the stack.

Updates are typically backward compatible, and database migrations are applied automatically on startup.

Versioning

• Revision images are tagged with semantic versions (e.g., ghcr.io/revision-org/revision-app:1.12.3 ).
• The latest  tag always points to the most recent stable release.
• For production environments, pin specific versions in your compose or orchestration configuration to ensure controlled rollouts.

Environment Variables

Environment variables control how each container in a self-hosted Revision setup behaves.

Most configurations can be kept as defaults, but database, mail, and internal URLs must be adjusted for your environment.

revision-app

revision-worker

revision-db