Stratum guide

Deploy the containers

Choose the all-in-one image or separate UI and backend images, then set production runtime boundaries.

Stratum publishes multi-architecture images for linux/amd64 and linux/arm64. Docker normally selects the correct manifest automatically.

All-in-one deployment

The all-in-one image delivers the compiled UI, API, WebSocket endpoint, and health endpoints on port 8080. For a persistent deployment, prepare PostgreSQL and apply migrations before starting the application.

export STRATUM_VERSION=<release-tag>

docker pull ghcr.io/chaosphere-apps/stratum-allinone:$STRATUM_VERSION

docker run --rm \
  -e MIGRATION_DATABASE_URL="$MIGRATOR_DATABASE_URL" \
  --entrypoint /migrate \
  ghcr.io/chaosphere-apps/stratum-allinone:$STRATUM_VERSION status

docker run --rm \
  -e MIGRATION_DATABASE_URL="$MIGRATOR_DATABASE_URL" \
  --entrypoint /migrate \
  ghcr.io/chaosphere-apps/stratum-allinone:$STRATUM_VERSION up

docker run --rm \
  -e MIGRATION_DATABASE_URL="$MIGRATOR_DATABASE_URL" \
  --entrypoint /migrate \
  ghcr.io/chaosphere-apps/stratum-allinone:$STRATUM_VERSION check

status is read-only. up applies ordered, transactional migrations under a PostgreSQL advisory lock. check exits unsuccessfully when migrations are pending or unknown and should gate the application rollout.

docker run -d \
  --name stratum \
  --restart unless-stopped \
  -p 8080:8080 \
  -e DATABASE_URL="$APP_DATABASE_URL" \
  -e AUTO_MIGRATE=false \
  -e PUBLIC_URL='https://stratum.example.com' \
  -e ALLOWED_ORIGINS='https://stratum.example.com' \
  ghcr.io/chaosphere-apps/stratum-allinone:$STRATUM_VERSION

Separate services

Use stratum-ui and stratum-backend when your platform operates static delivery and API workloads independently. Keep one public origin: route /api/* and WebSocket upgrades for /ws to the backend on port 8081, and route /* to the UI on port 8080.

/api/*  -> stratum-backend:8081
/ws     -> stratum-backend:8081 (WebSocket upgrade)
/*      -> stratum-ui:8080

Database and runtime boundaries

Use a managed PostgreSQL 16 or 17 service with TLS verification, encrypted storage, automated backups, point-in-time recovery, and tested restoration. Use a schema-owning migration role only for the migration job and a separate application role for normal DML.

Production checklist

  • Pin one release tag and use it for both migrations and application containers.
  • Set AUTO_MIGRATE=false after /migrate check succeeds.
  • Terminate TLS at a trusted ingress, reverse proxy, or load balancer.
  • Set PUBLIC_URL and ALLOWED_ORIGINS to the externally visible HTTPS origin.
  • Configure TRUSTED_PROXY_CIDRS when forwarding metadata comes from trusted proxies.
  • Keep secrets in your platform secret manager, not image layers or source control.
  • Configure Okta redirect URIs using the public HTTPS URL.
  • Use /healthz for liveness and /readyz for traffic readiness.
  • Smoke-test sign-in, design save, versions, reviews, and WebSocket reconnect after deployment.

Starting point for about 150 employees

Begin with one Stratum application replica at 2 vCPU and 2–4 GB memory, backed by managed PostgreSQL at 2–4 vCPU and 4–8 GB memory. Set the application pool around 20 maximum and 2 minimum connections, then tune from measured concurrency, query latency, and saturation rather than employee count.

Alert on HTTP error rate, readiness failures, database connection saturation, slow queries, locks, storage growth, and backup failures. Load-test representative large designs and simultaneous review sessions before company rollout.