Wie Man Node.js auf einem VPS Ausführt

Heroku hat seine kostenlose Stufe abgeschafft und den Preis angehoben. Vercel berechnet pro Platz und beendet lang laufende Jobs. Render und Railway staffeln ihre Preise nach Verkehrsaufkommen.

Öffne die aktuellste Rechnung von deinem Hosting-Anbieter. Die Node-App, eine Postgres-Datenbank und ein Redis-Cache. Drei Posten, drei Sätze von Überschreitungswarnungen, ein hektischer Slack-Thread am Tag, an dem das Marketing endlich eine Kampagne startet.

Deshalb werfen viele Teams einen erneuten Blick auf das VPS. Node.js selbst ist es egal, wo es ausgeführt wird. Das einzige, vor dem Serverless dich schützte, war herauszufinden, was nach dem ‘npm start’ passiert.

Lass uns ein Produktions-Setup-Muster für Node.js auf einem Linux-Server betrachten, den Du kontrollierst. Wenn Du Dich per SSH auf einen Server einloggen und eine Konfigurationsdatei lesen kannst, wirst Du am Ende einen Produktionsstack haben, den Du jahrelang mit ein paar Stunden Wartung pro Monat betreiben kannst.

Wann Macht Es Sinn, Node.js Auf Einem VPS Zu Betreiben?

Ein VPS ist das richtige Zuhause für Node.js, wenn Du einen dauerhaften Prozess hast, einen Stack, den Du auf eine Rechnung konsolidieren möchtest, oder eine verwaltete Laufzeitumgebung, die die Bequemlichkeit überschritten hat.

Allgemein gesprochen gibt es drei gute Möglichkeiten:

• Langlebige Prozesse: WebSocket-Server, Warteschlangenarbeiter, Cron-Job-Planer, MCP-Server. Alles, was dauerhaft laufen und zuhören muss. Die meisten serverlosen Plattformen optimieren noch immer um kurzlebige Ausführungen und Anforderungslebenszyklen. Ein Node-Prozess auf einem VPS sitzt einfach da.
• Kostenkonsolidierung: Node-App, Postgres, Redis, plus ein kleiner Build-Arbeiter, alle leben auf derselben 4 GB Box. Eine Rechnungszeile, nicht vier.
• Apps, die PaaS entwachsen sind: Funktionstimeouts bei deinem langen PDF-Erstellungsauftrag. Preise pro Sitzplatz in einem Team, das schließlich einen vierten Ingenieur eingestellt hat. Eine Heroku-Rechnung, die über 60 $ pro Monat für eine Arbeitslast steigt, die auf einem 15 $ VPS einwandfrei läuft.

Und es gibt drei falsche Passungen:

• Statische Seiten und SSG-Inhalte: Ein Next.js-Export, ein Astro-Build, ein Gatsby-Blog. Die kostenlose Version von Vercel ist das richtige Werkzeug. Ein VPS ist übertrieben.
• Sporadische, ereignisgesteuerte Arbeitslasten: AWS Lambda oder Cloudflare Workers kosten nur wenige Cents für einen Webhook, der zehnmal am Tag ausgeführt wird. Ein VPS kostet gleich viel, egal ob die App beschäftigt ist oder schläft.
• Horizontal skalierte Echtzeit-Apps: Wenn dein WebSocket-Server 100.000 gleichzeitige Verbindungen verteilen muss, ist ein VPS nicht die Antwort. Das ist ein Kubernetes-Cluster, eine verteilte Edge-Infrastruktur oder eine verwaltete Echtzeit-Plattform.

JavaScript ist die am häufigsten verwendete Sprache in der 2025 Stack Overflow Entwicklerumfrage, und Node.js bleibt eine der Standardmethoden, mit denen Entwickler JavaScript im Backend ausführen. Das sind viele Personen, die Node irgendwo ausführen. Dieser Artikel ist für den Teil von ihnen, der es vorziehen würde, es auf einem Server zu betreiben, den sie selbst kontrollieren.

Ich habe gesehen, wie Teams vier Produktions-Node-Dienste von Heroku auf einen einzigen 4 GB VPS umgezogen haben, mit der gleichen Betriebszeit, einem Drittel der Rechnung und langlebigen WebSockets, die endlich ohne Umweg funktionierten.

