Despliega Node.js en Nodion

Despliega Node.js paso a paso

1. Escucha en PORT Nodion define PORT para el proceso web y envía allí el tráfico. Lee la variable y enlaza el servidor a 0.0.0.0. Fastify escucha en localhost por defecto, así que pasa host: '0.0.0.0' a listen. server.js

   const express = require("express");
   
   const app = express();
   app.get("/", (req, res) => res.send("ok"));
   
   const port = process.env.PORT || 3000;
   app.listen(port, "0.0.0.0");

2. Haz commit de un lockfile y un script start Haz commit de package-lock.json, yarn.lock, pnpm-lock.yaml o bun.lock; sin lockfile, la build falla. Nodion ejecuta el script start directamente, por lo que los hooks de npm como prestart no se ejecutan. Sin script start, los frameworks conocidos como Nuxt usan su propio comando por defecto; todo lo demás arranca con node server.js, index.js o app.js y, como último recurso, con node .. Las dependencias de desarrollo se eliminan después de la build, así que las herramientas que necesitas en tiempo de ejecución, como tsx o una CLI de migraciones, van en dependencies. package.json

   "scripts": {
     "start": "node server.js"
   }

3. TypeScript: mantén un archivo de entrada JavaScript Si el package.json tiene un script build y no existe ninguno de los archivos server.js, app.js, index.js, src/server.js, src/index.js o src/app.js, Nodion trata el repositorio como un sitio estático y no arranca tu servidor. Un servidor TypeScript que tsc compila en dist/ tiene exactamente ese aspecto. Añade junto al package.json un index.js que cargue el servidor compilado (el fragmento necesita "type": "module"; en CommonJS escribe require("./dist/server.js")) y haz que el script start apunte al archivo compilado, por ejemplo node dist/server.js, no a una herramienta de desarrollo. index.js

   import "./dist/server.js";

4. Crea la app y define las variables 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. Las variables que lee tu script de build necesitan la opción Build en la pestaña Environment; las demás solo existen en tiempo de ejecución. Marca las claves de API como secretas.
5. Vincula PostgreSQL y ejecuta las migraciones Crea una base de datos PostgreSQL en la misma región y vincúlala en la pestaña Environment: a partir del siguiente despliegue, tu app lee DATABASE_URL. Una línea release: en un Procfile se ejecuta una vez por build, después de la build y antes de que arranque la nueva versión; si falla, la versión en ejecución sigue activa. Procfile

   release: npm run migrate

6. Haz push para desplegar Cada push a la rama genera una nueva release. El tráfico pasa a ella en cuanto / responde con un estado 2xx o 3xx. Si tu API responde 404 en /, añade una ruta como /health y defínela como ruta de health check en los ajustes de la app.

A tener en cuenta

• Vite en el package.json significa sitio estáticoSi vite figura en dependencies o devDependencies, Nodion hace la build del repositorio como sitio estático y solo publica el resultado de la build, aunque exista un server.js. Lo mismo vale para Angular, Gatsby, Create React App y Eleventy. Para un servidor Node.js que además compila un frontend Vite, usa un Dockerfile.
• BunCon un bun.lock, Nodion instala tus dependencias y ejecuta la build con Bun. Aun así, la app arranca mediante el script start, por lo que el script tiene que llamar a Bun, por ejemplo "start": "bun run index.ts"; sin él, Nodion arranca la app con node. La regla del archivo de entrada de arriba también se aplica a los proyectos Bun.
• Workers de colasPon web: node server.js y worker: node worker.js en un Procfile; sin una línea web:, la primera entrada del Procfile distinta de release: pasa a ser el comando por defecto. Después añade en la pestaña Processes un proceso llamado worker sin puerto. Valkey en la misma región le da a tu cola una REDIS_URL.

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

• Alternativas a Heroku con hosting en la UE: 5 opciones Una plataforma alemana y clouds estadounidenses con regiones en la UE, comparados por sede, regiones y bases de datos gestionadas.
• 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.

Node.js en Nodion: preguntas y respuestas