Linux Docker Compose Deployment
Linux Docker Compose is the preferred DeskDox production deployment model for customer-managed infrastructure.
Deployment Position
This model is fully supported by the repository production compose baseline. It is appropriate for dedicated Linux servers, enterprise VMs, VPS deployments, and private-cloud hosts where the customer can control storage, DNS, firewall, TLS, backup, and monitoring.
Production Compose Baseline
The root production compose file defines:
| Service | Image / runtime | Persistent data |
|---|---|---|
postgres | postgres:16 | /srv/edms/volumes/postgres:/var/lib/postgresql/data |
gotenberg | gotenberg/gotenberg:8 | Stateless conversion service. |
backend | ghcr.io/dev-saifar/edms-backend:${IMAGE_TAG:-latest} | Uploads, previews, FAISS, backups, licensing. |
preview-worker | Same backend image | Uploads, previews, FAISS, backups, licensing. |
index-worker | Same backend image | Uploads, previews, FAISS, backups, licensing. |
frontend | ghcr.io/dev-saifar/edms-frontend:${IMAGE_TAG:-latest} | Static runtime container. |
The backend startup command applies Alembic migrations before starting Uvicorn. This means deployment windows must allow for schema migration review and backup/rollback planning.
Host Preparation
The customer should provision:
- Linux server or VM with agreed CPU/RAM/storage sizing.
- Docker Engine and Docker Compose v2.
- Durable SSD-backed storage for
/srv/edms/volumes/...or approved equivalent paths. - Restricted administrative access.
- DNS and TLS endpoint strategy.
- Monitoring for CPU, memory, disk, Docker service state, and backup success.
Persistent Directories
The production compose baseline uses:
| Host path | Container path | Purpose |
|---|---|---|
/srv/edms/volumes/postgres | /var/lib/postgresql/data | PostgreSQL data. |
/srv/edms/volumes/uploads | /app/files | Uploaded document binaries. |
/srv/edms/volumes/previews | /app/data/previews | Preview artifacts. |
/srv/edms/volumes/faiss | /app/data/faiss | Search, RAG, and index artifacts. |
/srv/edms/volumes/backups | /var/lib/deskdox/backups | Backup output. |
/srv/edms/volumes/licensing | /var/lib/deskdox/licensing | Licensing state. |
These paths must be included in capacity planning and backup design.
Implementation Notes
Commands are provided here for deployment engineers and should be adapted to the customer’s approved process.
cp .env.prod.template .env.prod
docker compose -f docker-compose.prod.yml --env-file .env.prod config
docker compose -f docker-compose.prod.yml --env-file .env.prod up -d
docker compose -f docker-compose.prod.yml --env-file .env.prod ps
Health validation should include the frontend endpoint, backend health API, container health status, and representative application smoke tests.
Linux Acceptance Criteria
| Area | Expected result |
|---|---|
| Service startup | All six production services are running and healthy. |
| Persistence | Required host paths exist, are writable, and survive container replacement. |
| Public endpoint | Users access DeskDox through the approved FQDN and TLS endpoint. |
| Internal isolation | Database, converter, backend direct port, and workers are not publicly exposed. |
| Application validation | Login, upload, preview, search/OCR, workflow, email, backup, and audit tests pass. |
| Handover | Image tag, environment location, data paths, backup path, and support owners are documented. |
Production Caveats
The Linux compose model is single-host by default. Two-tier, three-tier, and HA designs require separate design review for shared storage, database operations, worker concurrency, file locking, backup/restore, and network exposure.