Die Migration besteht hauptsächlich aus einem Nachmittag mit ‚apt install‘, einem ‚pm2 start‘ und einer DNS-Änderung.

Welche VPS-Spezifikationen Benötigt Node.js Wirklich?

Node.js selbst ist leichtgewichtig. Ein minimaler Express-Server kann im Leerlauf gut unter 100 MB Arbeitsspeicher verbleiben. Der Rat „Node benötigt nur 1 GB“, den man immer noch auf älteren Blogs findet, ist technisch korrekt und praktisch nutzlos. Bis du Postgres, Redis, Protokolle und einen Bereitstellungsprozess hinzugefügt hast, der nicht nur auf Hoffnung basiert, überschreitest du bereits an einem ruhigen Tag diese Grenze.

Realistische Größen für häufige Arbeitslasten:

Arbeitslast	RAM	vCPU	Speicher	Notizen
Kleine Express-API, keine DB auf dem Server	2 GB	1-2	40 GB NVMe	Realistische Untergrenze für eine Produktions-App
Node API + Postgres + Redis auf einem Server	4 GB	2	80 GB NVMe	Der ideale Mittelweg; hier landen die meisten Teams
SSR-intensive App (Next.js, Nuxt, Remix)	8 GB	4	80 GB NVMe	SSR-Rendering und Build-Pipelines sind die Speicherfresser
Echtzeit/WebSocket-App, moderater Maßstab	8 GB	4	80 GB NVMe	Jede dauerhafte Verbindung verbraucht Speicher

Einige Details, die Du klären solltest, bevor Du provisions:

• NVMe-Speicher Ist Wichtiger Als Reine Festplattengröße: Moderne Node-Apps greifen während der Installation, beim Aufbau und beim Start auf Tausende von kleinen Dateien zu. Langsame Festplatten verschlechtern spürbar die Installation von Abhängigkeiten, Kaltstarts und SSR-Neuaufbauten.
• KVM-Virtualisierung, Nicht OpenVZ: Ältere OpenVZ-basierte Pläne teilen sich einen Kernel mit dem Host, was veraltete Kernel-Versionen und gelegentliche Kompatibilitätsprobleme mit neueren Laufzeiten bedeuten kann. Die meisten renommierten VPS-Anbieter sind jetzt nur noch KVM, aber es lohnt sich immer noch, dies zu überprüfen.
• Swap-Speicher: Aktiviere 1-2 GB Swap auf kleineren Boxen. Der V8-Speicherhaufen von Node kann während der Müllsammlung stark schwanken. Ohne Swap führt ein vorübergehender Spitzenwert zum Absturz des Prozesses. Ich habe gesehen, wie eine 4 GB Box während eines routinemäßigen Deployments einen OOM-Fehler hatte, weil jemand Swap deaktiviert hatte, da er es für ein Anachronismus der Docker-Ära hielt.
• Bandbreite: Die meisten modernen VPS-Pläne beinhalten 1-4 TB monatliche Bandbreite, genug für fast alles außer Videohosting. Selbstverwaltete VPS-Pläne beinhalten ungemessene Bandbreite, eine weniger Zeile auf dem Kapazitätsplanungs-Worksheet.

Ein 4 GB VPS kostet etwa 15 $ pro Monat zum Marktpreis. Das sind 50 Cent pro Tag oder etwa einen Flughafenkaffee alle zwei Wochen. Verglichen mit den Kosten für separat verwaltete App-Runtimes, Managed Postgres und Redis auf einer PaaS, ändern sich die wirtschaftlichen Vorteile überraschend schnell.

Welche Node.js-Version Solltest Du Installieren?

Installiere Node.js 24 (Codename Krypton). Es ist die aktuelle aktive LTS-Version, die im Oktober 2025 eingeführt und gemäß dem offiziellen Node.js-Veröffentlichungsplan bis April 2028 unterstützt wird.

Viele Anleitungen verweisen immer noch auf Node 22. Diese Anleitungen wurden nicht aktualisiert. Wenn Du heute eine neue Bereitstellung beginnst, fixiere Dein CI-Image und Dein VPS auf Node 24.x.

