Dattavani Backend: Deployment Diagram

Production deploy, step by step

The release owner runs Deploy Backend Production by hand. Merging does not deploy.
The job builds core-service and pushes :<sha> and :production-latest to the registry.
It runs terraform apply, then SSHes into every droplet tagged dattavani-production.
On each droplet it rewrites .env.production, pulls :production-latest and restarts the container.
Droplets restart one at a time with a 5 s pause and no health check (deploy-production.yml:133-135).

Runtime path

api.dattavani.ai hits a global load balancer with a Let's Encrypt cert and a /health check.
It forwards to the blr1 or nyc1 internal load balancer, then to port 8000 on a droplet.
On the droplet, Caddy blocks /docs, /redoc and /openapi.json, then proxies to core-service.
core-service runs with 2 CPUs, 3 GB and one uvicorn worker (Dockerfile CMD).
Pools autoscale at 60% CPU: blr1 3 to 6 droplets, nyc1 2 to 6.

Staging is a different setup

Deploy Backend Staging copies the repo to a VPS over password SSH and runs docker compose.
There core-service runs 4 workers behind Caddy at dev.dattavani.ai, and /docs stays open.
terraform-staging (staging.dattavani.ai) is not run by any workflow. It owns the registry and the SSH key production reads.

Secrets (names only)

Production: [redacted], [redacted], [redacted], [redacted], [redacted], [redacted], [redacted], [redacted], [redacted].
Staging: CORE_SERVICE_ENV, VPS_HOST, VPS_PORT, VPS_USER, [redacted], VPS_TARGET_DIR.
docs/deployment.md does not list [redacted] or [redacted], but the workflow needs them.

Before you deploy

Apply new migrations to Supabase first. No workflow runs them (docs/deployment.md:25).
Cleanup keeps only the 3 newest images, so an older SHA cannot be redeployed. docs/deployment.md:49 says otherwise.
Terraform puts [redacted] and the DO token in droplet user_data (compute.tf:103-106, 128). Guard the state bucket.
The firewall opens SSH port 22 to the whole internet (firewall.tf:13-18).