So betreibst du Node.js auf einem VPS

Heroku hat seinen kostenlosen Tarif abgeschafft und den Mindestpreis angehoben. Vercel rechnet pro Platz ab und bricht lang laufende Jobs per Timeout ab. Bei Render und Railway steigt der Preis mit dem Traffic.

Öffne die letzte Rechnung deines Hosting-Anbieters. Die Node-App, eine Postgres-Datenbank und ein Redis-Cache. Drei Posten, drei Sätze an Warnungen vor Mehrkosten und ein hektischer Slack-Thread an dem Tag, an dem das Marketing endlich eine Kampagne startet.

Genau wegen dieser Rechnung schauen sich viele Teams den VPS noch einmal genauer an. Node.js selbst ist es egal, wo es läuft. Das Einzige, wovor Serverless dich bewahrt hat, war herauszufinden, was nach ‚npm start‘ passiert.

Schauen wir uns ein Muster für ein Produktions-Setup mit Node.js auf einem Linux-Server an, den du kontrollierst. Wenn du dich per SSH auf einem Server anmelden und eine Konfigurationsdatei lesen kannst, hast du am Ende einen Produktions-Stack, den du jahrelang mit ein paar Stunden Wartung pro Monat betreiben kannst.

Wann lohnt es sich, Node.js auf einem VPS zu betreiben?

Ein VPS ist das richtige Zuhause für Node.js, wenn du einen langlebigen Prozess hast, einen Stack, den du in einer einzigen Rechnung zusammenfassen willst, oder eine Rechnung für eine verwaltete Laufzeitumgebung, die den Komfort nicht mehr rechtfertigt.

Grob gesagt gibt es drei Fälle, in denen es gut passt:

• Langlebige Prozesse: WebSocket-Server, Queue-Worker, Cron-Scheduler, MCP-Server. Alles, was dauerhaft laufen und auf Anfragen warten muss. Die meisten Serverless-Plattformen sind nach wie vor auf kurzlebige Ausführung und Request-Lebenszyklen optimiert. Ein Node-Prozess auf einem VPS läuft einfach weiter.
• Kostenbündelung: Node-App, Postgres, Redis und ein kleiner Build-Worker laufen alle auf demselben 4-GB-Server. Ein Rechnungsposten statt vier.
• Apps, die PaaS entwachsen sind: Funktions-Timeouts bei deinem langen PDF-Generierungsjob. Preise pro Platz für ein Team, das endlich einen vierten Engineer eingestellt hat. Eine Heroku-Rechnung, die auf über 60 $ im Monat klettert – für einen Workload, der auf einem VPS für 15 $ problemlos läuft.

Und es gibt drei Fälle, in denen es nicht passt:

• Statische Websites und SSG-Inhalte: Ein Next.js-Export, ein Astro-Build, ein Gatsby-Blog. Der kostenlose Tarif von Vercel ist dafür das richtige Werkzeug. Ein VPS wäre übertrieben.
• Sporadische, ereignisgesteuerte Workloads: AWS Lambda oder Cloudflare Workers kosten ein paar Cent für einen Webhook, der zehnmal am Tag läuft. Ein VPS kostet gleich viel, egal ob die App gerade ausgelastet ist oder schläft.
• Horizontal skalierte Echtzeit-Apps: Wenn dein WebSocket-Server 100.000 gleichzeitige Verbindungen bedienen muss, ist ein einzelner VPS nicht die Lösung. Dafür brauchst du einen Kubernetes-Cluster, eine verteilte Edge-Infrastruktur oder eine verwaltete Echtzeit-Plattform.

JavaScript ist laut der 2025 Stack Overflow Developer Survey die meistgenutzte Programmiersprache, und Node.js ist nach wie vor einer der Standardwege, JavaScript im Backend auszuführen. Das sind eine Menge Leute, die Node irgendwo betreiben. Dieser Artikel richtet sich an diejenigen unter ihnen, die es lieber auf einem Server betreiben würden, den sie selbst kontrollieren.

Ich habe gesehen, wie Teams vier Node-Produktionsdienste von Heroku auf einen einzigen 4-GB-VPS umgezogen haben – mit derselben Verfügbarkeit, einem Drittel der Kosten und langlebigen WebSockets, die endlich ohne Workaround funktionierten.

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

