Hosting Node.js i Next.js. Wypychasz kod, strona działa.

1. Node.js braucht etwas zwischen PaaS und einem nackten Server

Für Node.js-Anwendungen ist ein Modell wie bei PaaS-Plattformen (Platform as a Service) oft die natürliche erste Wahl: git push genügt, und die Anwendung läuft, ohne dass ein Server verwaltet werden muss. Das Problem beginnt bei der Rechnung: Die meisten solchen Plattformen rechnen in US-Dollar ab, und bei echtem Produktionsverkehr steigen die Preise schnell, während die physische Infrastruktur außerhalb von Polen liegt.

Auf Saplo wird eine Node.js-Anwendung als einsatzbereites Starter-Projekt (Express) mit Auswahl der Node.js-Version 18, 20 oder 22, standardmäßig 20, bereitgestellt. Per Git Deploy kannst du es durch deinen eigenen Code ersetzen: Ein Push ins Repository aktualisiert die laufende Anwendung automatisch, ohne dass du dich nach jeder Änderung manuell auf dem Server anmelden musst.

Das Anwendungsmanifest gibt mindestens 512 MB RAM und 3 GB Speicherplatz an. Das bedeutet, dass auch Box S (1 GB RAM) technisch ausreicht, um eine einfache Node.js-Anwendung zu betreiben. Für alles, was mehr als ein Prototyp ist, solltest du jedoch Box M mit vollem SSH-Zugriff in Betracht ziehen.

2. Git Deploy vs. manueller Upload

Git Deploy bedeutet, dass das Code-Repository die einzige Quelle der Wahrheit für die in Produktion laufende Anwendung ist: Ein Push in den festgelegten Branch löst ein Update der Anwendung auf Box aus, ohne dass du nach jeder Codeänderung Dateien manuell per FTP hochladen oder per SSH kopieren musst.

Für ein Team, das mit mehreren Personen an derselben Node.js-Anwendung arbeitet, ist das ein echter Unterschied: Jeder Commit, der in den richtigen Branch gelangt, erreicht sofort den Server. So kannst du schnell iterieren, ohne zusätzliche Deployment-Schritte außer dem git push.

Box M bietet zusätzlich SSH-Zugriff mit sudo, mit dem du den Node.js-Prozess manuell verwalten kannst, etwa durch einen Neustart nach Änderungen an Umgebungsvariablen oder die Installation zusätzlicher Systempakete, die von manchen npm-Abhängigkeiten benötigt werden. Das ist nicht immer allein per Git Deploy möglich.

3. Warum kein klassischer VPS?

Auf einem unkonfigurierten VPS bei Konkurrent A (1 vCPU, 2 GB RAM, 20 GB Speicherplatz für ca. 11 €/Monat netto, öffentliche Preislisten, Stand 2026-10-10) erfordert die Einrichtung einer Node.js-Anwendung die manuelle Installation von Node, eines Prozessmanagers wie PM2, eines Reverse-Proxys und eines SSL-Zertifikats, bevor die Anwendung unter einer Domain mit https öffentlich erreichbar ist.

Bei Saplo werden diese Elemente (nginx als Reverse Proxy, SSL und der Prozessmanager im Container) bei der Installation aus dem Katalog automatisch konfiguriert. Von der Auswahl der Node-Version bis zur laufenden, öffentlich erreichbaren Anwendung unter deiner eigenen Domain dauert es so nur Minuten statt Stunden für die manuelle Serverkonfiguration.

Die Kosten sind mit denen eines VPS mit ähnlichen Ressourcen vergleichbar, doch du musst das Betriebssystem nicht selbst verwalten und riskierst auch nicht, dass ein Fehler in der Firewall-Konfiguration oder bei einer Systemaktualisierung deine Anwendung lahmlegt, obwohl er nichts mit dem Node.js-Code selbst zu tun hat.

4. Mehrere Node.js-Anwendungen auf einer Box

Auf einer Box kannst du ohne Begrenzung mehrere unabhängige Node.js-Projekte gleichzeitig bereitstellen, jedes in einem eigenen LXC-Container, jeweils mit eigener Domain oder Subdomain und ohne Portkonflikte zwischen den Projekten.

Für Anwendungen mit Datenbank stehen dir separate Datenbankmodule (Postgres, MySQL, Redis) zur Verfügung, die in einer eigenen Compose-Datei als Container bereitgestellt werden und nicht als kostenpflichtiges Add-on. Für einen typischen Stack aus Node.js und Datenbank ist das eine natürliche Kombination ohne zusätzliche Kosten für die Datenbank selbst. Das Hinzufügen einer Datenbank als weitere Anwendung auf derselben Box dauert genauso lange wie ihre Bereitstellung aus dem Katalog, ganz ohne separaten Vertrag mit einem externen Cloud-Datenbank-Anbieter.

5. Für wen es sich eignet

Wenn du eine einfache Backend-API oder einen Mikroservice entwickelst, bietet dir Box M mit vollem SSH-Zugang und Git-Deployment schnell eine produktionsreife Umgebung, ohne dass du den Server von Grund auf konfigurieren musst.

