Deploy a Rails App With SSM and Docker

What this flow is

This playbook describes a git-based continuous deployment (CD) to a
shared Docker host, orchestrated entirely by AWS Systems Manager (SSM)
— no SSH keys, no bastion, no interactive shell.

The mental model is simple:

push to main
  -> CI (audit + lint + tests) goes green
    -> deploy job authenticates to AWS
      -> aws ssm send-command (AWS-RunShellScript) on the instance
        -> on the host: git fetch/reset --hard + docker compose up -d --build
          -> healthcheck (curl /up)

Why SSM instead of SSH

• No inbound port 22. The instance never exposes SSH to the internet;
  SSM connects through the SSM agent outbound. Smaller attack surface.
• No long-lived key to leak. GitHub Actions authenticates to AWS with a
  short-lived credential (OIDC role) and is authorized to run exactly one
  command document on exactly one instance.
• Auditable. Every deploy is an SSM command invocation with logs in
  CloudWatch — you get a per-deploy record for free.

When to use this

• You have one shared host running several small apps behind a shared
  network, Postgres and Redis. You want to add one more app without
  standing up new data services or a full orchestrator (ECS/K8s).
• You want deploys to be a side effect of merging to main, not a manual
  ritual.

When NOT to use this

• You need blue/green or zero-downtime rollouts across many replicas — reach
  for ECS/K8s. This flow recreates a single container and has a brief gap
  while the new container boots.

The steps below build the flow from the ground up: the deploy compose file,
secrets on the host, the CD job that fires the SSM command, migrations on
boot, verification (with a timing gotcha), and rollback.