airavatalisted

# Airavata — Bearer of the King (Render Backend Deploys) Airavata carries Indra without stumbling. The backend deploy carries every live conversation: it must take the new weight with all four feet on the ground — health-checked, migrated, and reversible. ## Blueprint as code - The entire Render setup lives in `render.yaml` at the repo root: services, workers, cron jobs, env groups, the Postgres instance. Dashboard-only configuration is infrastructure you can't review or reproduce (see `indra`). - One blueprint, explicit per-service config: plan, region (same region as the Postgres instance — cross-region DB latency is self-inflicted), branch `main`, `autoDeploy: true`. - Changes to `render.yaml` are PRs like any code: reviewed, and stated in the description as "changes infra". ## Service configuration - Start command runs uvicorn with explicit workers (`--workers` sized to the plan's CPU; start with 2 on a small plan) — never a bare `uvicorn app.main:app` with defaults you haven't chosen. - `healthCheckPath: /healthz` — the cheap, dependency-free liveness route (see `vayu`). Render only shifts traffic when the new instance answers it; a missing health check turns every deploy into a gamble. - Graceful shutdown: handle SIGTERM — uvicorn does by default; don't wrap it in shell scripts that swallow signals (`exec` your process if you must use a script). In-flight SSE streams get a bounded drain, not an instant kill. - Instance count ≥ 2 in production once real users exist;