Version	Codename	Status	EOL
Node.js 26.x	(keiner)	Aktuell	Wird Ende 2026 zu LTS
Node.js 24.x	Krypton	Aktives LTS	April 2028
Node.js 22.x	Jod	Wartungs-LTS	April 2027
Node.js 20.x	Eisen	Ende des Lebenszyklus	EOL erreicht am 30. April 2026. Nicht verwenden.

Ein paar Faustregeln:

• Verwende keine aktuellen (nicht-LTS) Versionen in der Produktion: Node 26 dient dem Testen zukünftiger Kompatibilität und neuer Laufzeitfunktionen, nicht für die App, von der deine Einnahmen abhängen.
• Node 22 ist die Ausweichoption, falls eine kritische Abhängigkeit noch nicht mit der Kompatibilität von Node 24 aufgeholt hat: Die meisten Teile des Ökosystems stabilisierten sich innerhalb weniger Monate nach der LTS-Promotion.
• Fixiere deine Node-Version überall: Dein CI-Image, Dockerfile, .nvmrc und produktives VPS sollten alle übereinstimmen. „Funktioniert auf meinem Rechner“ wird schnell teuer, sobald native Module ins Spiel kommen.

🤔Bun in Betracht ziehen? Es ist bei einigen Arbeitslasten schneller und wirklich beeindruckend, aber das Ökosystem ist noch kleiner und die Erfolgsgeschichte in der Produktion kürzer als bei Node. Für die meisten Teams gewinnt das Bewährte.

NodeSource, das die apt und yum Repositories pflegt, von denen viele Produktionsteams Node installieren, hebt Verbesserungen in der 24.x-Linie hervor, beginnend mit einer neueren V8-Engine. Node 24 liefert jetzt auch ausgereifte Werkzeuge wie eingebautes node –watch und einen stabilen nativen Test Runner (node: test), die beide in den Linien 20–22 stabilisiert wurden und hier weitergeführt werden. Nichts davon ist auffällig. Es reduziert einfach jeden Monat ein wenig den operativen Aufwand.

Wie Installierst Du Node.js Auf Einem VPS?

Du hast zwei realistische Installationswege. Wähle je nachdem, ob der Server eine Node-Anwendung oder mehrere ausführt.

NodeSource Für Einen Einzel-App-Server

Dies ist der einfachste Produktionspfad. Ein Einrichtungsskript und ein apt install beschaffen dir die aktuelle Node 24 LTS Reihe als Systempaket, und zukünftige Sicherheitsupdates fließen durch normale Paket-Upgrades.

Auf Ubuntu oder Debian:

curl -fsSL https://deb.nodesource.com/setup_24.x | bash -
apt install -y nodejs

Überprüfe die Installation:

node -v
npm -v

Du solltest eine Node 24.x Veröffentlichung sehen.

Anweisungen für die RHEL-Familien-Distribution (yum/dnf) befinden sich im offiziellen NodeSource-Distributionsrepository.

nvm für Versionswechsel pro Projekt

nvm (Node Version Manager) installiert Node in Deinem Home-Verzeichnis und ermöglicht es verschiedenen Projekten, unterschiedliche Node-Versionen zu verwenden. Nützlich, wenn Du mehrere Apps auf demselben Server hostest oder keinen Sudo-Zugang hast.

Führe dies als Deinen App-Benutzer aus, nicht als Root:

curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.5/install.sh | bash

Lade deine Shell neu, dann installiere Node 24:

nvm install 24
nvm use 24
nvm alias default 24

👉Eine wichtige Regel: Verwende nicht sudo ‘npm install -g’ für Anwendungsabhängigkeiten.

Globale Installationen sind normalerweise für maschinenübergreifende CLI-Tools wie pm2, typescript oder nodemon reserviert. Deine App-Abhängigkeiten gehören in die package.json und sollten vom Projektverzeichnis aus mit npm ci installiert werden.

NodeSource	nvm
Eine Node-Version pro Server	Mehrere Node-Versionen pro Server
Systemweit installiert, läuft als beliebiger Nutzer	Pro Nutzer installiert
Auto-Updates mit ‘apt’	Manuell verwaltet
Erfordert sudo	Kein sudo erforderlich

