Load secrets from AWS SSM Parameter Store via chamber at container boot

[nbudin]

Purpose

Managing secrets that come from Terraform outputs (AWS access keys, S3 bucket name, etc.) has always been a manual step — someone has to run flyctl secrets set after a terraform apply. This closes that gap.

The approach is a thin entrypoint script that conditionally runs chamber before starting the app. If CHAMBER_SERVICE is set, chamber loads all SSM parameters under that path as environment variables before exec-ing the real process. If it's not set, the script is a no-op — the app boots normally. This means operators running their own Intercode instances aren't affected at all.

On the Terraform side, the intercode_aws_resources module now writes the secrets it produces (IAM access keys, S3 bucket name, region) to SSM automatically, adds a secrets variable for the manually-managed ones (DATABASE_URL, Stripe keys, etc.), and grants the app's IAM user permission to read from its own SSM path. The existing IAM user the app already uses for SQS/SES/S3 gets the SSM permissions, so no new credentials are needed.

Changes

💻 Engineer-facing

• bin/entrypoint.sh: conditional chamber wrapper; CHAMBER_SERVICE unset = passthrough, set = SSM load then exec
• Dockerfile: installs chamber binary (multi-arch), wires up ENTRYPOINT, pins version via ARG CHAMBER_VERSION
• fly.toml: adds CHAMBER_SERVICE = "intercode_production" (update this to match your var.name if different)
• terraform/modules/intercode_aws_resources/ssm.tf: SSM parameters for Terraform-derived secrets (auto-populated) and var.secrets map (caller-provided)
• terraform/modules/intercode_aws_resources/iam.tf: adds ssm:GetParametersByPath/GetParameter/GetParameters to the app's IAM group policy
• New outputs: chamber_service, ssm_path_prefix

Risks

The Terraform changes are additive — new SSM parameters and a new IAM policy statement — so they won't affect existing deployments until CHAMBER_SERVICE is set and the secrets variable is populated. The entrypoint script is a no-op unless CHAMBER_SERVICE is present, so this is safe to deploy before the Terraform side is wired up.

The chamber version is pinned at 2.13.4 — worth verifying that's current before the first build.

Release plan and notes

Deploy the app change first (harmless since CHAMBER_SERVICE is now in fly.toml but SSM parameters don't exist yet — chamber will fail to start). Actually: populate the SSM parameters via terraform apply before deploying, then remove the corresponding Fly secrets once confirmed working.

🤖 Generated with Claude Code