Welche VPS-Ressourcen braucht Node.js wirklich?

Node.js selbst ist schlank. Ein minimaler Express-Server kommt im Leerlauf mit deutlich unter 100 MB Arbeitsspeicher aus. Der Rat Node braucht nur 1 GB, den du noch in älteren Blogs findest, ist technisch korrekt und praktisch nutzlos. Sobald du Postgres, Redis, Logs und einen Deployment-Prozess hinzugefügt hast, der nicht nur von Hoffnung zusammengehalten wird, liegst du schon an einem ruhigen Tag darüber.

Realistische Dimensionierung für gängige Workloads:

Ein paar Details, die du vor der Bereitstellung klären solltest:

• NVMe-Speicher ist wichtiger als die reine Festplattengröße: Moderne Node-Apps greifen bei Installationen, Builds und beim Start auf Tausende kleiner Dateien zu. Langsame Festplatten machen Dependency-Installationen, Kaltstarts und SSR-Rebuilds spürbar langsamer.
• KVM-Virtualisierung, nicht OpenVZ: Ältere OpenVZ-basierte Tarife teilen sich einen Kernel mit dem Host, was veraltete Kernel-Versionen und gelegentliche Kompatibilitätsprobleme mit neueren Laufzeitumgebungen bedeuten kann. Die meisten seriösen VPS-Anbieter setzen inzwischen ausschließlich auf KVM, ein kurzer Check lohnt sich trotzdem.
• Swap-Speicher: Aktiviere auf kleineren Servern 1–2 GB Swap. Der V8-Heap von Node kann bei der Garbage Collection stark schwanken. Ohne Swap killt eine kurzzeitige Spitze den Prozess. Ich habe erlebt, wie ein 4-GB-Server bei einem routinemäßigen Deployment wegen Speichermangel (OOM) abgestürzt ist, weil jemand Swap deaktiviert hatte – in dem Glauben, das sei ein Relikt aus der Docker-Ära.
• Bandbreite: Die meisten modernen VPS-Tarife enthalten 1–4 TB Bandbreite pro Monat. Das reicht für fast alles außer Video-Hosting. Selbstverwaltete VPS-Tarife bieten unbegrenzte Bandbreite, also eine Zeile weniger in der Tabelle für die Kapazitätsplanung.

Ein 4-GB-VPS kostet zu Marktpreisen etwa 15 $ im Monat. Das sind 50 Cent am Tag oder ungefähr ein Flughafenkaffee alle zwei Wochen. Verglichen mit separaten Kosten für App-Laufzeiten, verwaltetes Postgres und Redis auf einer PaaS kippt die Rechnung überraschend schnell.

Welche Node.js-Version solltest du installieren?

Installiere Node.js 24 (Codename Krypton). Es ist das aktuelle Active-LTS-Release, wurde im Oktober 2025 hochgestuft und wird laut dem offiziellen Release-Zeitplan von Node.js bis April 2028 unterstützt.

Viele Tutorials verweisen noch auf Node 22. Diese Anleitungen wurden nicht aktualisiert. Wenn du heute ein neues Deployment startest, lege dein CI-Image und deinen VPS auf Node 24.x fest.

Ein paar Faustregeln:

• Setze in der Produktion keine Current-Releases (ohne LTS) ein: Node 26 ist dazu da, zukünftige Kompatibilität und neue Laufzeitfunktionen zu testen – nicht für die App, an der dein Umsatz hängt.
• Node 22 ist die Ausweichoption, falls eine kritische Abhängigkeit noch nicht mit Node 24 kompatibel ist: Der Großteil des Ökosystems hat sich innerhalb weniger Monate nach der LTS-Hochstufung stabilisiert.
• Lege deine Node-Version überall fest: Dein CI-Image, dein Dockerfile, .nvmrc und der Produktions-VPS sollten übereinstimmen. Läuft auf meinem Rechner wird schnell teuer, sobald native Module ins Spiel kommen.

🤔Du denkst über Bun nach? Bei manchen Workloads ist es schneller und wirklich beeindruckend, aber das Ökosystem ist noch kleiner und die Erfahrung im Produktionseinsatz kürzer als bei Node. Für die meisten Teams gewinnt das Langweilige.

