Deploying Rails. Deployed properly.: what should I watch out for? (#1)

RAILS_MASTER_KEY belongs in a secret manager, not an env var pasted into a dashboard. Every cloud has one; use it.

Deploying Rails. Deployed properly.: what should I watch out for? (#2)

Health checks: hit `/up` (Rails 7.1+) not `/`. It skips middleware and doesn't touch the DB.

Deploying Rails. Deployed properly.: what should I watch out for? (#3)

Solid Cable uses Postgres LISTEN/NOTIFY — great, but you need session affinity if you're behind more than one Puma process without a shared cable.

Deploying Rails. Deployed properly.: what should I watch out for? (#4)

If you use `bin/rails assets:precompile` at boot, you'll deploy slowly and flakily. Bake assets into the image.

// framework · rails

Rails. Deployed properly.

The majestic monolith is back, and it deploys better than ever. Kamal 2, Solid stack, Propshaft — no Node, no Redis, no Nginx if you don't want them.

Rails 8 rethought the deployment story from the ground up. This guide covers the modern default — Kamal 2 + Solid Queue + Solid Cache + Solid Cable — plus the "boring stack" of Puma behind a managed load balancer when you'd rather let the cloud do the heavy lifting.

under 60s

zero-downtime deploy

dependencies removed by Solid stack

1 vCPU / 1 GB

min prod footprint

01 / 05

Dockerfile: use the generated one

`rails new` in Rails 8 gives you a production-grade multi-stage Dockerfile out of the box. Resist the urge to rewrite it. Add build args for asset precompile secrets, then move on.

Dockerfile
# rails new -- --skip-jbuilder --database=postgresql
# ships a hardened multi-stage Dockerfile. Trust it.
FROM ruby:3.3-slim AS base
ENV RAILS_ENV=production BUNDLE_DEPLOYMENT=1 BUNDLE_WITHOUT="development:test"
# ... see bin/docker-entrypoint for db:prepare on boot

02 / 05

Kamal 2 for VMs, PaaS for managed

Kamal turns any Linux box into a Rails production host — perfect for AWS EC2, Azure VMs or GCP Compute Engine. On Cloud Run, Fargate, Container Apps or Heroku, skip Kamal and let the platform do rolling deploys.

yml
# config/deploy.yml
service: hotwire-monolith
image: you/hotwire-monolith
servers:
  web: [ 10.0.1.11, 10.0.1.12 ]
  jobs:
    hosts: [ 10.0.1.21 ]
    cmd: bundle exec rake solid_queue:start
registry:
  server: ghcr.io
  username: you
env:
  clear: { RAILS_LOG_TO_STDOUT: true }
  secret: [ RAILS_MASTER_KEY, DATABASE_URL ]

03 / 05

Solid Queue instead of Sidekiq

Solid Queue runs on the same Postgres as your app, so you can drop Redis entirely. For most apps under ~500 jobs/sec this is a huge operational win. Keep Sidekiq if you need its high-throughput or ecosystem features.

04 / 05

Zero-downtime migrations

Follow the classic expand → migrate → contract pattern: add nullable columns, backfill in a job, then enforce constraints in a second deploy. `strong_migrations` catches most footguns in CI.

05 / 05

Assets: Propshaft, not Sprockets

New apps ship with Propshaft — a tenth the code of Sprockets and no dependency on Node. Import maps handle JS; Tailwind runs via the standalone CLI. Precompile happens once, at image build time.

Gotchas we learned the hard way

!RAILS_MASTER_KEY belongs in a secret manager, not an env var pasted into a dashboard. Every cloud has one; use it.
!Health checks: hit `/up` (Rails 7.1+) not `/`. It skips middleware and doesn't touch the DB.
!Solid Cable uses Postgres LISTEN/NOTIFY — great, but you need session affinity if you're behind more than one Puma process without a shared cable.
!If you use `bin/rails assets:precompile` at boot, you'll deploy slowly and flakily. Bake assets into the image.