Wenn du dir unsicher bist, starte mit NodeSource. Die meisten Produktionsserver mit einem einzigen Zweck benötigen keinen projektbezogenen Wechsel der Node-Version.

👉DreamHost Selbstverwaltete VPS-Nutzer: Die bei der Bereitstellung verfügbare Node-App wird mit Node 22 LTS ausgeliefert — noch unterstützt bis April 2027. Um Node 24 zu verwenden, nutze die NodeSource- oder nvm-Schritte oben nach der Bereitstellung.

Solltest Du PM2 Oder Systemd Verwenden, Um Deine App Am Laufen Zu Halten?

Beide funktionieren. Die ehrliche Antwort ist, welche dein Team bevorzugt. PM2 ist der entwicklerfreundliche Weg. systemd ist der Unix-native Weg. Beide lösen dieselben drei Probleme: Neustart bei Absturz, Start bei Boot und sanftes Herunterfahren bei ‘SIGTERM’.

Wenn Du neu anfängst, so wählst Du aus:

	PM2	systemd
Einrichtungszeit	3 Minuten	10 Minuten
Clustermodus (Mehr-Kern)	Integriert	Nicht integriert (Starte N Einheiten)
Log-Rotation	Modul: ‘pm2-logrotate’	Integriert über ‘journalctl’
Neuladen ohne Ausfallzeit	‘pm2 reload’	Üblicherweise manuell gehandhabt mit rollenden Neustarts oder mehreren Einheiten
Speicherbedarf (Dämon)	Kleiner Dämon-Overhead	Keiner (kein zusätzlicher Dämon)
Am besten für	Einzelbox, JS-Shop, schnelle Iteration	Mehr-App-Boxen, Wohlfühlen des Operations-Teams

Der PM2 Schnellstart ist genau das, schnell:

npm install -g pm2
pm2 start app.js --name api
pm2 startup    # gibt den systemd-Startbefehl aus, der ausgeführt werden soll
pm2 save       # speichert die aktuelle Prozessliste

PM2 wird dann zum einzigen, mit dem Du sprichst: ‚pm2 logs‘, ‚pm2 reload api‘, ‚pm2 monit‘.

👉Auch wissenswert: ‚pm2 startup‚ schreibt eine systemd-Einheit, sodass die PM2-Konfiguration tatsächlich systemd unter der Haube verwendet.

Ein minimales systemd-Unit für die direkte Node-Verwaltung unter ‚/etc/systemd/system/api.service‘:

[Unit]
Beschreibung=Meine Node API
Nach=network.target

[Service]
Type=simple
User=app
WorkingDirectory=/var/www/api
ExecStart=/usr/bin/node server.js
Restart=on-failure
RestartSec=5
Environment=NODE_ENV=production
StandardOutput=journal
StandardError=journal

[Install]
WantedBy=multi-user.target
Dann ‘systemctl enable --now api.’ Protokolle findest Du in ‘journalctl -u api -f.’

Wenn Du bereits PM2 verwendest und es funktioniert, migriere nicht zu systemd nur weil jemand auf Hacker News es gesagt hat. Der Speicher des PM2-Dämons ist nicht der Grund, warum Du von ihm weg migrieren würdest.

Migriere, wenn Du einen echten Grund hast, beispielsweise wenn Du ein halbes Dutzend Node-Prozesse betreibst, bei denen jeder Megabyte zählt, oder in eine Betriebsumgebung versendest, in der jeder andere Dienst eine systemd-Einheit ist und PM2 als die ungewöhnliche Ausnahme hervorsticht.

Wie Setzt Du NGINX (oder Caddy) Vor Deine Node-App?

Du möchtest einen Reverse-Proxy vor Node aus fünf Gründen: HTTPS-Terminierung, gzip/brotli-Kompression, Auslieferung von statischen Assets, mehrere Apps auf demselben Server betreiben und einfacheres Ratenlimiting. Node kann all diese Dinge tun. NGINX und Caddy machen sie besser, und sie stürzen deine Ereignisschleife nicht ab, wenn etwas nicht funktioniert.

