VPS für Node.js und Python: Dimensionierung und Deployment
Zuverlässige App-Server brauchen Prozesse, Reverse Proxy, Datenbank, Rollback, Logs und Backups – nicht nur genügend RAM zum Start.

CPU, RAM und Speicher
| Szenario | Start | Beobachten |
|---|---|---|
| Bot/Webhook | 1 vCPU, 1–2 GB RAM | Queue und externe APIs |
| Kleine API | 2 vCPU, 2 GB RAM | Latenz und Prozesse |
| SSR + PostgreSQL | 2–4 vCPU, 4–8 GB RAM | DB, Build und Cache |
| Medien/Worker | 4+ vCPU, 8+ GB RAM | CPU, Disk, Queue |
Solider Aufbau
- Reverse Proxy terminiert TLS.
- App läuft als eigener Nicht-root-Benutzer.
- Prozessmanager startet Worker neu.
- Secrets kommen aus geschützter Laufzeitkonfiguration.
- Logs rotieren, externes Monitoring alarmiert.
- Datenbank und Uploads werden extern gesichert.
Versionen kontrollieren
Unterstützte Runtime und Abhängigkeiten mit Lockfiles fixieren. Python-Projekte erhalten getrennte Virtual Environments, Node-Projekte keine global gemeinsam genutzten Module. Produktionsartefakte reproduzierbar in CI bauen.
Deployment und Rollback
Versionierte Release-Verzeichnisse oder unveränderliche Images nutzen: Release hochladen, Migrationen kontrolliert ausführen, umschalten, Smoke-Test und Vorgänger behalten. Große Frontend-Builds nicht auf einem knappen Produktiv-VPS erzeugen.
Lokale oder Managed Database
Lokal ist günstig und latenzarm, konkurriert aber mit der App um Ressourcen. Managed kostet mehr, trennt Betrieb und Backups. Erst bei messbarer Last oder Verfügbarkeitsbedarf aufteilen.
Engpass finden
| Symptom | Ursache | Erster Schritt |
|---|---|---|
| CPU 100% | Blockierende Arbeit | Profiling, Worker auslagern |
| OOM | Leak/zu viele Prozesse | RSS und Heap prüfen |
| Hoher I/O wait | DB, Logs, Disk | Abfragen messen |
| Langsam bei wenig Last | Externe API/DB-Lock | Timings und Timeouts |
Häufige Fragen
Node.js oder Python?
Nach Bibliotheken, Team und Aufgabe wählen; Architektur zählt meist mehr.
Ist Docker nötig?
Nein. systemd und Virtual Environments sind ebenfalls zuverlässig.
Mehrere Projekte auf einem VPS?
Ja, getrennt nach Benutzern/Containern und Limits; der Host bleibt gemeinsamer Fehlerpunkt.
Dazu: Docker auf VPS.