NodeSource, das die apt- und yum-Repositorys pflegt, aus denen viele Produktionsteams Node installieren, hebt Verbesserungen in der 24.x-Linie hervor, angefangen mit einer neueren V8-Engine. Node 24 bringt außerdem inzwischen ausgereifte Tools wie das integrierte node –watch und einen stabilen nativen Test-Runner (node: test) mit – beide wurden in den Linien 20–22 stabil und sind hier weiterhin dabei. Nichts davon ist spektakulär. Es beseitigt einfach jeden Monat ein bisschen Reibung im Betrieb.

Wie installierst du Node.js auf einem VPS?

Es gibt zwei realistische Installationswege. Entscheide danach, ob auf dem Server eine Node-App läuft oder mehrere.

NodeSource für einen Server mit nur einer App

Das ist der einfachste Weg für die Produktion. Ein Setup-Skript und ein apt install liefern dir die aktuelle Node-24-LTS-Linie als Systempaket, und künftige Sicherheitsupdates kommen über ganz normale Paket-Upgrades.

Unter 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 ein Node-24.x-Release sehen.

Anleitungen für Distributionen der RHEL-Familie (yum/dnf) findest du im offiziellen NodeSource-Distributions-Repository.

nvm für Versionswechsel pro Projekt

nvm (Node Version Manager) installiert Node in deinem Home-Verzeichnis und ermöglicht es, dass verschiedene Projekte verschiedene Node-Versionen nutzen. Praktisch, wenn du mehrere Apps auf demselben Server hostest oder keinen sudo-Zugriff hast.

Führe das als dein 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 und installiere dann Node 24:

nvm install 24
nvm use 24
nvm alias default 24

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

Globale Installationen sind in der Regel CLI-Tools auf Systemebene wie pm2, typescript oder nodemon vorbehalten. Die Abhängigkeiten deiner App gehören in die package.json und sollten mit npm ci aus dem Projektverzeichnis installiert werden.

Wenn du unsicher bist, fang mit NodeSource an. Die meisten Produktionsserver mit nur einer Aufgabe brauchen keinen Wechsel der Node-Version pro Projekt.

👉Für Nutzer von DreamHost VPS: Die Node.js-App, die bei der Bereitstellung verfügbar ist, bringt Node.js 24 LTS sowie fnm, PM2, Nginx und Certbot-SSL mit, sodass du die Installationsschritte oben überspringen kannst.

PM2 oder systemd: Was hält deine App am Laufen?

Beides funktioniert. Die ehrliche Antwort: das, womit dein Team vertraut ist. PM2 ist der entwicklerfreundliche Weg. systemd ist der Unix-native Weg. Beide lösen dieselben drei Probleme: Neustart nach einem Absturz, Start beim Booten und sauberes Herunterfahren bei ‚SIGTERM‘.

Wenn du neu anfängst, hilft dir diese Übersicht bei der Wahl:

Der PM2-Schnellstart ist genau das – schnell:

npm install -g pm2
pm2 start app.js --name api
pm2 startup    # prints the systemd startup command to run
pm2 save       # saves the current process list

Danach ist PM2 das Einzige, womit du kommunizierst: ‚pm2 logs‘, ‚pm2 reload api‘, ‚pm2 monit‘.

👉Auch gut zu wissen: ‚pm2 startup‘ schreibt eine systemd-Unit, das PM2-Setup nutzt unter der Haube also tatsächlich systemd.

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

[Unit]Description=My Node APIAfter=network.target

[Service]Type=simpleUser=appWorkingDirectory=/var/www/apiExecStart=/usr/bin/node server.jsRestart=on-failureRestartSec=5Environment=NODE_ENV=productionStandardOutput=journalStandardError=journal

[Install]WantedBy=multi-user.target
Dann ‚systemctl enable --now api‘. Die Logs findest du unter ‚journalctl -u api -f‘.

Wenn du PM2 bereits nutzt und es funktioniert, migriere nicht zu systemd, nur weil jemand auf Hacker News das gesagt hat. Der Speicherverbrauch des PM2-Daemons ist kein Grund für einen Umstieg.

