Kamal + Docker for Rails Production

Ship a Rails 8 app to production without managing Kubernetes or paying Heroku 10× markup. AI agents generate Dockerfiles that work but waste 500MB of image size and 4 minutes of build time. They reach for alpine and trip on native gem compilation. This skill encodes the choices a senior infra-aware Rails dev makes.

Why this matters

Rails 8 ships a Dockerfile out of the box, plus Kamal 2 for deployment. Both are good. But the defaults need understanding — what to keep, what to customize, and how to wire secrets without leaking them to images or logs.

The opinion

Use the Rails-generated multi-stage Dockerfile as the starting point. Base on ruby:3.x-slim (debian-slim), not alpine — alpine's musl libc causes subtle native-gem failures with nokogiri, pg, sassc, and libvips. Use bin/docker-entrypoint for runtime setup (db:prepare). Deploy with Kamal 2. Use Rails credentials for app secrets, Kamal envs (.kamal/secrets) for deployment secrets. Health check at GET /up. Never put secrets in the Dockerfile.

Counter-positions:

• Distroless base images (gcr.io/distroless) are smaller and safer than slim, but every native gem becomes a debugging session. Worth it for super-locked-down envs; over-investment for most.
• Heroku, Fly.io, Render — managed PaaS. Trade money for engineer-hours. Pick if the team's time is better spent on product than ops. Kamal is the answer when you've decided you want your own VMs.
• Kubernetes — appropriate when you actually need its features (multi-cluster, auto-scaling on real signals, multi-team isolation). Don't pick K8s for a single Rails app.

Core patterns