Despliega Docker Compose en Nodion

Despliega Docker Compose paso a paso

1. Revisa tu archivo Compose Nodion lee docker-compose.yml, docker-compose.yaml, compose.yml o compose.yaml, y toma el que está más cerca de la raíz del repositorio. Necesita al menos un servicio de app además de las bases de datos y cachés; un archivo que solo tenga bases de datos y cachés se ignora. docker-compose.yml

   services:
     web:
       build: .
       environment:
         DATABASE_URL: postgres://app:app@db:5432/app
         REDIS_URL: redis://cache:6379
     db:
       image: postgres:17
     cache:
       image: valkey/valkey:8

2. Elige Docker Compose al crear la app Crea una aplicación desde tu repositorio en la región EU Central. Cuando el análisis encuentra un archivo Compose utilizable, aparece la opción Docker Compose; nunca está preseleccionada. Elígela y revisa el plan: antes de crear la app, todavía puedes elegir el tamaño y las instancias de cada proceso y ajustar el tamaño de los volúmenes.
3. Mira qué se convierte en servicio gestionado Nodion se guía por el nombre de la imagen: postgres y postgis pasan a ser Managed PostgreSQL, pgvector pasa a ser pgvector, redis y valkey pasan a ser Valkey, mysql y mariadb pasan a ser MySQL, clickhouse pasa a ser ClickHouse y minio pasa a ser un bucket. Cualquier otro servicio ejecuta su imagen como proceso de esa única app. El tag de la imagen no determina la versión de la base de datos, y los usuarios y contraseñas los pone Nodion. Managed PostgreSQL no tiene la extensión PostGIS, así que una app que necesite PostGIS pierde sus funciones espaciales tras la importación; deja una base de datos así fuera del archivo Compose.
4. Revisa las variables de conexión Una variable del servicio de app que apunta a otro servicio por su nombre, como @db:5432 en el ejemplo de arriba, se convierte en un vínculo: Nodion inserta la dirección real en el despliegue. Si no, las bases de datos llegan como DATABASE_URL y Valkey como REDIS_URL. Del resto de variables, solo se copian las del servicio de app principal, y los valores que parecen secretos se marcan como secretos.
5. A partir de ahí, gestiona la app en el dashboard El primer despliegue espera a que las bases de datos estén listas. Después, el archivo Compose ya no se lee: cada push construye la app con la estrategia Dockerfile o Buildpacks que se encuentre en el mismo repositorio, y cambias los procesos, las variables y los tamaños en el dashboard.

A tener en cuenta

• Experimental y puntualLa importación es un atajo para la primera configuración, no un runtime de Compose. Si tu archivo no se traslada bien, monta la misma configuración a mano: una app, una base de datos vinculada en la pestaña Environment y procesos adicionales en la pestaña Processes.
• Qué ignora NodionLas redes, los perfiles, los healthchecks de Compose, depends_on como orden de arranque, deploy.replicas, los bind mounts y los volúmenes anónimos. Un segundo servicio con su propio build: comparte la imagen de la única app.
• VolúmenesLos volúmenes con nombre se convierten en volúmenes de Nodion, de 5 GB por defecto y editables en el plan, montados en los procesos que los usan.

Lo que Nodion gestiona por ti

• Despliegues sin downtime Haz push a tu rama y Nodion construye una nueva release. El tráfico pasa a las nuevas instancias cuando superan el health check; si una release falla, la que está en marcha sigue activa. En cambio, las apps con un volumen local se reinician porque el disco pertenece a una sola instancia.
• Bases de datos junto a la app PostgreSQL, pgvector, MySQL, Valkey y ClickHouse gestionados en la misma región. Al vincular una base de datos, sus datos de conexión llegan como DATABASE_URL, REDIS_URL o CLICKHOUSE_URL.
• Previews por pull request Activa las previews: cada pull request de tu repositorio tendrá su propia app, con URL y bases de datos nuevas y vacías. Puedes crearla automáticamente o a mano. Se omiten las pull requests de forks y bots.
• Workers, cron jobs y escalado Ejecuta workers como procesos adicionales de la misma app, programa tareas en la pestaña Cron y escala cada proceso hasta 16 instancias.
• Paso de release Con buildpacks, una línea release: del Procfile se ejecuta con cada nueva build. Las apps con Dockerfile, así como los redeploys o rollbacks a una imagen anterior, usan un comando de release definido en la propia app, que además tiene prioridad sobre la línea del Procfile. En los sitios estáticos, el paso de release se ejecuta en una imagen que solo contiene los archivos generados por la build.
• Logs y métricas Logs de build, release y runtime, además de métricas de CPU, memoria, disco y red de cada instancia, en el dashboard.
• Dominios y HTTPS Un nombre de host predeterminado con HTTPS desde el primer despliegue; tus propios dominios reciben certificados automáticamente.

Para seguir leyendo

• Dockerfile vs buildpacks: ¿cuál deberías usar? Los dos convierten tu código en una imagen de contenedor. Lo que cambia es quién escribe los pasos de la build, y eso decide el control, el mantenimiento y las actualizaciones de seguridad.
• Alternativas a Railway en Europa: 5 opciones comparadas Contenedores y bases de datos con pago por uso, con una empresa o región en la UE: cinco alternativas a Railway comparadas por facturación, bases de datos y ubicación.

Docker Compose en Nodion: preguntas y respuestas