Wähle NGINX, wenn jemand in deinem Team es bereits kennt. Wähle Caddy, wenn du HTTPS in drei Zeilen Konfiguration möchtest und du mit einem kleineren fortgeschrittenen Konfigurations-Ökosystem zufrieden bist.

Minimale NGINX-Konfiguration

Platziere diesen Proxy-Block in /etc/nginx/sites-available/api, erstelle einen Symlink zu sites-enabled, dann nginx -t && systemctl reload nginx.

server {
    listen 80;
    server_name api.example.com;

    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection 'upgrade';
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_cache_bypass $http_upgrade;
    }
}

Die ‚Upgrade‘- und ‚Connection‘-Überschriften sind die WebSocket-Unterstützungslinien. Die eigenen Dokumente von NGINX weisen darauf hin, dass Upgrade ein Hop-by-Hop-Header ist, daher benötigt es eine explizite Behandlung, wenn WebSocket-Traffic weitergeleitet wird.

Lass sie drin, wenn Deine App jetzt WebSockets verwendet oder später verwenden könnte. Socket.IO, GraphQL-Abonnements über WebSockets und eine überraschende Anzahl von „regulären“ Echtzeitfunktionen hängen von diesem Upgrade-Handshake ab.

Der weitaus häufigste Produktionsfehler, den ich in Node-Setups sehe, ist ein Socket.IO-Server hinter NGINX ohne diese beiden Zeilen. Verbindungen schlagen gelegentlich fehl, Entwickler geben Socket.IO die Schuld, und das eigentliche Problem liegt meistens in der Proxy-Konfiguration.

Minimale Caddyfile

Die Caddy Reverse-Proxy Schnellstart Version desselben:

api.example.com {
    reverse_proxy 127.0.0.1:3000
}

Das ist die gesamte Datei. Solange die Domain auf den Server zeigt und die Ports 80/443 erreichbar sind, stellt Caddy HTTPS automatisch bereit und erneuert es. Caddys Dokumentation besagt, dass automatisches HTTPS TLS-Zertifikate für Websites bereitstellt und diese erneuert; auch die Schnellstartanleitung für den Reverse-Proxy weist darauf hin, dass HTTPS automatisch ist, wenn Caddy den Hostname kennt.

Node An localhost Binden, Nicht An 0.0.0.0

Welchen Proxy Du auch wählst, konfiguriere deine Node-App so, dass sie auf 127.0.0.1:3000 und nicht auf 0.0.0.0:3000 hört. Das Einzige, was dem öffentlichen Internet auf einem Node-Box gegenüberstehen sollte, ist der Proxy. Kombiniere dies mit UFW, Ubuntus gängiger Firewall-Frontend, um alles außer den Ports 22, 80 und 443 zu blockieren.

ufw standardmäßig eingehende Verbindungen verweigern
ufw erlaube 22/tcp
ufw erlaube 80/tcp
ufw erlaube 443/tcp
ufw aktivieren

Wenn SSH auf einem benutzerdefinierten Port läuft, erlaube diesen Port, bevor UFW aktiviert wird.

Binde von Anfang an an localhost. Das Meeting, bei dem jemand zugibt, dass „die App exponiert war, weil Node an 0.0.0.0 gebunden war“, ist kein Meeting, das Du haben möchtest.

Wie Richtest Du HTTPS Für Deine Node.js-App Ein?

Nutze Let’s Encrypt. Es ist kostenlos, automatisiert und von jedem Browser vertraut. Es gibt zwei Wege, abhängig davon, welchen Proxy Du gewählt hast.

NGINX + Certbot

Richte einen A-Eintrag auf deine VPS-IP aus und warte, bis die DNS sich verbreitet hat.

Installiere Certbot:

apt install certbot python3-certbot-nginx

Starte:

certbot --nginx -d api.example.com

Certbot aktualisiert deine NGINX-Konfiguration und lädt den Server automatisch neu.

Auf modernen Ubuntu-Versionen wird die Erneuerung automatisch durch einen systemd-Timer gehandhabt, der vom Certbot-Paket installiert wird.

Öffne https://api.example.com und bestätige das Schloss-Symbol.

Die offiziellen Certbot-Dokumentationen behandeln auch den Snap-basierten Installationspfad, falls dein Distributionspaket veraltet ist.

