Fai il deploy di Node.js su Nodion

Deploy di Node.js passo dopo passo

1. Ascolta su PORT Nodion imposta PORT per il processo web e invia lì il traffico. Leggi la variabile e metti il server in ascolto su 0.0.0.0. Fastify ascolta su localhost per impostazione predefinita, quindi passa 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. Fai il commit del lockfile e dello script di avvio Fai il commit di package-lock.json, yarn.lock, pnpm-lock.yaml o bun.lock; senza lockfile la build fallisce. Nodion esegue direttamente lo script start, quindi gli hook npm come prestart non vengono eseguiti. Senza script di avvio, i framework noti come Nuxt usano un loro comando predefinito; tutto il resto parte con node server.js, index.js o app.js e, come ultima opzione, con node .. Le dipendenze di sviluppo vengono rimosse dopo la build, quindi gli strumenti che ti servono a runtime, come tsx o una CLI di migrazione, vanno in dependencies. package.json

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

3. TypeScript: tieni un file JavaScript come punto d'ingresso Se il package.json ha uno script build e non esiste nessuno dei file server.js, app.js, index.js, src/server.js, src/index.js o src/app.js, Nodion tratta il repository come sito statico e non avvia il tuo server. Un server TypeScript che tsc compila in dist/ si presenta esattamente così. Aggiungi accanto al package.json un index.js che carica il server compilato (lo snippet richiede "type": "module"; in CommonJS scrivi require("./dist/server.js")) e fai puntare lo script di avvio al file compilato, per esempio node dist/server.js, non a uno strumento di sviluppo. index.js

   import "./dist/server.js";

4. Crea l'app e imposta le variabili Nella dashboard crea un'applicazione dal tuo repository GitHub, GitLab, Bitbucket o Gitea, scegli il branch e la regione EU Central. Le variabili lette dal tuo script di build richiedono il flag Build nella scheda Environment; tutte le altre esistono solo a runtime. Contrassegna le chiavi API come segrete.
5. Collega PostgreSQL ed esegui le migrazioni Crea un database PostgreSQL nella stessa regione e collegalo nella scheda Environment: dal deploy successivo la tua app legge DATABASE_URL. Una riga release: in un Procfile viene eseguita una volta per ogni build, dopo la build e prima che parta la nuova versione; se fallisce, la versione in esecuzione resta online. Procfile

   release: npm run migrate

6. Push e deploy Ogni push sul branch crea una nuova release. Il traffico passa alla nuova release appena / risponde con uno stato 2xx o 3xx. Se la tua API risponde 404 su /, aggiungi una route come /health e impostala come percorso di health check nelle impostazioni dell'app.

Da sapere

• Vite nel package.json indica un sito staticoCon vite in dependencies o devDependencies, Nodion fa la build del repository come sito statico e pubblica solo l'output della build, anche se esiste un server.js. Lo stesso vale per Angular, Gatsby, Create React App ed Eleventy. Per un server Node.js che fa anche la build di un frontend Vite, usa un Dockerfile.
• BunCon un bun.lock, Nodion installa le dipendenze ed esegue la build con Bun. L'app però parte sempre tramite lo script di avvio, quindi lo script deve chiamare Bun, per esempio "start": "bun run index.ts"; senza script, Nodion avvia l'app con node. La regola sul file di ingresso descritta sopra vale anche per i progetti Bun.
• Worker per le codeMetti web: node server.js e worker: node worker.js in un Procfile; senza una riga web:, la prima voce del Procfile diversa da release: diventa il comando predefinito. Poi aggiungi nella scheda Processes un processo chiamato worker senza porta. Valkey nella stessa regione dà alla tua coda un REDIS_URL.

Cosa gestisce Nodion per te

• Deploy senza downtime Fai push sul tuo branch e Nodion crea una nuova release. Il traffico passa alle nuove istanze solo quando superano l'health check; una release fallita lascia attiva quella in esecuzione. Le app con un volume locale invece si riavviano, perché il disco appartiene a una sola istanza.
• Database accanto all'app PostgreSQL, pgvector, MySQL, Valkey e ClickHouse gestiti, nella stessa regione. I database collegati arrivano come DATABASE_URL, REDIS_URL o CLICKHOUSE_URL.
• Anteprime per ogni pull request Attiva le anteprime: ogni pull request del tuo repository riceve un'app dedicata, con un proprio URL e database nuovi e vuoti, creata automaticamente o manualmente. Le pull request dai fork e quelle dei bot vengono ignorate.
• Worker, cron job e scalabilità Esegui i worker come processi aggiuntivi della stessa app, pianifica i job nella scheda Cron e scala ogni processo fino a 16 istanze.
• Fase di release Con i buildpack, la riga release: del Procfile viene eseguita a ogni nuova build. Le app con Dockerfile, così come i redeploy e i rollback a un'immagine precedente, usano un comando di release impostato sull'app stessa, che ha anche la precedenza sulla riga del Procfile. Nei siti statici, la fase di release gira in un'immagine che contiene solo i file generati dalla build.
• Log e metriche Nella dashboard trovi log di build, release e runtime, oltre alle metriche di CPU, memoria, disco e rete per ogni istanza.
• Domini e HTTPS Un hostname predefinito con HTTPS dal primo deploy; i tuoi domini ricevono i certificati in automatico.

Per approfondire

• Alternative a Heroku con hosting UE: 5 opzioni a confronto Una piattaforma tedesca e cloud statunitensi con regioni nell'UE, a confronto per sede, regioni e database gestiti.
• Dockerfile vs buildpack: quale dovresti usare? Entrambi trasformano il tuo codice in un'immagine container. Cambia chi scrive i passaggi della build, e questo determina controllo, manutenzione e aggiornamenti di sicurezza.

Node.js su Nodion: domande e risposte