Fazendo deploy de Rails sem escrever um Dockerfile

A suposição por trás da maioria dos guias de “como containerizar Rails” é que você precisa escrever um Dockerfile primeiro. Na maioria das vezes, não precisa — o método de build só precisa se tornar seu problema quando os padrões genuinamente não conseguem entender sua aplicação, o que é mais raro do que parece.

O que realmente escolhe o método de build

Método	Quando ele roda
Dockerfile	o repositório tem um que de fato constrói a aplicação — um Dockerfile só de desenvolvimento que espera um bind mount é ignorado automaticamente, não rodado às cegas
Railpack	o padrão pra qualquer repositório sem Dockerfile
Nixpacks	fallback quando o Railpack não consegue planejar o repositório
Buildpacks	só quando escolhido explicitamente em Settings → Build method

Uma aplicação Rails nova sem Dockerfile constrói no Railpack sem nada escrito à mão. A ordem importa mais do que os nomes: o Railyard checa primeiro se existe um Dockerfile de verdade, e só recorre aos builders automáticos quando não há um.

O que uma aplicação Rails recebe sem precisar pedir

Esta é a parte que substitui o que um Dockerfile escrito à mão teria que fazer:

• RAILS_ENV, RACK_ENV, RAILS_SERVE_STATIC_FILES e RAILS_LOG_TO_STDOUT são definidos se você ainda não tiver feito isso.
• Os assets são construídos com SECRET_KEY_BASE_DUMMY=1, então um secret real não é exigido no momento do build — o próprio SECRET_KEY_BASE é gerado uma vez e criptografado.
• pg, mysql2/trilogy e redis/sidekiq no Gemfile são mapeados pro banco gerenciado correspondente — os bancos extras do Rails 8 (cache, queue, cable) declarados em config/database.yml recebem cada um sua própria URL de conexão automaticamente.
• Sidekiq, Solid Queue, GoodJob, Resque ou Delayed Job — o que de fato estiver no Gemfile.lock — é oferecido como processo worker.
• O Active Storage em disco recebe um volume persistente sem nenhuma configuração; conecte um bucket no lugar e as variáveis do S3 são injetadas do mesmo jeito.
• O assets:precompile roda na etapa de build automaticamente, toolchain do Node incluído — um passo de tailwindcss:build ou esbuild encadeado nele simplesmente funciona, sem stage separado no Dockerfile.

Quando você realmente precisa escrever um

Um Dockerfile ganha seu lugar quando a aplicação depende de algo genuinamente fora do próprio ecossistema Ruby — um binário compilado que os builders automáticos não sabem instalar, uma etapa de runtime fora do padrão, uma imagem base exigida por motivos de compliance. Fora isso, o caminho automático lida com gems nativas antigas (nio4r, Puma 5 e anteriores) compilando direto sob o GCC atual, sem nenhuma mudança no Dockerfile.

A etapa de release roda bin/rails db:prepare por padrão antes de cada versão receber tráfego — uma linha release: no seu próprio Procfile sobrepõe isso se você já tiver uma. Defina um release_command customizado só quando o db:prepare genuinamente não for suficiente, como um script de migração de dados pontual.

Referência completa do framework: Rails, e o que a etapa de build realmente faz: Build methods.