Rails Dockerfile Best Practices Part 1: Image Slimming

Takeaways

• Series goal: line-by-line walkthrough of Rails 7.1+ default Dockerfile — Part 1 covers image size reduction only.
• Why slim images: faster builds/deploys/CI, lower registry storage and bandwidth, faster startup, smaller attack surface (fewer packages).
• Inspect tools: docker images for size; docker history for per-layer breakdown — layers are immutable filesystem deltas from each Dockerfile instruction.
• Typical Rails image bloat sources: Ruby base, apt packages, bundle copy, app copy — example kamal-dashboard ~619MB before optimization.
• Base image choice matters: ruby:$VERSION-slim vs full Debian; multi-stage builds separate build deps from runtime (previewed in series).

Notes

Igor Aleksandrov (igor.works). Cites DHH cloud-exit cost savings as motivation for caring about image size at scale. Practical for Kamal/Dockerized Rails deployments.

Open questions

• Slim image vs. debuggability tradeoffs in production incident response?
• Alpine vs debian-slim for Rails (musl/gem native extension issues)?