Migriere, wenn du einen echten Grund hast – etwa wenn ein halbes Dutzend Node-Prozesse laufen, bei denen jedes Megabyte zählt, oder wenn du in eine Ops-Umgebung auslieferst, in der jeder andere Dienst eine systemd-Unit ist und PM2 aus der Reihe tanzt.

Wie schaltest du NGINX (oder Caddy) vor deine Node-App?

Es gibt fünf Gründe für einen Reverse Proxy vor Node: HTTPS-Terminierung, gzip-/Brotli-Komprimierung, Auslieferung statischer Assets, mehrere Apps auf demselben Server und einfacheres Rate Limiting. Node kann das alles. NGINX und Caddy können es besser, und sie legen deine Event Loop nicht lahm, wenn etwas schiefläuft.

Nimm NGINX, wenn sich bereits jemand in deinem Team damit auskennt. Nimm Caddy, wenn du HTTPS mit drei Zeilen Konfiguration willst und mit einem kleineren Ökosystem für fortgeschrittene Konfigurationen leben kannst.

Minimale NGINX-Konfiguration

Lege diesen Proxy-Block in /etc/nginx/sites-available/api ab, erstelle einen Symlink nach sites-enabled und führe dann nginx -t && systemctl reload nginx aus.

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 Header ‚Upgrade‘ und ‚Connection‘ sind die Zeilen für die WebSocket-Unterstützung. Die Dokumentation von NGINX weist ausdrücklich darauf hin, dass Upgrade ein Hop-by-Hop-Header ist und beim Proxying von WebSocket-Traffic deshalb explizit behandelt werden muss.

Lass sie drin, wenn deine App jetzt oder später WebSockets nutzt. Socket.IO, GraphQL-Subscriptions über WebSockets und überraschend viele ganz normale Echtzeitfunktionen hängen von diesem Upgrade-Handshake ab.

Der mit Abstand häufigste Produktionsfehler, den ich bei Node-Setups sehe, ist ein Socket.IO-Server hinter NGINX ohne diese beiden Zeilen. Verbindungen brechen sporadisch ab, die Entwickler geben Socket.IO die Schuld, und das eigentliche Problem ist meist die Proxy-Konfiguration.

Minimales Caddyfile

Die Version desselben Setups aus dem Caddy-Reverse-Proxy-Schnellstart:

api.example.com {
    reverse_proxy 127.0.0.1:3000
}

Das ist die ganze Datei. Solange die Domain auf den Server zeigt und die Ports 80/443 erreichbar sind, richtet Caddy HTTPS automatisch ein und erneuert es. Laut der Dokumentation von Caddy stellt automatisches HTTPS TLS-Zertifikate für Websites bereit und hält sie aktuell. Auch der Reverse-Proxy-Schnellstart von Caddy weist darauf hin, dass HTTPS automatisch läuft, sobald Caddy den Hostnamen kennt.

Node an localhost binden, nicht an 0.0.0.0

Egal, welchen Proxy du wählst: Konfiguriere deine Node-App so, dass sie auf 127.0.0.1:3000 lauscht, nicht auf 0.0.0.0:3000. Auf einem Node-Server sollte nur der Proxy mit dem öffentlichen Internet verbunden sein. Kombiniere das mit UFW, dem gängigen Firewall-Frontend von Ubuntu, und blockiere alles außer den Ports 22, 80 und 443.

ufw default deny incoming
ufw allow 22/tcp
ufw allow 80/tcp
ufw allow 443/tcp
ufw enable

Falls SSH auf einem eigenen Port läuft, gib diesen Port frei, bevor du UFW aktivierst.

Binde Node vom ersten Tag an an localhost. Das Meeting, in dem jemand zugeben muss, dass die App offen im Netz stand, weil Node an 0.0.0.0 gebunden war, willst du nicht erleben.

Wie richtest du HTTPS für deine Node.js-App ein?

Nutze Let’s Encrypt. Es ist kostenlos, automatisiert und wird von jedem Browser als vertrauenswürdig eingestuft. Je nachdem, welchen Proxy du gewählt hast, gibt es zwei Wege.

NGINX + Certbot

Richte einen A-Record auf die IP deines VPS und warte, bis sich die DNS-Änderung verbreitet hat.

