SafariDesk Production Deployment
This page covers production deployment for the Docker Compose setup in the monorepo root. Use Installation first for the base install. Use this page before exposing SafariDesk to real users. Related pages:- Architecture
- Configuration
- Docker Images and Releases
- Update Guide
- Backup and Restore
- Troubleshooting
Recommended Production Model
Recommended:- The host, cloud load balancer, or external reverse proxy terminates TLS.
- The SafariDesk
nginxservice receives HTTP traffic from that trusted layer. - Internal services remain private inside Docker Compose.
HTTPS_PORT value exists in .env.example for future TLS deployment patterns, but the current root Compose file does not publish 443 by default.
Host Requirements
Minimum:- Linux server
- Docker Engine
- Docker Compose plugin
- 4 GB RAM
- 20 GB disk
- Port
80available
- Ubuntu 22.04 or newer
- 8 GB RAM
- 4 CPU cores
- 50 GB or more disk for database, uploads, logs, and backups
- Domain name
- TLS certificate
- Automated backups
- Monitoring for disk, memory, CPU, and container restarts
DNS
Same-domain deployment needs one DNS record. Example:Firewall Rules
Public inbound:
Do not expose these service ports publicly:
Check published ports:
safaridesk_nginx should show a host port by default.
Production Environment
Set production values in.env.
Example same-domain values:
Start Production Services
Pull images:always for core services.
Run migrations:
TLS
The current Compose setup does not terminate TLS inside the SafariDesk Nginx container. Use one of these production patterns:- Host-level reverse proxy terminates TLS and forwards to
localhost:${HTTP_PORT}. - Cloud load balancer terminates TLS and forwards to the server.
- Future Compose TLS profile mounts certificates into Nginx.
.env URLs should use https://.
Volumes and Persistence
Production data lives in Docker volumes:
At minimum, back up:
- PostgreSQL database
uploadsvolume.env
Backup Before Real Usage
Create a first backup after installation:Operational Checks
Check containers:WebSocket Verification
WebSockets are routed through:Security Checklist
DEBUG=falseSECRET_KEYchangedSECRET_ENCRYPTION_KEYchangedDB_PASSWORDchangedSUPERUSER_PASSWORDchangedALLOWED_HOSTSis not*CORS_ALLOW_ALL_ORIGINS=falseCORS_ALLOWED_ORIGINSmatches the public app URLCSRF_TRUSTED_ORIGINSmatches the public app URL- PostgreSQL is not publicly exposed
- Redis is not publicly exposed
- Backend port
8100is not publicly exposed - Channels port
8101is not publicly exposed - Docker socket is not mounted into backend containers
- Image tag is pinned
- Backups are configured
Production Deployment Checklist
- DNS points to the deployment host.
- TLS is configured.
.envcontains production URLs..envcontains production secrets.docker compose config --quietpasses.docker compose pullsucceeds.- Containers start.
- Migrations run.
- Static files collect.
- Admin user exists.
- Frontend loads.
- API health route works.
- WebSockets work.
- Uploads work.
- Celery worker starts.
- Celery Beat starts.
- Email settings are tested.
- Backup and restore have been tested.

