Migrar desde Railway

Migra servicios de Railway con su base de datos y sus variables.

Un proyecto de Railway es un conjunto de servicios conectados mediante referencias entre variables. En Nodion, un servicio con su propio código pasa a ser una aplicación, los workers del mismo código pasan a ser procesos adicionales de esa app y las bases de datos pasan a ser bases de datos gestionadas que vinculas a la app. Nodion no lee railway.json ni railway.toml; la propia Railway está retirando Config as Code (corte definitivo el 1 de diciembre de 2026), así que trasladas la configuración a mano.

Equivalencias entre Railway y Nodion

1. Crea el proyecto y las bases de datos

Crea un proyecto y, dentro de él, las bases de datos que usa tu proyecto de Railway, en la región en la que se ejecutarán las apps. Para Postgres, elige una versión igual o más reciente que la de Railway. En lugar de Redis, Nodion ofrece Valkey, también vinculado como REDIS_URL. Un Valkey vacío solo basta si lo usas como cache o para colas que has dejado vaciar antes; si necesitas las claves de Redis, muévelas antes de eliminar el proyecto de Railway. Más información en Bases de datos.

2. Copia la base de datos

Las bases de datos de Railway son privadas por defecto. Para el dump puedes acceder a ellas de dos maneras. La primera: activa el acceso público en Settings, Networking; Railway crea entonces un TCP proxy, define DATABASE_PUBLIC_URL (documentación de Railway) y factura el tráfico que pasa por el proxy como egress. La segunda: deja la base de datos privada y abre un túnel con la Railway CLI, después de enlazar el proyecto con railway link. Los backups de volúmenes integrados de Railway solo se restauran en el mismo proyecto, así que para la migración necesitas pg_dump.

Detén las escrituras de tus servicios y crea el dump como indica la guía de backups de Railway. Con el acceso público, usa el valor de DATABASE_PUBLIC_URL de las variables del servicio de la base de datos:

bashpg_dump "postgresql://postgres:PASSWORD@PROXY_HOST:PROXY_PORT/railway" \
  --format=custom --no-owner --file=railway.dump

Con el túnel, primero enlaza el proyecto con railway link; después abre el túnel y, en un segundo terminal, haz el dump contra localhost con el puerto que muestra la CLI:

bashrailway link
railway connect postgres --tunnel-only

# second terminal
pg_dump "postgresql://postgres:PASSWORD@localhost:TUNNEL_PORT/railway" \
  --format=custom --no-owner --file=railway.dump

En Nodion, abre la pestaña Overview de la base de datos y haz clic en Enable public access. Cuando el endpoint deje de mostrar Provisioning, copia la URL de conexión (siempre con TLS) y añade tu propia IP en Allowed sources. Después, restaura:

bashpg_restore --verbose --no-owner --no-acl \
  --dbname "postgresql://nodion:PASSWORD@HOST:PORT/DATABASE?sslmode=require" \
  railway.dump

Usa un pg_restore igual o más reciente que el más nuevo de los dos servidores. Comprueba el número de filas en la pestaña Browse y luego vuelve a desactivar el acceso público, también en Railway.

3. Crea la aplicación y sus procesos

Crea una aplicación por cada servicio con código, desde su repositorio Git. Si Railway hacía la build con Railpack o Nixpacks, usa la estrategia Buildpacks (Buildpacks); si encontraba un Dockerfile, usa la estrategia Dockerfile. A diferencia de Railway, Nodion no elige la estrategia por ti: la defines tú.

Railway inyecta PORT en tus servicios. Nodion define PORT solo para el proceso web de las apps con buildpacks; en las apps con Dockerfile, la app escucha en el puerto del proceso web (si no, en el del EXPOSE de la imagen; si no, en el 8080).

Si un segundo servicio se ejecutaba desde el mismo repo y solo cambiaba el start command (un worker, por ejemplo), añádelo en Processes, New process como otro proceso de la misma app e introduce ahí el start command. Traslada un pre-deploy command a una línea release: del Procfile (buildpacks) o al release command de la app (Settings, en la tarjeta Preview environments, donde el campo aparece una vez activadas las previews, o release_command a través de la API). Se ejecuta una vez en cada despliegue antes de web; si falla, la release anterior sigue activa.

4. Traslada las variables

Muestra las variables de un servicio como líneas KEY=value (Railway CLI):

bashrailway variable list --kv > railway.env

Pega las líneas en Environment, Add many. La Railway CLI no muestra las sealed variables (documentación de Railway); defínelas a mano, como secretos, con nodion env set KEY=value --secret. Revisa los valores con comillas y define los valores de varias líneas con la CLI o la API.

Nodion no tiene referencias como ${{shared.KEY}} o ${{otherService.KEY}}. Revisa cada variable importada: debe contener el valor real, no el texto de la referencia. Donde una referencia apuntaba a otro servicio, define en su lugar el hostname interno de ese servicio en Nodion (<app>.app.internal) o vincula la base de datos.

Después, borra las variables que apuntan a una base de datos de Railway (DATABASE_URL, REDIS_URL): una variable que defines tú sobrescribe el valor de una base de datos vinculada. Vincula las bases de datos con Attach database. Dentro de Nodion, la conexión va sin TLS (sslmode=disable); si tu código fuerza SSL, desactívalo para esta URL.

5. Traslada el cron

En Railway, un cron job es un servicio independiente que se ejecuta y termina (documentación de Railway). En Nodion lo añades en la pestaña Cron de la app que contiene el código necesario: programación de cinco campos en UTC, el comando, un timeout de hasta 30 minutos y hasta 8 jobs por app. Se ejecuta con la release activa y las variables de entorno de la app.

6. Despliega, traslada el dominio y apaga Railway

Despliega y revisa la pestaña Logs. Después añade el dominio en la pestaña Domains y crea los dos registros que muestra Nodion: TXT _nodion-challenge.your-domain y un CNAME (un ALIAS en el apex) que apunta al hostname por defecto de la app. El certificado llega en cuanto el CNAME apunta a Nodion; cuenta con unos minutos sin certificado válido y baja el TTL antes. Cuando todo funcione, elimina el proyecto de Railway; según Railway, la eliminación es permanente.

bashrailway delete --project my-project --yes

Qué funciona de otra manera

• No hay entornos como production y staging dentro de un proyecto; usa apps o proyectos separados.
• No hay shared variables ni referencias; los valores de la base de datos llegan al vincularla.
• Los cron jobs se ejecutan en una app existente, no como servicio independiente.
• La CLI obtiene los logs, pero no puede seguirlos; para verlos en directo, usa la pestaña Logs.

Siguientes pasos

Comparativa de Nodion y Railway, Precios, Aplicaciones y Bases de datos.