Installiere Certbot:

apt install certbot python3-certbot-nginx

Führe Folgendes aus:

certbot --nginx -d api.example.com

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

Auf aktuellen Ubuntu-Versionen übernimmt ein systemd-Timer, den das Certbot-Paket installiert, die Erneuerung automatisch.

Öffne https://api.example.com und prüfe, ob das Schloss-Symbol angezeigt wird.

Die offizielle Certbot-Dokumentation beschreibt auch die Installation per Snap, falls das Paket deiner Distribution veraltet ist.

Caddy

Füge die Domain zum Caddyfile hinzu (im Beispiel oben ist sie schon enthalten) und starte Caddy neu. Solange die Domain korrekt aufgelöst wird und die Ports 80/443 erreichbar sind, wird das Zertifikat beim ersten Start automatisch bereitgestellt. Certbot brauchst du dafür nicht.

Terminiere TLS in der Produktion nicht direkt in Node.

Das https-Modul von Node funktioniert einwandfrei, aber Reverse Proxys wie NGINX und Caddy sind speziell für die TLS-Terminierung gebaut. Sie bieten dir OCSP-Stapling, moderne Cipher-Voreinstellungen, automatische Zertifikatserneuerung, HTTP/2-Unterstützung und – bei Caddy – HTTP/3-Unterstützung direkt ab Werk.

Könntest du das alles direkt in Node erledigen? Klar. Du würdest damit nur Infrastruktur nachbauen, die dein Proxy bereits hervorragend abdeckt.

Wie sieht ein produktionsreifes Node.js-Setup wirklich aus?

Acht Dinge sorgen in der Produktion regelmäßig für Ärger. Die meisten stehen in keinem Installations-Tutorial, weil sie nicht in den Ablauf Node installieren, App starten passen. Sie machen aber den Unterschied zwischen einer App, die den zweiten Monat übersteht, und einer, die es nicht tut.

• NODE_ENV=production: Der am häufigsten vergessene Schritt. In vielen Node-Frameworks und -Bibliotheken deaktiviert diese Einstellung Verhalten, das nur für die Entwicklung gedacht ist, und aktiviert Optimierungen für die Produktion. Express zum Beispiel speichert kompilierte View-Templates im Cache und gibt in der Produktion knappere Fehlermeldungen aus – laut der eigenen Dokumentation bringt das bis zu dreifache Performance. Setze die Umgebungsvariable überall.
• Sauberes Herunterfahren: Wenn dein VPS neu startet oder PM2 ‚SIGTERM‘ sendet, hat deine App ein paar Sekunden Zeit, laufende Anfragen abzuarbeiten, Datenbankverbindungen zu schließen und sich sauber zu beenden. Richte dafür einen Handler mit ‚process.on(‘SIGTERM’, …)‘ ein. Wie lange PM2 standardmäßig beim Herunterfahren wartet, hängt von Konfiguration und Umgebung ab. Geh also nicht davon aus, dass du immer viel Zeit zum Aufräumen hast.
• Log-Rotation: Bei PM2 übernimmt das Modul ‚pm2-logrotate‘ diese Aufgabe. Bei direkt genutzten systemd-Units kümmert sich das systemd-Journal darum. Ohne Rotation füllen deine Logs die Festplatte in einem Bruchteil der Zeit, mit der du rechnest.
• Disziplin bei .env: Committe niemals Secrets und schreibe sie niemals in Logs. Nutze ‚dotenv‘ für die lokale Entwicklung. In der Produktion setzt du Umgebungsvariablen über ‚Environment=‘ in deiner systemd-Unit oder über deine PM2-Ecosystem-Datei. An dem Tag, an dem du versehentlich ‚console.log(process.env)‘ ausführst, musst du sämtliche Zugangsdaten austauschen.
• Ein Reverse Proxy vor Node: Binde Node an localhost und lass NGINX oder Caddy die Verbindung zum öffentlichen Internet übernehmen.
• Eine Firewall: Blockiere mit UFW alles außer 22, 80 und 443. SSH von Port 22 wegzuverlegen hält entschlossene Angreifer nicht auf, reduziert aber automatisierte Brute-Force-Versuche und überflüssige Einträge in den Auth-Logs drastisch.
• Monitoring: Ein Healthcheck-Endpunkt, den dein Monitoring-Tool jede Minute abfragt. PM2 bringt grundlegende Funktionen mit. Für alles Ernsthafte nutzt du Prometheus und Grafana oder einen gehosteten Uptime-Dienst wie Better Stack oder UptimeRobot. Du willst wissen, dass deine App ausgefallen ist, bevor ein Kunde es dir sagt.

