Node.js auf Nodion deployen

Node.js Schritt für Schritt deployen

1. Auf PORT lauschen Nodion setzt PORT für den Web-Prozess und schickt den Traffic dorthin. Lies die Variable aus und binde an 0.0.0.0. Fastify lauscht standardmäßig nur auf localhost, gib listen also host: '0.0.0.0' mit. 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. Lockfile und start-Skript committen Committe package-lock.json, yarn.lock, pnpm-lock.yaml oder bun.lock; ohne Lockfile scheitert der Build. Nodion führt das start-Skript direkt aus, npm-Hooks wie prestart laufen also nicht. Ohne start-Skript bekommen bekannte Frameworks wie Nuxt ihren eigenen Standard, alles andere startet mit node server.js, index.js oder app.js, zuletzt mit node .. Dev-Dependencies werden nach dem Build entfernt; Tools, die du zur Laufzeit brauchst, etwa tsx oder ein Migrations-CLI, gehören in dependencies. package.json

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

3. TypeScript: eine JavaScript-Einstiegsdatei behalten Hat die package.json ein build-Skript und gibt es keine der Dateien server.js, app.js, index.js, src/server.js, src/index.js oder src/app.js, behandelt Nodion das Repository als statische Site und startet deinen Server nicht. Genau so sieht ein TypeScript-Server aus, den tsc nach dist/ kompiliert. Leg neben die package.json eine index.js, die den kompilierten Server lädt (das Beispiel braucht "type": "module"; in CommonJS schreibst du require("./dist/server.js")), und lass das start-Skript auf die kompilierte Datei zeigen, etwa node dist/server.js, nicht auf ein Dev-Tool. index.js

   import "./dist/server.js";

4. App anlegen und Variablen setzen Lege im Dashboard eine Application aus deinem GitHub-, GitLab-, Bitbucket- oder Gitea-Repository an und wähle Branch und Region EU Central. Variablen, die dein build-Skript liest, brauchen auf dem Tab Environment das Häkchen Build; alle anderen gibt es nur zur Laufzeit. API-Keys markierst du als Secret.
5. PostgreSQL anhängen und Migrationen ausführen Lege eine PostgreSQL-Datenbank in derselben Region an und hänge sie auf dem Tab Environment an: Ab dem nächsten Deploy liest deine App DATABASE_URL. Eine release:-Zeile in einer Procfile läuft bei jedem Build einmal, nach dem Build und bevor die neue Version startet; scheitert sie, bleibt die laufende Version live. Procfile

   release: npm run migrate

6. Pushen und deployen Jeder Push auf den Branch baut ein neues Release. Der Traffic wechselt, sobald / mit 2xx oder 3xx antwortet. Antwortet deine API auf / mit 404, leg eine Route wie /health an und trag sie in den App-Einstellungen als Health-Check-Pfad ein.

Gut zu wissen

• Vite in der package.json heißt statische SiteSteht vite in dependencies oder devDependencies, baut Nodion das Repository als statische Site und liefert nur den Build-Output aus, auch wenn es eine server.js gibt. Dasselbe gilt für Angular, Gatsby, Create React App und Eleventy. Für einen Node.js-Server, der zusätzlich ein Vite-Frontend baut, nimm ein Dockerfile.
• BunMit einer bun.lock installiert Nodion deine Dependencies und baut mit Bun. Gestartet wird die App trotzdem über das start-Skript, es muss Bun also selbst aufrufen, etwa "start": "bun run index.ts"; ohne start-Skript startet Nodion die App mit node. Die Regel zur Einstiegsdatei oben gilt auch für Bun-Projekte.
• Queue-WorkerSchreib web: node server.js und worker: node worker.js in eine Procfile; ohne web:-Zeile wird der erste Procfile-Eintrag außer release: zum Standardbefehl. Dann legst du auf dem Tab Processes einen Prozess worker ohne Port an. Valkey in derselben Region liefert deiner Queue eine REDIS_URL.

Was Nodion für dich betreibt

• Deploys ohne Downtime Push auf deinen Branch und Nodion baut ein neues Release. Der Traffic wechselt erst, wenn die neuen Instanzen ihren Health Check bestehen; ein fehlgeschlagenes Release lässt das laufende stehen. Apps mit lokalem Volume starten stattdessen neu, weil die Disk zu einer Instanz gehört.
• Datenbanken neben der App Managed PostgreSQL, pgvector, MySQL, Valkey und ClickHouse in derselben Region. Angehängte Datenbanken kommen als DATABASE_URL, REDIS_URL oder CLICKHOUSE_URL in die App.
• Previews pro Pull Request Schalte Previews ein, und Pull Requests aus deinem Repository bekommen eine eigene App mit eigener URL und frischen, leeren Datenbanken, automatisch oder per Hand angelegt. Forks und Bot-Pull-Requests werden übersprungen.
• Worker, Cron Jobs und Skalierung Worker laufen als weitere Prozesse derselben App, Jobs planst du auf dem Tab Cron, und jeden Prozess skalierst du auf bis zu 16 Instanzen.
• Release-Schritt Mit Buildpacks läuft eine release:-Zeile in der Procfile bei jedem neuen Build. Dockerfile-Apps sowie Redeploys und Rollbacks auf ein früheres Image nutzen einen Release Command, der an der App selbst gesetzt ist; er hat auch Vorrang vor der Procfile-Zeile. Bei statischen Sites läuft ein Release-Schritt in einem Image, das nur die gebauten Dateien enthält.
• Logs und Metriken Build-, Release- und Laufzeit-Logs sowie CPU-, Speicher-, Disk- und Netzwerk-Metriken für jede Instanz im Dashboard.
• Domains und HTTPS Ein Default-Hostname mit HTTPS ab dem ersten Deploy; deine eigenen Domains bekommen automatisch Zertifikate.

Weiterlesen

• Heroku-Alternativen mit EU-Hosting: 5 Optionen im Vergleich Eine deutsche Plattform und US-Clouds mit EU-Regionen, verglichen nach Sitz, Regionen und Managed Databases.
• Dockerfile vs Buildpacks: was solltest du nutzen? Beide machen aus deinem Code ein Container-Image. Der Unterschied ist, wer die Build-Schritte schreibt, und das entscheidet über Kontrolle, Wartung und Security-Updates.

Node.js auf Nodion: Fragen und Antworten