Migrate a Rails app to AWS: the architecture, Sidekiq, and the database cutover.

IWhy move a Rails app to AWS

Most Rails apps arrive at AWS from Heroku. The move is triggered by cost, by platform limits, or by requirements Heroku does not meet.

Cost as you grow. A Rails monolith is rarely one dyno: web dynos, Sidekiq dynos, a scheduler process, managed Postgres and Redis, log and APM add-ons. Buying the underlying services on AWS and right-sizing them can cost less at scale, but it is not automatic. Price both sides with your real usage; the Heroku vs AWS page has the list prices and a break-even formula.

Platform limits. Heroku Postgres caps connections by plan (200 on Standard-0 and Premium-0, 500 on larger plans), and Rails opens a pool per Puma process and per Sidekiq process, so a busy fleet hits the cap. Heroku's 30-second router timeout ends slow requests. On AWS you size connections and timeouts yourself.

Requirements. VPC isolation, IAM, compliance controls and integration with the rest of an AWS estate.

IIThe target architecture: a Rails monolith on AWS

Data, cache and storage map almost one-to-one. The compute layout is the main decision.

Compute. Amazon ECS on Fargate: Puma as one service behind the load balancer (scaling on requests or CPU), Sidekiq as another (scaling on queue depth), both from the same image. For a small, mostly-web app, ECS Express Mode creates the service, load balancer and scaling from one image. (App Runner closed to new customers on April 30, 2026.)

Database. RDS for PostgreSQL (like-for-like) or Aurora PostgreSQL (storage that grows on its own, faster failover, up to 15 readers). Many teams land on RDS first and evaluate Aurora once stable. Put Amazon RDS Proxy in front to pool connections across Puma and Sidekiq.

Redis, files and assets. ElastiCache covers Sidekiq queues, Action Cable pub/sub (config/cable.yml) and :redis_cache_store with a connection-string change. Active Storage uses the :amazon service on S3. rails assets:precompile runs at build time and CloudFront serves the fingerprinted files.

IIIDockerizing Rails, and credentials into AWS

Modern Rails (7.1 and later) generates a production Dockerfile, which is a good starting point.

The generated multi-stage build installs gems, runs rails assets:precompile (with SECRET_KEY_BASE_DUMMY=1 so it does not need real secrets), and copies only what runtime needs into a slim image. Each Procfile process becomes a service with a different command from the same image.

Move config vars and secrets out of the platform: real secrets (RAILS_MASTER_KEY or SECRET_KEY_BASE, DATABASE_URL credentials, API keys) into AWS Secrets Manager, plain config into SSM Parameter Store. ECS injects both as environment variables. Run rails db:migrate as a one-off task at deploy time, not on container boot.

IVSidekiq, Action Cable and scheduled jobs

Background work is the classic "we forgot one" area after a migration.

Sidekiq runs as its own ECS service against ElastiCache, scaled on queue depth and sized for memory-hungry jobs without overpaying the web tier. Solid Queue apps run the same way with the database as the backend.

Action Cable needs the Redis pub/sub backend and a load balancer that allows WebSocket upgrades with a generous idle timeout.

Scheduled jobs. sidekiq-cron rides along on the Sidekiq service. The whenever gem (a crontab) and Heroku Scheduler do not exist on Fargate: recreate each schedule as an EventBridge Scheduler rule that runs a one-off ECS task.

VThe Postgres cutover: check your source first

Containers, the landing zone, Sidekiq and assets can be built and tested without touching production. The Postgres cutover is the one moment that touches live data.

From classic Heroku Postgres (Essential, Standard, Premium): Heroku does not grant the replication role, so AWS DMS change data capture and logical replication to RDS are not available. Plan a write freeze and a pg_dump into pg_restore, and time a test restore to size the window. On Heroku Postgres Advanced, managed logical replication to an external database makes a short cutover possible. The Heroku Postgres to RDS page has the full runbook.

From a self-managed or other cloud Postgres: AWS DMS can do a full load and then stream ongoing changes, so the switch is a short pause.

The sequence: maintenance mode, pause Sidekiq, finish the restore or drain replication, switch DATABASE_URL and REDIS_URL, update Route 53 (TTL lowered a day ahead), re-check sequences, verify writes, leave maintenance. Keep the old platform as a rollback until you are confident.

VIWho runs the move, and who can fund it

You can do this yourself with the steps above. Many teams have a partner run the landing zone, the containers and the cutover.

Partner-filed funding: AWS says the Migration Acceleration Program (MAP) helps offset initial migration costs. It is built for migrations with meaningful ongoing AWS spend, so a small Rails app may not qualify. When the migration does qualify, your matched partner files it and AWS approves: typically $50K to $150K for startups. Depends on the workload; AWS approves. Activate credits are separate, and you apply for those yourself.

CloudRoute matches you with one vetted AWS partner. Startups pay CloudRoute nothing; partners pay CloudRoute a monthly membership plus 10% of AWS-approved funding.

VIIRails-specific gotchas

The small set of things that turn a clean migration messy.

• Assets compile wrong: No CSS after cutover usually means assets were not precompiled in the image or the asset host is wrong. Precompile at build time and check CloudFront.
• Connection limits move, they do not vanish: RDS limits scale with instance memory. Size pools per process and use RDS Proxy.
• Scheduled jobs must be recreated: whenever and Heroku Scheduler do not move. Rebuild each schedule in EventBridge Scheduler or sidekiq-cron.
• Slow requests the timeout used to hide: Without Heroku's 30-second wall, slow endpoints run longer. Set load balancer and Puma timeouts deliberately.
• Secret drift: Different RAILS_MASTER_KEY or SECRET_KEY_BASE values across services break credentials and sessions. One value from Secrets Manager.
• Ephemeral filesystem: Anything written to local disk (uploads, generated files) must go to S3.