Geschätzter Wartungsaufwand für den Stack oben: ein bis drei Stunden im Monat.

Apt-Updates, gelegentliche Abhängigkeits-Updates und ein vierteljährlicher Blick auf das Log-Volumen. Das ist der Preis für niedrigere Kosten und mehr Kontrolle.

Wann ist ein VPS die falsche Wahl für Node.js?

Ein VPS ist die falsche Wahl, wenn deine Workload für etwas anderes gemacht ist. Sei ehrlich zu dir, auf welcher Seite du stehst, bevor du einen Server bereitstellst.

• Statische Websites und SSG-Inhalte: Next.js-Export, Astro, Gatsby und ein Eleventy-Blog. Plattformen wie Vercel, Netlify oder Cloudflare Pages bieten dir weltweit gecachtes statisches Hosting, Git-basierte Deployments und automatische Rebuilds direkt ab Werk. Für rein statische Inhalte ist ein VPS meist unnötige Infrastruktur.
• Seltene, ereignisgesteuerte Workloads: Cloudflare Workers und AWS Lambda kosten für Webhooks, die zehnmal am Tag laufen, sehr wenig.
• Echtzeit-Apps mit mehr als 100.000 gleichzeitigen Verbindungen: Ein einzelner VPS skaliert nicht horizontal. Du brauchst Orchestrierung (Kubernetes, ECS, Nomad) oder eine verwaltete Echtzeit-Plattform wie Ably oder Pusher.
• Stark regulierte Workloads mit hohen Compliance-Anforderungen: HIPAA, PCI-DSS Level 1, FedRAMP. Eine verwaltete PaaS mit integrierten Compliance-Zertifizierungen erspart dir Ärger bei Audits. Compliance selbst auf einem VPS umzusetzen, ist ein Projekt über mehrere Quartale, das du dir wahrscheinlich nicht antun willst.
• Keine Linux-Erfahrung – und keine Lust, sie aufzubauen: Plattformen wie Render, Railway und DigitalOcean App Platform liegen irgendwo zwischen reinem VPS-Hosting und vollständig verwalteter PaaS. Tools wie Dokploy ergänzen deine eigene VPS-Infrastruktur um Deployment-Workflows im Heroku-Stil. So bekommst du viele der Vorteile bei Kosten und Kontrolle, ohne dich tief in iptables, die Interna von systemd oder das Debugging von Reverse Proxys um 1 Uhr nachts einarbeiten zu müssen.

Für keine dieser Antworten musst du dich schämen. Die beste technische Entscheidung ist die, die zu deiner Workload passt.

Deinen Node-Stack wählen und einziehen

Öffne diese Hosting-Rechnung noch ein letztes Mal.

Einen überraschend großen Teil davon ersetzt du gleich durch eine einzige VPS-Rechnung.

👉Der Stack: Ubuntu 24.04 LTS, Node 24, PM2 (oder systemd), NGINX (oder Caddy), Let’s Encrypt über Certbot (oder die integrierte Funktion von Caddy).

Starte den kleinsten VPS-Tarif, der den von dir geplanten RAM bietet, installiere Node, lass deine App auf ‚127.0.0.1‘ laufen, richte NGINX darauf aus und stelle deinen DNS um.

Wenn die App ein Deployment, einen Neustart und eine Nacht ohne Zwischenfälle übersteht, hast du das Wichtigste geschafft.

Der Rest ist Wartung. Ein bis zwei Stunden im Monat, ab und zu ein Zeitfenster für ‚apt upgrade‘, ein vierteljährliches Update der Abhängigkeiten. Das ist der Deal, den du eingehst, wenn du eine Rechnung pro Nutzer gegen eine Pauschale tauschst – und mit dem selbstverwalteten VPS Stack 4 von DreamHost kannst du direkt loslegen.

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