Description
When ADMIN_DATABASE_URL (Apollo) or THERMOS_ADMIN_DATABASE_URL / THERMOS_WORKER_ADMIN_DB (Thermos) are not present in Doppler, migration jobs now generate a short-lived RDS IAM auth token for the postgres master user instead of requiring a stored password.
Logic per migration step:
- Env var set → use it as-is (no change in behaviour)
- Env var unset + IAM credentials available →
aws rds generate-db-auth-token → URL-encode token → build connection URL on the fly
- Env var unset + no IAM credentials → fail fast with a clear error
Why IAM-only makes sense here:
- Production migration jobs run on the
self-hosted runner (EC2), which already has an instance profile — no credentials to store or rotate
- The
postgres master user has rds_iam granted and its password has been rotated to an unknown value
- Token is ephemeral (15 min), generated inside the
doppler run subshell and never written to disk or logs
Scope:
.github/workflows/apollo_migrations_and_deploy.yaml — wraps the make migrate call
.github/workflows/thermos_prod_docker_and_deploy.yaml — wraps both registrydb and workerdb Atlas steps
Staging is unaffected: staging uses ubuntu-latest (no instance profile), so ADMIN_DATABASE_URL must still be set in Doppler for staging — the aws sts get-caller-identity check will fail and the step errors out clearly.
How did I test this PR
- Reviewed the diff against both workflow files
- Confirmed the
aws sts get-caller-identity guard correctly gates the IAM path
- The fallback is additive — existing Doppler env vars continue to take precedence with zero change in behaviour
🤖 Generated with Claude Code