Wenn dein Startup gleichzeitig mehrere Node.js-Dienste entwickelt, etwa eine API, ein Panel und einen Worker, kannst du mit Box L alle auf einem Konto und in getrennten Containern betreiben. So brauchst du nicht für jeden Mikroservice eine eigene Rechnung bei verschiedenen PaaS-Anbietern.

Für alle, die von einer ausländischen, in US-Dollar abgerechneten PaaS-Plattform migrieren, bietet Saplo einen ähnlich komfortablen Deployment mit git push, rechnet aber in Zloty ab und betreibt die Infrastruktur in einem europäischen Rechenzentrum.

6. Erstes Deployment einer Node.js-Anwendung auf Saplo

Nachdem du den Express-Starter mit der gewünschten Node-Version (18, 20 oder 22) bereitgestellt hast, verknüpfst du im Panel ein Git-Repository mit der Anwendung. So werden spätere Codeänderungen bei jedem Push in den festgelegten Branch automatisch auf den Server übertragen.

Ersetze den Code des Express-Starters durch deine eigene Anwendung und behalte dabei den Port sowie die von der Saplo-Engine benötigten Umgebungsvariablen bei, damit der Reverse Proxy den Traffic weiterhin korrekt an deine Anwendung unter der verbundenen Domain weiterleitet.

Umgebungsvariablen wie API-Schlüssel und den Connection String zur Datenbank setzt du im App-Panel, ohne sie direkt im Code-Repository zu speichern. Das ist unabhängig davon, wo die Anwendung gehostet wird, eine gute Sicherheitspraxis.

Wenn deine Anwendung eine Datenbank nutzt, füge auf derselben Box ein separates Modul (Postgres, MySQL oder Redis) hinzu und verbinde deine Anwendung über die interne Adresse damit, ohne die Datenbank öffentlich im Internet zugänglich zu machen.

Überwache die Anwendungslogs per SSH (ab Box M), um nach jedem Deployment Fehler schnell zu erkennen, bevor sie für die Nutzer deiner produktiven Anwendung spürbar werden.

7. Node.js in einer Microservices-Architektur auf einer Box

Mehrere unabhängige Node.js-Dienste, etwa eine API, ein Worker, der eine Warteschlange verarbeitet, und ein Administrationsbereich, lassen sich als getrennte Anwendungen auf derselben Box betreiben, jede in einem eigenen Container. Sie kommunizieren über das interne Netzwerk oder über eine öffentliche API.

Diese Aufteilung erleichtert das unabhängige Deployment jedes Dienstes, denn ein git push zu einem Dienst erfordert kein Redeployment der anderen. Bei einem wachsenden Projekt ist das praktischer als ein großer, monolithischer Node.js-Prozess, der alles gleichzeitig abwickelt.

Redis als separates Datenbankmodul auf derselben Box dient oft als Aufgabenwarteschlange oder Cache zwischen Mikroservices, ohne dass du einen externen, kostenpflichtigen Redis-Dienst außerhalb der Saplo-Infrastruktur benötigst.

Bei einer Microservices-Architektur solltest du Box L oder größer wählen, denn mehrere unabhängige Node.js-Prozesse zusammen mit einer Datenbank und Redis benötigen mehr Arbeitsspeicher als eine einzelne, einfache Anwendung.

8. Überwachung und Logs für Node.js-Anwendungen in der Produktion

Eine Node.js-Anwendung in der Produktion stößt früher oder später auf einen Fehler, der bei lokalen Tests nicht aufgetreten ist. Deshalb ist der Zugriff auf die Prozesslogs per SSH (ab Box M) ein grundlegendes Diagnosewerkzeug: Du siehst, was zum Zeitpunkt eines Ausfalls oder unerwarteten Verhaltens tatsächlich passiert ist.

Gute Praxis ist strukturiertes Logging, etwa im JSON-Format mit Schweregrad und Zeitstempel, statt einfacher console.log-Aufrufe, die im Code verstreut liegen. So lassen sich Logs später leichter nach Ereignistyp oder Fehlerstufe filtern, besonders wenn die Anwendung wächst und die Logmenge zunimmt.

Der Prozessmanager im Container kann so konfiguriert werden, dass er den Prozess nach einem Ausfall neu startet, beispielsweise nach einer nicht abgefangenen Exception, die Node.js beendet. Dadurch führt ein kurzzeitiger Ausfall nicht zu einer langen Unterbrechung der Verfügbarkeit, bevor jemand im Team das Problem bemerkt und manuell eingreift.

Für Anwendungen mit vielen npm-Abhängigkeiten ist es sinnvoll, regelmäßig bekannte Sicherheitslücken in den verwendeten Paketen zu prüfen (mit den üblichen npm-Audit-Tools), da veraltete Abhängigkeiten ein häufiger Angriffsvektor für Node.js-Anwendungen sind, unabhängig davon, wie gut der Anwendungscode selbst geschrieben ist.

