Docker Deployment

Docker Compose is the recommended way to run RedCloud on a single host.

What Compose runs

The root docker-compose.yml defines four services:

Service	Image / build	Published port
`postgres`	`postgres:16-alpine`	`${DB_PORT:-5432}`
`redcloud`	builds `Dockerfile` (backend + frontend)	`${PORT:-9900}`
`license-server`	builds `Dockerfile.license`	`${LICENSE_PORT:-7700}`
`scheduler`	builds `scheduler/Dockerfile`	none

Each service has a health check (pg_isready, curl /health, curl /, and a process check for the scheduler). Persistent data uses a named pgdata volume, scan output is mounted from ./out, and cloud credentials are mounted read-only from ./credentials.

Deploy

# 1. Configure environment
cp .env.example .env
#    edit .env — set HMAC_KEY, API_KEY, ENCRYPTION_KEY, DB_PASSWORD, license, etc.

# 2. Provide cloud credentials
mkdir -p credentials
#    place your GCP service-account key at credentials/sa-key.json

# 3. Start
docker compose up -d
docker compose logs -f

# Stop (keep data):
docker compose down
# Stop and delete the database volume:
docker compose down -v

Open http://<host>:9900 once the redcloud health check is passing.

Images

Dockerfile — multi-stage: a node:20-alpine stage builds the frontend, a python:3.12-slim stage installs the gcloud CLI and Python dependencies, copies the built frontend into the backend’s static directory, runs as a non-root redcloud user, exposes 9900, and starts uvicorn api.app:app with two workers. The start command honors a dynamic $PORT (so it runs on Cloud Run unchanged).
Dockerfile.production — a hardened variant that compiles the Python to bytecode and ships .pyc only (no source). Runtime behavior is identical.
Dockerfile.license — the standalone license server on 7700.

Health, metrics, and operations

Endpoint	Purpose
`GET /health`	Liveness (used by the container health check)
`GET /health?deep=true`	Database, disk, gcloud, and security-posture diagnostics
`GET /metrics`	Prometheus metrics
`GET /api/versions`	API version info

Back up PostgreSQL on a schedule (the deployment runbook suggests a nightly backup.sh cron) and restore with the provided restore script.