Skip to main content

SafariDesk Self-Hosted Architecture

SafariDesk self-hosting runs from the monorepo root using Docker Compose. The default deployment uses one public Nginx entrypoint and keeps the application, database, Redis, WebSocket, and background worker services private inside the Docker network. Related pages:

Deployment Model

The consolidated repository contains both application codebases:
  • frontend/ contains the Vite React frontend.
  • backend/ contains the Django backend, API, Channels server, Celery app, and migrations.
  • deploy/nginx/ contains reverse proxy routing.
  • deploy/scripts/ contains maintenance scripts.
  • docs/self-hosting/ contains deployment documentation.
The self-hosted deployment is started from the repository root:
The root docker-compose.yml defines all required services.

Docker Services

SafariDesk uses eight Compose services by default. Only nginx publishes a host port by default. Application images:
  • Frontend image: safaridesk/safaridesk-frontend
  • Backend image: safaridesk/safaridesk-backend
Infrastructure images:
  • Nginx: nginx:1.27-alpine
  • PostgreSQL with pgvector: pgvector/pgvector:pg16
  • Redis: redis:7-alpine

Architecture Diagram


Public and Private Network Boundaries

Public by default:
  • nginx on ${HTTP_PORT:-80}
Private inside Docker Compose:
  • frontend:80
  • backend:8100
  • channels:8101
  • db:5432
  • redis:6379
  • worker
  • beat
Do not expose PostgreSQL, Redis, the backend API port, or the Channels port directly to the internet.

Routing

The default self-hosted deployment uses same-domain routing. Same-domain routing is the recommended default because it avoids most CORS, CSRF, WebSocket origin, and upload URL problems.

Storage

SafariDesk uses Docker volumes for persistent and shared data. The backend media root is configured through:
Uploads must persist across container restarts, image updates, and application upgrades.

Database

The db service uses:
The backend connects to PostgreSQL using:
The database service is internal only. Backups should be created with the scripts in deploy/scripts/.

Redis, Celery, and WebSockets

Redis is used by:
  • Celery worker queueing
  • Celery result backend
  • Django Channels
  • Backend cache features where configured
The default Redis service is:
Runtime services:
  • channels runs Daphne for WebSockets.
  • worker runs Celery workers.
  • beat runs Celery Beat scheduled tasks.
These services use the same backend image as the Django API but run different commands.

Environment Files

Self-hosting uses one root .env file. Start from:
Important environment groups:
  • App identity
  • Docker image namespace and tag
  • Domains and URLs
  • Security
  • Database
  • Redis and Celery
  • Email and SMTP
  • Admin bootstrap
  • OAuth and mail integrations
  • Integrations
  • AI providers
  • Billing and licensing
  • Optional ports
See Configuration for the full variable reference.

Docker Image Strategy

SafariDesk publishes two application images:
The backend image is reused by four services:
  • backend
  • channels
  • worker
  • beat
The image namespace and tag are controlled by:
For production, pin SAFARIDESK_IMAGE_TAG to a released version instead of using latest. See Docker Images and Releases for release and tag details.

Health Checks

Compose health checks are configured for:
  • nginx
  • frontend
  • backend
  • db
  • redis
The backend health check calls:
Nginx waits for the backend health check before treating the backend dependency as ready.

Licensing

The environment file includes licensing settings:
Licensing behavior depends on the edition, deployment type, and configured license server. Document final license server URLs and entitlement behavior here before publishing the official production docs. Placeholder license links:

Production Notes

For production deployments:
  • Use a Linux host.
  • Keep only ports 80 and 443 public.
  • Put TLS in front of Nginx or extend the Nginx deployment to terminate TLS.
  • Pin Docker image tags.
  • Use strong secrets in .env.
  • Back up postgresdata and uploads.
  • Run migrations after upgrades.
See Production Deployment and Backup and Restore.