Production readiness — Section 7: Secrets and Application Configuration

Update 2026-08-25: Resolved for Production — adopted the SSM Parameter Store pipeline (deploy/secrets.sh) from day one rather than repeating staging's hand-provisioned/partial setup. All 6 secrets now live in /musehub/production/* as KMS-encrypted SecureString parameters; secrets.sh runs end-to-end and regenerates .env correctly. Migration itself never exposed a secret value outside the instance — a temporary write policy was granted, used once, then removed and replaced with the correct least-privilege read-only policy.

Staging remains at 3-of-7 parameters in SSM — completing that is a reasonable follow-up but wasn't required to answer this ticket's open question (which pipeline should production use). Answer: SSM, from day one.

Completed the actual work item — staging secrets migrated to SSM, pipeline proven end-to-end.

Found and fixed a real gap along the way: staging's instance role had zero SSM Parameter Store permissions at all (only agent connectivity + ECR pull) — secrets.sh would have failed even with all parameters populated. Added a scoped read-only policy matching production's pattern.

Migrated the 4 missing parameters without exposing any value: temporarily granted the instance role write access, ran the migration entirely server-side (read .env, write to SSM, all on the instance), then revoked write access immediately — same discipline used for R2 credentials earlier in the project.

Ran deploy/secrets.sh for real against staging (not just confirmed it exists) — fetched all 7 parameters, wrote a fresh .env, passed its own sanity check, confirmed staging stayed healthy. Staging and production now have an identical secrets pipeline.

Remaining work (log-leak review, WORKER_INTERNAL_KEY audit, rotation policy) split to #177.

Closing.