feat(deploy): wire staging DATABASE_URL through SSM, retire orphaned self-hosted Postgres
Phase 1 of the database migration plan (docs/database-architecture.md):
- deploy/secrets.sh now fetches an optional DATABASE_URL override from SSM (/musehub/<env>/DATABASE_URL). When present it wins verbatim -- this is how staging's managed RDS instance gets wired in. When absent, falls back to constructing the self-hosted URL from DB_PASSWORD, matching setup-ec2*.sh's original pattern. This also fixes a previously-unknown general gap: secrets.sh never wrote DATABASE_URL at all before this change, for either environment -- every working value came only from setup-ec2*.sh's one-time initial .env write and would silently vanish the next time secrets.sh ran.
- Added /musehub/staging/DATABASE_URL as a real SSM SecureString, extracted from the live container and written via a temporary, narrowly-scoped IAM grant on the instance role (revoked immediately after) -- the value never transited a local shell.
- Redeployed staging for real: migrations ran against RDS, schema gate passed (73 tables in sync), health check passed. Verified live via /healthz.
- Removed the now-orphaned musehub_postgres, musehub_runner containers and musehub_postgres_data volume from the staging instance.
- Verified RDS baseline hardening: PubliclyAccessible=false, security group scoped to VPC CIDR only, DeletionProtection=true, 7-day automated backups. Found one real gap: StorageEncrypted=false (can't be fixed in place on an existing instance; tracked as a Phase 1 follow-up, and to be avoided by provisioning production's instance encrypted from the start in Phase 2).
Semantic Changes
7 symbols
Files Changed
~2
1061 in snapshot
0 comments
muse hub commit comment sha256:6b17aab7bbd46a2cde5a226d9d17e4251b8bf85353e899875786626cf000e350 --body "your comment"
No comments yet. Be the first to start the discussion.