Die Überwachung des RAM-Verbrauchs des Node.js-Prozesses hilft dir, Speicherlecks zu erkennen, bevor sie zum Ausfall der gesamten Anwendung führen. Bei langlebigen Prozessen, etwa WebSocket-Servern oder Anwendungen mit langanhaltenden Verbindungen, ist das ohne entsprechende Überwachung ein reales Risiko. Wenn du regelmäßig den Speicherverbrauch im zeitlichen Verlauf prüfst, erkennst du wachsende Probleme selbst ohne fortgeschrittene Profiling-Tools frühzeitig genug, um eine Korrektur zu planen, bevor die Anwendung in der Produktion ausfällt.

Das Saplo-Panel zeigt die aktuelle Ressourcennutzung des Containers und ist damit der erste Anhaltspunkt bei der Diagnose von Leistungsproblemen, bevor du zu detaillierteren Profiling-Tools für die Node.js-Anwendung greifen musst.

9. Community und npm-Ökosystem als Teil der Stack-Auswahl

Node.js verfügt über eines der größten Paketökosysteme (npm) unter den verbreiteten Sprachen und Plattformen. Damit stehen dir für die meisten typischen Anforderungen, etwa Authentifizierung, Datenbankverbindung und Dateiverarbeitung, ausgereifte, bewährte Bibliotheken zur Verfügung, statt diese Logik in jedem neuen Projekt neu zu schreiben.

Auf Saplo steht dir dieses Ökosystem vollständig zur Verfügung, weil die Anwendung in einer standardmäßigen Node.js-Umgebung mit Zugriff auf die npm-Registry läuft. Es gelten keine Einschränkungen durch die Hosting-Plattform, wie sie bei manchen geschlossenen PaaS-Plattformen mit einer begrenzten Liste unterstützter Pakete üblich sind.

Die Wahl zwischen gängigen Frameworks (Express, Fastify, NestJS) und reinem Node.js liegt vollständig bei dir, denn der von Saplo bereitgestellte Starter (Express) ist ein Ausgangspunkt und keine starre Einschränkung. Bei Bedarf kannst du ihn durch einen anderen Framework ersetzen.

Updates der Node.js-Umgebung selbst, also ein Wechsel auf eine neuere LTS-Version, sind als Option bei der Neukonfiguration der Anwendung verfügbar. So bleibst du im Takt des Node.js-Release-Zyklus und musst wegen der geforderten Umgebungsversion nicht zu einem anderen Anbieter wechseln.

Für Teams, die die Entwicklung des JavaScript-Ökosystems verfolgen (neue Build-Tools, neue Architekturmuster), bietet die Flexibilität durch vollen SSH-Zugriff und eine standardmäßige Node.js-Umgebung auf Saplo keine zusätzlichen Einschränkungen gegenüber dem, was auf einem klassischen, selbst verwalteten Server möglich ist.

10. Node.js-Anwendungen vor dem Produktivstart testen

Vor jedem Produktivstart solltest du die neue Anwendungsversion in einer produktionsnahen Umgebung testen, zum Beispiel in einer separaten temporären Anwendung auf demselben Box, bevor du die Änderung auf die Domain bringst, die deine Kunden tatsächlich nutzen.

Automatisierte Tests (Unit- und Integrationstests), die vor der Bereitstellung in einer einfachen CI-Pipeline auf Repository-Ebene laufen, helfen dabei, Regressionen im Code zu erkennen, bevor er per git deploy auf den Produktionsserver gelangt. Das ist deutlich günstiger als die Behebung eines Fehlers, der bereits für Nutzer sichtbar ist.

Bei Anwendungen mit kritischem Traffic in der Produktion solltest du Änderungen außerhalb der Hauptverkehrszeiten bereitstellen. So begrenzt du die Zahl der Nutzer, die von einem möglichen kurzzeitigen Fehler beim Update per git deploy betroffen sind.

Ein Rollback auf die vorherige funktionierende Codeversion (Rückkehr zu einem früheren Commit und erneutes git push) ist ein einfacher Schutzmechanismus, wenn sich ein neues Deployment als problematisch erweist. Ein Box-Backup ab Box L schützt zusätzlich die Datenbank der Anwendung vor größeren Problemen.

11. Zusammenfassung: Node.js mit git deploy als schneller Weg in die Produktion

Die Kombination aus einem fertigen Express-Starter, der flexiblen Wahl der Node-Version und dem automatischen Deployment per git push verkürzt die Zeit von der Idee bis zu einer laufenden, öffentlich erreichbaren Node.js-Anwendung auf Minuten. Auf einem blanken VPS wären dagegen Stunden für die manuelle Einrichtung von Server, Firewall und Reverse Proxy nötig, bevor die erste Zeile deines eigenen Anwendungscodes überhaupt auf einer Produktionsadresse mit aktivem SSL-Zertifikat läuft. Wenn du eine neue Idee testest, kann dieser Zeitvorsprung entscheidend sein: In den ersten Arbeitsstunden konzentrierst du dich auf die Anwendungslogik statt auf die Infrastruktur rund um sie. Noch stärker gilt das, wenn du mehrere Ideen parallel testest: Die Kosten für die Prüfung der nächsten Idee sinken auf die Zeit zum Schreiben des Codes, weil du die identische Serverkonfiguration nicht bei jedem Versuch neu einrichten musst.