Despliega Docker en Nodion

Despliega Docker paso a paso

1. Escucha en 0.0.0.0 e indica el puerto con EXPOSE Nodion construye tu Dockerfile tal cual y arranca el CMD o el ENTRYPOINT de la imagen. No define PORT: tu servidor escucha en todas las interfaces en un puerto fijo, y EXPOSE le indica al formulario de creación cuál es. Las builds multi-stage funcionan; se ejecuta el stage final. Dockerfile

   FROM python:3.13-slim
   WORKDIR /app
   COPY requirements.txt .
   RUN pip install --no-cache-dir -r requirements.txt
   COPY . .
   EXPOSE 8000
   CMD ["gunicorn", "app:app", "--bind", "0.0.0.0:8000"]

2. Crea la app En el dashboard, crea una aplicación desde tu repositorio de GitHub, GitLab, Bitbucket o Gitea, y elige la rama y la región EU Central. Si hay un Dockerfile en el repositorio, el formulario preselecciona la estrategia Dockerfile y rellena el puerto a partir de EXPOSE. En un monorepo, define el Base directory (el contexto de build) y el nombre del Dockerfile.
3. Pasa los valores de build como build args Las variables con la casilla Build marcada en la pestaña Environment llegan a la build como build args de Docker, así que decláralas con ARG en el stage que las lee. El resto de variables, y las bases de datos vinculadas como DATABASE_URL, solo existen cuando el contenedor está en ejecución. Dockerfile

   FROM node:24-slim AS build
   ARG VITE_API_URL
   WORKDIR /app
   COPY . .
   RUN npm ci && npm run build

4. Ejecuta las migraciones una vez por despliegue Define tu comando de migraciones como comando de release de la app: se ejecuta una vez por despliegue desde la nueva imagen, antes de que arranque la nueva versión, y si falla, el despliegue se detiene y la versión en ejecución sigue activa. Defínelo con el campo release_command de la API; en el dashboard, por ahora el campo solo aparece en los ajustes de la app cuando los entornos de preview están activados. También puedes ejecutar las migraciones en el entrypoint o en el comando de arranque, pero entonces cada instancia las ejecuta en cada arranque.
5. Haz push para desplegar Cada push a la rama construye una nueva imagen en Fráncfort. El tráfico pasa a ella en cuanto el proceso web responde con 2xx o 3xx en la ruta del health check (por defecto /). Si la imagen tiene un HEALTHCHECK de Docker, se ignora.

A tener en cuenta

• Sin variable PORTSi tu servidor lee PORT, defínela tú, con ENV PORT=8000 en el Dockerfile o como variable en la pestaña Environment, y mantenla igual que el puerto del proceso web.
• Imágenes ya construidasOmite la build desde Git y despliega una imagen de Docker Hub, del GitHub Container Registry, del registry de Nodion o de un registry privado cuyas credenciales hayas guardado en Nodion. Se aplican las mismas reglas de puerto y health check.
• USER, .dockerignore y el commitSe respeta el USER de la imagen, se aplica un .dockerignore en el contexto de build y .git nunca se envía a la build. Declara ARG NODION_GIT_SHA para escribir el hash del commit en la imagen.

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 en Nodion: preguntas y respuestas