Migrar desde Render
Migra servicios de Render con su Postgres, sus variables de entorno y sus dominios.
En Render, cada parte de una aplicación es un servicio independiente: web service, background worker, private service, cron job. En
Nodion construyes una sola imagen y ejecutas a partir de ella varios procesos en una aplicación; los cron jobs pertenecen a la app.
Nodion no lee un render.yaml, así que trasladas la configuración a mano.
Equivalencias entre Render y Nodion
| Render | Nodion |
|---|---|
| Web service | Application con el proceso web |
| Background worker | Otro proceso de la app, como worker |
| Private service | Proceso con un puerto, accesible internamente en <app>-<process>.app.internal (también recibe un hostname público, ver el paso 3) |
| Cron job (servicio independiente) | Cron job de la app |
| Static site | Buildpack de sitios estáticos |
| Build command y start command | Detección del buildpack y Procfile, o el comando del proceso |
| Pre-deploy command | Release command o entrada release: del Procfile |
| Render Postgres | Postgres gestionado, vinculado como DATABASE_URL |
| Render Key Value | Valkey, vinculado como REDIS_URL |
| Persistent disk | Volumen |
| Preview environments, service previews | Entornos de preview |
1. Crea el proyecto y la base de datos
Crea un proyecto y, dentro de él, una base de datos PostgreSQL en la región en la que se ejecutará la app. La app y su base de datos tienen que estar en la misma región. Elige una versión de Postgres igual o más reciente que la de Render. Más información en Bases de datos.
2. Copia la base de datos
La URL externa de la base de datos está en la página Info de la base de datos de Render; Render solo acepta conexiones externas con TLS
(documentación de Render). Detén las escrituras
de tus servicios y crea el dump como indica la documentación de backups
de Render. -n public incluye solo el esquema public; quítalo si tu app usa otros esquemas.
bashpg_dump --dbname="RENDER_EXTERNAL_DATABASE_URL" -n public --no-owner \
--format=directory --jobs=4 --compress=0 -f render.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-privileges --jobs=4 --format=directory \
--dbname="postgresql://nodion:PASSWORD@HOST:PORT/DATABASE?sslmode=require" \
render.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; la base de datos sigue funcionando internamente.
3. Crea la aplicación y sus procesos
Crea una aplicación desde el repositorio Git del web service. Si Render hacía la build con un build command y un start command, usa la estrategia
Buildpacks (Buildpacks); un Procfile define los comandos y, si no lo hay, se aplican los valores por defecto del lenguaje.
Si el servicio se ejecutaba en Docker, usa la estrategia Dockerfile.
Render define PORT en 10000 por defecto. Nodion define PORT para el proceso web de las apps con buildpacks
(por defecto, 8080); si tu app lee PORT, no cambia nada. Si el 10000 está fijado en el código, cámbialo. En las apps con Dockerfile,
Nodion no define PORT; la app escucha en el puerto del proceso web.
Añade cada background worker del mismo repo en Processes, New process como otro proceso e introduce su start command. Un
private service también pasa a ser un proceso, con un puerto. Ojo: cada proceso con un puerto recibe un hostname público por defecto
además de su dirección interna; no existe un servicio solo privado. Protege ese puerto en la app (con autenticación, por ejemplo). Los
hostnames de Nodion solo se pueden desactivar para toda la app, una vez que hay un dominio personalizado activo. Un worker que solo consume una cola no necesita puerto. 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 de entorno
Render no documenta ninguna exportación de variables de entorno desde el dashboard; la API de Render devuelve las variables de un servicio, pero no las de los environment groups
(referencia de la API de Render, GET /services/{serviceId}/env-vars;
sobre los environment groups, consulta la documentación de Render). Recógelas como
líneas KEY=value, incluidos los valores de los environment groups, y pégalas en Environment, Add many.
Define los secretos con nodion env set KEY=value --secret y los valores de varias líneas con la CLI o la API. Nodion no tiene
secret files: guarda su contenido como variable secreta (--secret) y haz que la app lo lea de la variable o que escriba el
archivo al arrancar la propia app. Los secretos no deben ir en la imagen, como también advierte Render.
Después, borra las variables DATABASE_URL y REDIS_URL de Render: 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, y lo mismo para rediss:// hacia Valkey.
5. Traslada los cron jobs
Un cron job de Render es un servicio independiente con una programación en UTC (documentación de Render). En Nodion lo añades en la pestaña Cron de la app cuyo código necesita: programación de cinco campos en UTC, el comando, un timeout de hasta 30 minutos y hasta 8 jobs por app. Si una ejecución sigue en curso, se omite la siguiente.
6. Despliega, traslada el dominio y apaga Render
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. Nodion no ofrece un registro A
como destino, así que en el apex tu proveedor de DNS tiene que admitir ALIAS, ANAME o CNAME flattening. 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 los servicios de Render (Render CLI). Render no conserva backups de una base de datos eliminada, así que guarda tu dump.
bashrender services delete my-service --confirm Eliminar el servicio no elimina la base de datos ni una instancia de Key Value. En las instancias de pago, Render guarda por defecto los datos de Key Value en disco (documentación de Render): un Valkey vacío solo basta si lo usas como cache o para colas que has dejado vaciar antes; si necesitas las claves, muévelas antes de eliminar la instancia. Después, elimina tú mismo la base de datos de Render Postgres, con Delete Database al final de su página Info (documentación de Render), y también cualquier instancia de Key Value; los comandos de la CLI para ambas están en la referencia de la Render CLI.
Qué funciona de otra manera
- No hay environment groups ni secret files; cada variable pertenece a una sola app.
- Los workers y los private services son procesos de una app, no servicios independientes.
- Los cron jobs se ejecutan en una app existente con su release activa.
- La CLI obtiene los logs, pero no puede seguirlos; para verlos en directo, usa la pestaña Logs.
Siguientes pasos
Comparativa de Nodion y Render, Precios, Aplicaciones y Bases de datos.