Caddy

Füge die Domain zur Caddydatei hinzu (das obige Beispiel enthält sie bereits), dann starte Caddy neu. Solange die Domain korrekt aufgelöst wird und die Ports 80/443 erreichbar sind, wird das Zertifikat automatisch beim ersten Start bereitgestellt. Es gibt keinen Certbot.

Beende TLS in Node selbst nicht für die Produktion.

Node’s https-Modul funktioniert einwandfrei, aber Reverse-Proxies wie NGINX und Caddy sind speziell für die TLS-Terminierung entwickelt. Sie bieten dir OCSP-Stapling, moderne Chiffre-Standards, automatische Zertifikatserneuerung, HTTP/2-Unterstützung und — im Fall von Caddy — HTTP/3-Unterstützung direkt ab Werk.

Könntest Du das alles direkt in Node handhaben? Sicher. Du würdest einfach eine Infrastruktur neu aufbauen, die Dein Proxy bereits sehr gut löst.

Wie Sieht Ein Produktionsfertiges Node.js-Setup Eigentlich Aus?

Acht Dinge beißen Menschen in der Produktion. Die meisten davon sind nicht in Installationsanleitungen enthalten, weil sie nicht in das Schema „Node installieren, App ausführen“ passen. Sie sind der Unterschied zwischen einer App, die den zweiten Monat überlebt, und einer, die es nicht tut.

• NODE_ENV=production: Der am häufigsten übersehene Schritt. In vielen Node-Frameworks und -Bibliotheken deaktiviert es verhaltensweisen, die nur in der Entwicklung vorhanden sind und aktiviert Optimierungen für die Produktion. Express beispielsweise speichert kompilierte Vorlagen im Cache und gibt knappere Fehlermeldungen in der Produktionsumgebung zurück — die eigenen Dokumentationen sprechen von einer bis zu 3-fachen Leistungsverbesserung. Setze die ‘env var’ überall.
• Graceful shutdown: Wenn dein VPS neu startet oder PM2 ‘SIGTERM’ sendet, hat deine App ein paar Sekunden Zeit, um laufende Anfragen abzuarbeiten, Datenbankverbindungen zu schließen und sauber zu beenden. Richte einen ‘process.on(‚SIGTERM‘, …)‘-Handler ein. Die Standardabschaltzeit von PM2 hängt von der Konfiguration und Umgebung ab, also gehe nicht davon aus, dass du immer viel Zeit zum Aufräumen hast. 
• Log-Rotation: PM2’s ‘pm2-logrotate’ Modul kümmert sich darum für PM2. Das systemd-Journal handhabt es für direkte systemd-Einheiten. Ohne Rotation füllen deine Logs die Festplatte in einem Viertel der erwarteten Zeit.
• .env Disziplin: Niemals Geheimnisse einreichen, niemals protokollieren. Verwende ‘dotenv’ für lokale Entwicklung. In der Produktion, setze Umgebungsvariablen über ‘Environment=’ deiner systemd-Einheit oder deine PM2-Ökosystemdatei. Der Tag, an dem du ‘console.log(process.env)’ aus Versehen machst, ist der Tag, an dem du jede Anmeldeinformation rotierst.
• Ein umgekehrter Proxy vor Node: Binde Node an localhost; lass NGINX oder Caddy das öffentliche Internet bedienen.
• Eine Firewall: UFW lehnt alles ab außer 22, 80, 443. SSH von Port 22 zu verschieben, wird einen entschlossenen Angreifer nicht stoppen, aber es reduziert drastisch den automatisierten Brute-Force-Lärm und Junk-Auth-Protokolle.
• Überwachung: Ein Healthcheck-Endpunkt, den dein Überwachungstool jede Minute abruft. PM2 hat grundlegende Funktionen integriert. Für alles Ernsthaftes, betreibe Prometheus und Grafana oder nutze einen gehosteten Uptime-Dienst wie Better Stack oder UptimeRobot. Du willst wissen, dass deine App offline ist, bevor ein Kunde es dir sagt.

Wartungsschätzung für den oben genannten Stack: ein bis drei Stunden pro Monat.

