Phoenix y Elixir

• Datastores a partir de mix.exs: ecto_sql/postgrex → Postgres, ecto_ch/ch → ClickHouse, redix → Redis.
• Migrations: mix ecto.migrate. Los releases compilados no tienen mix en tiempo de ejecución, así que Railyard encuentra el release donde sea que la imagen lo ponga y ejecuta su migrator (bin/migrate si existe, o si no bin/<app> eval). mix phx.server se convierte en bin/<app> start de la misma forma.
• Variables leídas en config/runtime.exs (BASE_URL, HTTP_PORT, LISTEN_IP, DATABASE_URL, CLICKHOUSE_DATABASE_URL…) se conectan automáticamente; SECRET_KEY_BASE se genera.
• Se definen MIX_ENV=prod y PHX_SERVER=true.

Los trabajos en segundo plano normalmente no necesitan un segundo proceso

La mayoría de las apps de Elixir corren trabajos con Oban — una cola basada en Postgres iniciada desde el mismo árbol de supervisión que el endpoint web, así que ya está corriendo en el momento en que web arranca, sin un worker separado que declarar o escalar. Eso sigue siendo el modelo de 12-factor: el job runner es solo uno de los roles que tu único release OTP ya cumple, no un segundo desplegable que mantener sincronizado con el primero.

Si de verdad quieres un nodo worker dedicado — separar el procesamiento de trabajos en su propio proceso para que una cola lenta no le quite recursos a las solicitudes web — decláralo en un Procfile y haz que tu release lea un flag o una variable de entorno para saltarse el arranque del endpoint:

web: bin/my_app start
worker: bin/my_app eval "MyApp.Release.worker()"

Agrega o edita procesos desde la pestaña Workers de la app sin cambiar el repositorio, y escala cualquiera desde la CLI:

railyard scale my-app worker=2

Configuración y secretos

Todo lo que config/runtime.exs lee con System.get_env/2 es una variable normal: defínela en Variables, o railyard env:set my-app KEY=VALUE desde la CLI, y el mismo release compilado corre sin cambios desde staging hasta producción — paridad dev/prod, no un build distinto por entorno. Apunta a una base de datos, ClickHouse o Redis que corra como su propio servicio en el canvas con ${{redis.RAILYARD_PRIVATE_URL}} — resuelto por entorno. Consulta Variables y secretos.

Despliégalo

• Desde un repositorio: pega la URL de Git, o elígelo del selector una vez que conectes GitHub — Railyard lee mix.exs, completa ecto.migrate, la base de datos provisionada y SECRET_KEY_BASE, y despliega con cada push.
• Desde la CLI: railyard create my-app https://github.com/me/my-app --addons postgres, o railyard git:remote && git push railyard main desde dentro del repositorio.
• 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.