Why is master.key excluded from the build context?

Because it decrypts config/credentials.yml.enc. Anything in the build context can end up in a layer, and layers are readable by anyone who can pull the image.

Why does asset precompilation use a dummy secret?

Rails insists on a SECRET_KEY_BASE to boot, but asset compilation never uses it. SECRET_KEY_BASE_DUMMY=1 satisfies the check without putting a real secret anywhere near the build.

Should I use Thruster in front of Puma?

It is worth it if you serve assets from the app. Thruster adds HTTP caching and X-Sendfile support in front of Puma — wrap the CMD with `./bin/thrust` to enable it.

All Dockerizers

Ruby on Rails Dockerfile generator

Generate a production Dockerfile for a Rails app — gems installed in deployment mode, assets precompiled at build time and a non-root runtime.

Configure

App name

Port

Database service

Precompile assets

Redis service

Loading...

What this Dockerfile does

3 items need attention

Needs attention: RAILS_MASTER_KEY must come from the environment
config/master.key is excluded by .dockerignore on purpose — it decrypts your credentials file. Pass it at runtime instead.
Needs attention: Migrations do not run on boot
Run `./bin/rails db:migrate` as a release step. Running it from the entrypoint races as soon as you have more than one replica.
Needs attention: Compose credentials are placeholders
The generated docker-compose.yml uses `app`/`app` so it runs out of the box locally. Replace them with real secrets before this reaches a server.
Good practice: Multi-stage build (3 stages)
Compilers, dev dependencies and source files stay in the build stages. Only the runtime artefacts are copied into the final image.
Good practice: Runs as rails, not root
A container escape from a root process is a host root process. Dropping privileges is the cheapest hardening step there is.
Good practice: .dockerignore keeps secrets out of the build context
`.git`, `.env` and local dependency folders never reach the daemon, so they cannot end up in a layer or in `docker history`.
Good practice: Dependency cache persists across builds
BuildKit cache mounts keep the package manager store outside the image. Rebuilds after a lockfile change reuse everything already downloaded, and the cache adds nothing to the final size.
Good practice: Healthcheck defined
Docker, Compose and Easypanel can tell the difference between a running process and a working app, and restart it when it wedges.
Note: Requires BuildKit
BuildKit is the default builder in Docker 23 and later. On anything older, export `DOCKER_BUILDKIT=1` before building.
Note: The healthcheck uses /up
Rails 7.1 and later mount a health endpoint at /up by default. On older versions, point the probe at a route that exists.

How to use it

Everything runs locally. Nothing is uploaded, and no account is needed.

Drop the files into your project root
Every generated file belongs next to your package manifest — the Dockerfile references paths relative to the build context, so nesting them in a subfolder breaks the COPY lines.
Build the image
docker build -t rails-app .
Bring up the stack
docker compose up --build
Run migrations once
docker compose run --rm app ./bin/rails db:migrate