Apt-Aktualisierungen, gelegentliche Abhängigkeitsaktualisierungen und ein vierteljährlicher Blick auf das Protokollvolumen. Das ist der Tausch für die Kosten- und Kontrollvorteile.

Wann Ist Ein VPS Die Falsche Wahl Für Node.js?

Ein VPS ist die falsche Wahl, wenn deine Arbeitslast für etwas anderes ausgelegt ist. Sei ehrlich darüber, auf welcher Seite du stehst, bevor du bereitstellst.

• Statische Seiten und SSG-Inhalte: Next.js-Export, Astro, Gatsby und ein Eleventy-Blog. Plattformen wie Vercel, Netlify oder Cloudflare Pages bieten weltweit gecachtes statisches Hosting, Git-basierte Deployments und automatische Neubauten direkt aus der Box. Ein VPS ist normalerweise keine notwendige Infrastruktur für rein statische Inhalte.
• Sporadische, ereignisgesteuerte Workloads: Cloudflare Workers und AWS Lambda sind kostengünstig für Webhooks, die zehnmal pro Tag ausgeführt werden. 
• Echtzeit-Apps, die 100.000+ gleichzeitige Verbindungen benötigen: Ein VPS skaliert nicht horizontal. Du benötigst Orchestrierung (Kubernetes, ECS, Nomad) oder eine verwaltete Echtzeit-Plattform wie Ably oder Pusher.
• Compliance-intensive regulierte Workloads: HIPAA, PCI-DSS Level 1, FedRAMP. Eine verwaltete PaaS mit integrierten Compliance-Zertifizierungen erspart Prüfungsschmerzen. Compliance selbst auf einem VPS zu hosten ist ein mehrquartaliges Projekt, das Du wahrscheinlich nicht möchtest.
• Keine Linux-Kenntnisse — und kein Interesse, diese zu entwickeln: Plattformen wie Render, Railway und DigitalOcean App Platform liegen irgendwo zwischen rohem VPS-Hosting und vollständig verwaltetem PaaS. Werkzeuge wie Dokploy fügen Heroku-artige Bereitstellungsworkflows auf deiner eigenen VPS-Infrastruktur hinzu. Du erhältst immer noch viele der Kosten- und Kontrollvorteile, ohne dich tiefgehend mit iptables, Systemd-Interna oder Reverse-Proxy-Debugging um 1 Uhr morgens befassen zu müssen.

Es gibt keinen Grund, sich für eine dieser Antworten zu schämen. Die beste technische Entscheidung ist die, die zu deiner Arbeitslast passt.

Deinen Node-Stack Auswählen Und Einziehen

Öffne diese Hosting-Rechnung noch einmal.

Du wirst eine überraschend große Menge davon durch eine einzelne VPS-Rechnung ersetzen.

👉Der Stapel: Ubuntu 24.04 LTS, Node 24, PM2 (oder systemd), NGINX (oder Caddy), Let’s Encrypt über Certbot (oder integriert in Caddy).

Richte den kleinsten VPS-Tarif ein, der zu dem von dir berechneten RAM passt, installiere Node, betreibe deine App auf ‚127.0.0.1‘, richte NGINX darauf aus und wechsle deine DNS.

Wenn die App ein Deployment, einen Neustart und einen nächtlichen Lauf ohne Probleme übersteht, bist Du fast am Ziel.

Der Rest ist Wartung. Eine oder zwei Stunden im Monat, gelegentlich ein ‚apt upgrade‘ Fenster, ein vierteljährliches Abhängigkeitsupdate. Das ist der Deal, den Du gemacht hast, als Du eine pro-Sitz-Rechnung gegen eine Pauschalrechnung getauscht hast, und DreamHosts Selbstverwaltetes VPS Stack 4 ist der Punkt, an dem Du starten kannst.

Häufig gestellte Fragen zum Betrieb von Node.js auf einem VPS

Kann Ich Node.js Auf Jedem VPS Ausführen?

Die meisten modernen VPS-Pläne führen Node.js problemlos aus. Moderne auf KVM basierende VPS-Pläne mit einem 64-Bit Linux-Distro sind die sicherste Standardwahl für aktuelle Node.js-Versionen.

