Rails

• Release: bin/rails db:prepare corre antes de que cada versión salga en vivo (tu línea release: del Procfile tiene prioridad).
• Valores por defecto de producción: RAILS_ENV, RACK_ENV, RAILS_SERVE_STATIC_FILES y RAILS_LOG_TO_STDOUT se definen si no lo has hecho tú; los assets se compilan con SECRET_KEY_BASE_DUMMY=1, así que no se necesita un secreto real en tiempo de build. SECRET_KEY_BASE se genera una sola vez.
• Bases de datos: pg → Postgres, mysql2/trilogy → MySQL, redis/sidekiq → Redis. Las bases de datos extra de Rails 8 (cache, queue, cable) encontradas en config/database.yml obtienen cada una su propia <NAME>_DATABASE_URL.
• Workers: se ofrecen Sidekiq, Solid Queue (bin/jobs cuando está presente), GoodJob, Resque y Delayed Job a partir de tu Gemfile.lock.
• Uploads: Active Storage en disco recibe automáticamente un volumen persistente storage/; o conecta un bucket y se inyectan las variables de S3.
• Las gems nativas antiguas (nio4r, puma 5…) compilan bajo GCC 14 sin cambios.

Los workers son un segundo proceso, no una segunda app

Una app es un mismo código y una misma imagen; web, worker, el comando de release y cron son tipos de proceso de esa misma app, cada uno escalado por su cuenta — el modelo de 12-factor, no una flota de apps casi idénticas para un mismo código. Con un Procfile:

web: bin/rails server -p $PORT
worker: bundle exec sidekiq

ambos aparecen automáticamente. Sin uno, Railyard arranca web por su cuenta y ofrece el primer job runner que encuentra en tu Gemfile.lock como un proceso worker. Agrega más desde la pestaña Workers de la app, o escala lo que ya existe desde la CLI:

railyard scale my-app worker=3

web está limitado a una réplica por ahora; worker escala de 1 a 10. Consulta Workers y tareas programadas para cron.

Solid Queue, de tres formas

• Su propia base de datos (el valor por defecto de Rails 8). config/database.yml declara una entrada queue: con migrations_paths: db/queue_migrate; Railyard la lee como una base de datos extra y provisiona una QUEUE_DATABASE_URL separada junto a DATABASE_URL. bin/rails db:prepare migra ambas en el paso de release. El proceso worker ejecuta bin/jobs si tu app lo tiene, o si no bundle exec rake solid_queue:start.
• Compartiendo la base de datos principal. Elimina la entrada queue: (o apúntala a la conexión principal) y las tablas de Solid Queue viven junto a las tuyas — no se provisiona nada extra, un solo DATABASE_URL, el mismo comando de worker.
• Dentro de Puma, sin proceso worker. El switch Run Solid Queue inside Puma del panel Settings → Rails del canvas define SOLID_QUEUE_IN_PUMA=true, que un config/puma.rb estándar de Rails 8 ya lee (plugin :solid_queue if ENV["SOLID_QUEUE_IN_PUMA"]). Puma despacha los trabajos por su cuenta; elimina el proceso worker y escala web en su lugar.

El mismo panel agrega Action Cable sobre Solid Cable (WebSockets, que provisiona su propia CABLE_DATABASE_URL), YJIT y Thruster al frente de Puma.

Configuración y secretos

Nada más que variables de entorno: define una en Variables, o railyard env:set my-app KEY=VALUE desde la CLI, y la misma imagen corre sin cambios desde staging hasta producción — paridad dev/prod, no una rama en tiempo de build. SECRET_KEY_BASE y cualquier otro secreto propio de tu app se genera una sola vez y se cifra; una clave de terceros nunca se inventa por ti. Para apuntar a un Postgres o Redis que corra como su propio servicio en el canvas en lugar de un complemento en el servidor de la app, referéncialo con ${{redis.REDIS_URL}} — resuelto por entorno, la misma sintaxis entre servicios que se usa en todas partes. Consulta Variables y secretos.

Precompilar assets (Tailwind, esbuild, importmap)

assets:precompile corre en el paso de build sin configuración de tu parte: el build conecta un toolchain de Node directamente al propio build de Ruby, así que un paso de tailwindcss:build o cssbundling-rails/esbuild encadenado a él simplemente funciona — no hay una etapa separada de Dockerfile ni un hook de pre-deploy que escribir. Si precompilar necesita la base de datos o Redis — un initializer que hace consultas al arrancar, por ejemplo — y solo el app server las tiene, Railyard detecta el fallo ahí y difiere ese mismo paso a la fase de release automáticamente, donde sí existen. Subir una imagen ya construida en lugar de dejar que Railyard la construya funciona igual: los assets se compilan contra contenedores desechables de Postgres y Redis en el build server primero y quedan horneados en la imagen antes de que llegue al app server, así tu base de datos real nunca se toca. No necesitas un release_command para nada de esto — define uno solo si db:prepare no es suficiente, por ejemplo un script de migración de datos.

Despliégalo

• Desde un repositorio: pega la URL de Git, o elígelo del selector una vez que conectes GitHub — Railyard lee el Gemfile, completa la lista de procesos, las bases de datos y las variables documentadas, y despliega con cada push.
• Desde la CLI: railyard create my-app https://github.com/me/my-app --addons postgres,redis, o ejecuta railyard git:remote && git push railyard main desde dentro del repositorio para desplegar con cada push sin GitHub.
• Con un clic: agrega el botón de despliegue a tu README, o publícalo en el catálogo de plantillas para que cualquiera pueda lanzarlo con sus complementos y variables ya completados.