Desplegar Rails sin escribir un Dockerfile

La premisa detrás de la mayoría de las guías de “cómo containerizar Rails” es que primero tienes que escribir un Dockerfile. La mayoría de las veces no es así — el método de build solo necesita volverse tu problema cuando los valores por defecto de verdad no logran entender tu app, y eso pasa menos de lo que parece.

Qué decide el método de build en realidad

Método	Cuándo se usa
Dockerfile	el repo tiene uno que de verdad construye la app — un Dockerfile solo para desarrollo que espera un bind mount se salta automáticamente, no se corre a ciegas
Railpack	el valor por defecto para cualquier repo sin Dockerfile
Nixpacks	respaldo cuando Railpack no puede planificar el repo
Buildpacks	solo cuando se elige explícitamente en Settings → Build method

Una app de Rails recién creada sin Dockerfile construye con Railpack sin que escribas nada a mano. El orden importa más que los nombres: Railyard busca primero un Dockerfile real, y solo recurre a los builders automáticos cuando no hay uno.

Qué recibe una app de Rails sin que lo pidas

Esta es la parte que reemplaza lo que un Dockerfile escrito a mano tendría que hacer de todos modos:

• RAILS_ENV, RACK_ENV, RAILS_SERVE_STATIC_FILES y RAILS_LOG_TO_STDOUT se configuran si todavía no lo hiciste.
• Los assets se construyen con SECRET_KEY_BASE_DUMMY=1, así que no se necesita un secreto real en tiempo de build — el propio SECRET_KEY_BASE se genera una sola vez y queda cifrado.
• pg, mysql2/trilogy y redis/sidekiq en el Gemfile se mapean a la base de datos administrada correspondiente — las bases de datos extra de Rails 8 (cache, queue, cable) declaradas en config/database.yml reciben cada una su propia URL de conexión automáticamente.
• Sidekiq, Solid Queue, GoodJob, Resque o Delayed Job — el que de verdad esté en el Gemfile.lock — se ofrece como el proceso worker.
• Active Storage en disco recibe un volumen persistente sin ninguna configuración; conecta un bucket en su lugar y las variables de S3 se inyectan de la misma forma.
• assets:precompile corre en el paso de build automáticamente, toolchain de Node incluido — un paso de tailwindcss:build o esbuild encadenado a eso simplemente funciona, sin un stage de Dockerfile aparte.

Cuándo sí necesitas escribir uno

Un Dockerfile se gana su lugar cuando la app depende de algo que de verdad está fuera del propio ecosistema de Ruby — un binario compilado que los builders automáticos no saben instalar, un paso de runtime fuera de lo estándar, una imagen base exigida por razones de compliance. Fuera de eso, el camino automático maneja sin problema gemas nativas antiguas (nio4r, Puma 5 y anteriores) que compilan limpio bajo el GCC actual sin tocar ningún Dockerfile.

El paso de release corre bin/rails db:prepare antes de que cada versión reciba tráfico, por defecto — la propia línea release: de un Procfile lo reemplaza si ya tienes una. Define un release_command personalizado solo cuando db:prepare de verdad no alcanza, como un script de migración de datos puntual.

Referencia completa del framework: Rails, y qué hace en realidad el paso de build: Métodos de build.