Ältere OpenVZ-basierte Pläne haben manchmal Kernel-Beschränkungen, die neuere Node-Versionen beeinträchtigen. Wenn Du zwischen Anbietern wählst, frage, ob sie auf KVM basieren.

Wie viel RAM benötigt Node.js auf einem VPS?

Ein minimaler Express-Server ist im Leerlauf deutlich unter 100 MB, aber eine realistische Produktions-App mit Middleware, Protokollierung und einer Verbindungspool liegt typischerweise im Bereich von 150-300 MB.

Das realistische Minimum für eine Produktions-App beträgt 2 GB; der Idealfall für einen Node + Postgres + Redis Stack ist 4 GB. DreamHosts selbstverwaltetes VPS Stack 4 (4 GB) bewältigt die meisten Produktions-Workloads von Node. Wechsle zu Stack 8 (8 GB) für SSR-intensive oder Echtzeit-Apps.

Was ist die aktuelle Node.js LTS-Version?

Die aktuelle aktive LTS ist Node.js 24.x („Krypton“), eingeführt am 28. Oktober 2025 und unterstützt bis April 2028. Node.js 22.x („Jod“) befindet sich in der Wartungs-LTS bis April 2027, falls eine Abhängigkeit eine Rückwärtskompatibilität erfordert. Node.js 26 wurde am 5. Mai 2026 gestartet und wird im Oktober 2026 zu LTS befördert.

Die meisten Produktionsteams halten sich an LTS-Versionen, es sei denn, sie benötigen speziell neuere Laufzeitfunktionen.

Brauche ich PM2, wenn ich systemd habe?

Nein, Du brauchst nicht beides. PM2 und systemd lösen das gleiche Problem: Sie halten Deine Node-App auch bei Abstürzen und Neustarts am Laufen. Viele auf Node spezialisierte Teams wählen PM2 wegen des integrierten Clusterings, der Protokollverwaltung und der Reload-Tools.

Teams, die bereits systemd-Einheiten für alles andere verwenden, wählen systemd.

Warum NGINX vor Node.js setzen?

NGINX (oder Caddy) vor Node.js zentralisiert die TLS-Beendigung, Komprimierung, das Bereitstellen statischer Assets und die Ratenbegrenzung in einer speziell für das Proxying und Web-Hosting entwickelten Software.

Es ermöglicht Dir auch, mehrere Node-Apps auf demselben VPS ohne Portkonflikte auszuführen. In der Produktion hört Node auf localhost; NGINX steht dem öffentlichen Internet gegenüber.

Ist Node.js auf einem VPS günstiger als bei Heroku oder Vercel?

Ja, oft. Ein 4 GB VPS liegt üblicherweise im Bereich von 15 bis 25 Dollar pro Monat und kann die getrennt berechneten Kosten für App-Laufzeit, Datenbank und Cache auf vielen PaaS-Plattformen zusammenfassen.

Vercel Pro-Preise basieren auf Sitzen, und serverlose Plattformen legen weiterhin Ausführungsdauerbeschränkungen abhängig von Laufzeit und Plan fest.

Der Handel besteht darin, dass Du die Operationen selbst durchführst, etwa ein bis drei Stunden pro Monat.

Kann ich mehrere Node-Apps auf einem VPS ausführen?

Ja, und es ist der häufigste Grund, warum Teams von PaaS zu einem VPS wechseln. Führe jede App auf ihrem eigenen internen Port (3000, 3001, 3002) aus und leite den Verkehr mit NGINX-Serverblöcken nach Hostname um. PM2 verwaltet alle als separate Prozesse; systemd verwendet eine Einheitsdatei pro App.

Ein 4 GB VPS kann oft mehrere leichtgewichtige Node-Dienste zusammen mit einer kleinen Datenbank-Workload bewältigen.

Kann Ich Node.js Auf DreamHost Shared Hosting Ausführen?

Nein. Node.js benötigt persistente Prozesse, Paketinstallationen auf Root-Ebene und direktes Port-Binding, die alle vom Shared Hosting nicht bereitgestellt werden. DreamHosts selbstverwaltete VPS-Pläne (Stack 4 und höher) eignen sich für Node-Workloads mit vollem Root-Zugriff, NVMe-Speicher und unbegrenzter Bandbreite.