PM2 vs systemd: Welcher Prozessmanager für Node.js? Mit Messungen (2026)

PM2 vs systemd ist eine der ersten Fragen, die man sich stellt, sobald eine Node.js-App vom Laptop auf einen Server umzieht. Beide sorgen dafür, dass dein Programm im Hintergrund läuft, nach einem Absturz neu startet und beim Booten wieder hochkommt. PM2 ist ein Prozessmanager aus der Node-Welt, den du per npm installierst. systemd ist das Init-System, das auf fast jedem modernen Linux ohnehin schon läuft. Die Frage ist also nicht nur „welches ist besser?“, sondern auch: Brauche ich die zusätzliche Schicht überhaupt?

Wir haben das nicht aus Dokumentationen abgeschrieben, sondern am 12. November 2026 auf unserem eigenen Server nachgemessen: PM2 7.1.1, systemd 255 (Ubuntu 24.04), Node.js 22.23.5. Dieselbe kleine HTTP-App lief einmal unter PM2 und einmal als systemd-Unit. Wir haben sie per kill und kill -9 abgeschossen, in eine Absturzschleife geschickt, den Speicher mit smaps_rollup gemessen und während eines Reloads 600 Anfragen dagegen gefeuert. Vier Befunde vorweg:

1. PM2 startet eine App auch nach einem normalen kill (SIGTERM) neu. systemd mit Restart=on-failure tut das nicht, der Dienst bleibt aus. Das ist kein Fehler, sondern eine unterschiedliche Vorstellung davon, was „beendet“ heißt.

2. Bei einer Absturzschleife gibt systemd nach 5 Versuchen in 2,6 Sekunden auf, PM2 nach 15 Neustarts in rund 5 Sekunden. Beide melden das nirgendwohin, wenn du nichts einrichtest.

3. Dieselbe App braucht unter PM2 12,1 MB echten Speicher (PSS), unter systemd 8,3 MB. Dazu kommt der PM2-Daemon selbst mit 15 bis 18 MB.

4. Auf unserem Server lief seit Monaten ein pm2-root.service, der null Prozesse verwaltet, aber 131 MB alte Logdateien mitschleppt. Niemand hatte ihn abgeschaltet, weil nichts kaputt war.

PM2 vs systemd: Was ist was?

Bevor wir messen, kurz die Begriffe, denn die beiden Werkzeuge spielen nicht ganz in derselben Liga.

systemd ist das erste Programm, das Linux nach dem Kernel startet. Es hat die Prozessnummer 1 und fährt alles andere hoch: Netzwerk, SSH, Datenbanken, Webserver und eben auch deine eigenen Dienste. Jeder Dienst wird über eine kleine Textdatei beschrieben, eine Unit. Wie man so eine Datei schreibt, haben wir ausführlich in systemd Service erstellen gezeigt. systemd ist sprachneutral: Node, Python, Go, ein Bash-Skript, alles dasselbe.

PM2 ist ein Prozessmanager, der selbst in Node.js geschrieben ist. Du installierst ihn mit npm install -g pm2, startest deine App mit pm2 start app.js und bekommst sofort eine hübsche Tabelle mit Status, CPU, Speicher und Neustartzähler. PM2 läuft als eigener Hintergrundprozess, dem sogenannten God Daemon, der deine Apps als Kindprozesse startet und überwacht. Zusätzlich bringt PM2 Funktionen mit, die systemd nicht direkt hat: einen Cluster-Modus, der mehrere Instanzen deiner App auf einen Port verteilt, und einen Zero-Downtime-Reload.

Der entscheidende Punkt, den viele Tutorials verschweigen: PM2 ersetzt systemd nicht. Damit PM2 nach einem Neustart des Servers wieder läuft, erzeugt der Befehl pm2 startup eine systemd-Unit, die den PM2-Daemon startet. So sah das bei uns aus:

[Unit]
Description=PM2 process manager
After=network.target

[Service]
Type=forking
User=root
Environment=PM2_HOME=/root/.pm2
PIDFile=/root/.pm2/pm2.pid
Restart=on-failure
ExecStart=/usr/lib/node_modules/pm2/bin/pm2 resurrect
ExecReload=/usr/lib/node_modules/pm2/bin/pm2 reload all
ExecStop=/usr/lib/node_modules/pm2/bin/pm2 kill

[Install]
WantedBy=multi-user.target

Die Kette ist also immer: systemd → PM2-Daemon → deine App. Mit reinem systemd ist sie: systemd → deine App. Der Vergleich lautet deshalb ehrlicher „systemd allein“ gegen „systemd plus PM2“.

Unser Testaufbau

Damit der Vergleich fair ist, lief in beiden Fällen exakt dieselbe Datei. Eine Mini-App, die auf einem Port lauscht, ihre Prozessnummer zurückgibt und sich über /crash mit Exit-Code 1 selbst beendet:

const http = require('http');
const port = process.env.PORT || 4711;
http.createServer((req, res) => {
  if (req.url === '/crash') { res.end('bye'); setTimeout(() => process.exit(1), 10); return; }
  res.end('ok ' + process.pid + '\n');
}).listen(port);
process.on('SIGTERM', () => process.exit(0));

Für PM2 haben wir ein eigenes PM2_HOME unter /tmp benutzt, damit der vorhandene PM2-Daemon auf dem Server nicht angefasst wird. Für systemd haben wir eine minimale Unit mit Restart=on-failure angelegt, also genau das, was in den meisten Anleitungen steht. Nach dem Test haben wir beide Testumgebungen vollständig gelöscht.

Gemessen haben wir:

• Neustartverhalten bei SIGTERM, SIGKILL und Exit-Code 1
• Absturzschleifen: Wann gibt der Manager auf?
• Speicher: nicht RSS, sondern PSS aus /proc/PID/smaps_rollup. Warum RSS hier täuscht, steht in Wie viel RAM braucht ein Server.
• Ausfallzeit beim Neustart und Reload, gemessen mit einer Schleife aus curl-Anfragen alle 10 Millisekunden
• Startzeit des PM2-Daemons

Neustart nach Absturz: der größte Unterschied

Hier liegt der Unterschied, der im Alltag am meisten überrascht.

SIGTERM: PM2 betrachtet jedes Ende eines Prozesses, das nicht über pm2 stop kam, als ungeplant und startet ihn wieder. systemd sieht ein sauberes Beenden mit Exit-Code 0 als gewollt an. Wer also auf einem systemd-Server „mal eben“ kill auf eine App ausführt, schaltet sie damit ab. Unter PM2 ist sie eine Sekunde später zurück. Beides kann richtig oder falsch sein. Wenn du willst, dass systemd sich wie PM2 verhält, setzt du Restart=always.

SIGKILL: Beide starten neu. PM2 war in unserem Test schneller (68 gegen 379 Millisekunden bis zur ersten erfolgreichen Antwort). Der Grund ist banal: systemd wartet standardmäßig RestartSec=100ms, bevor es neu startet, und erzeugt dann einen komplett frischen Node-Prozess. Für die allermeisten Dienste ist eine Drittelsekunde völlig egal. Wer es schneller braucht, kann RestartSec senken.

Absturzschleife: Eine App, die 200 Millisekunden nach dem Start abstürzt, wird von keinem der beiden ewig neu gestartet. systemd greift nach seinem Standardlimit (StartLimitBurst=5 in StartLimitIntervalSec=10s) ein und setzt den Dienst auf failed. PM2 hört nach max_restarts (Standard 15) auf und zeigt errored. Das Problem ist in beiden Fällen dasselbe: Es klingelt nirgends. Die App ist aus, und du merkst es erst, wenn ein Nutzer sich beschwert. Unter systemd kannst du mit OnFailure= eine eigene Unit starten lassen, die dir eine Nachricht schickt. Unter PM2 brauchst du dafür ein Modul oder einen externen Dienst. Wie wir Dienste generell überwachen, steht in Server-Monitoring.

Speicherverbrauch: was die Schicht kostet

PM2 zeigt in seiner Tabelle eine Spalte mem. Bei unserer Test-App stand dort direkt nach dem Start 29 MB, eine Sekunde später 60,6 MB. Beides ist RSS und damit für den Vergleich wenig aussagekräftig, weil geteilte Bibliotheken bei jedem Prozess voll mitgezählt werden. Die ehrliche Zahl ist PSS, der Anteil, den ein Prozess tatsächlich allein verursacht:

Zwei Dinge fallen auf. Erstens läuft dieselbe App unter PM2 mit rund 4 MB mehr, weil PM2 sie in einen eigenen Wrapper (ProcessContainerFork) packt, der die Kommunikation mit dem Daemon übernimmt. Zweitens kostet der Daemon selbst noch einmal 15 bis 18 MB, egal ob er eine App oder zwanzig verwaltet. Auf einem 1-GB-VPS sind 20 bis 25 MB Zusatz spürbar, auf einem Server mit 8 GB oder mehr spielt das keine Rolle.

systemd selbst taucht in dieser Rechnung nicht auf, weil es ohnehin läuft. Als Bonus misst systemd den Verbrauch pro Dienst über cgroups mit: systemctl show -p MemoryCurrent dienstname lieferte bei uns 8,8 MB, ziemlich genau der PSS-Wert. Und mit MemoryMax=200M in der Unit setzt du eine harte Grenze, die der Kernel durchsetzt. PM2 kennt max_memory_restart, das ist aber eine nachträgliche Kontrolle: PM2 schaut regelmäßig nach und startet die App neu, wenn sie zu groß geworden ist. Der Kernel-Grenzwert unter systemd greift sofort.

Cluster-Modus und Zero-Downtime: die echte Stärke von PM2

Hier spielt PM2 seinen größten Vorteil aus. Mit einem einzigen Befehl startest du mehrere Instanzen deiner App, die sich einen Port teilen:

pm2 start app.js -i 4 --name meine-app

Node.js nutzt standardmäßig nur einen CPU-Kern. Der Cluster-Modus von PM2 verwendet das eingebaute cluster-Modul von Node und verteilt eingehende Verbindungen auf die Instanzen. In unserem Test landeten 8 Anfragen exakt gleichmäßig auf den 4 Prozessen, je 2 pro Instanz.

Dann der eigentliche Test: Während eine Schleife 600 Anfragen im Abstand von 10 Millisekunden schickte, haben wir pm2 reload ausgeführt. PM2 startet dabei eine Instanz nach der anderen neu und wartet, bis die neue bereit ist, bevor die alte beendet wird.

Unter systemd mit nur einer Instanz gingen beim Neustart 4 von 300 Anfragen verloren, etwa 1,3 Prozent, also ein Fenster von einigen Dutzend Millisekunden, in dem niemand auf dem Port lauschte. Für eine interne API ist das meist egal. Für einen Shop-Checkout, der ständig deployed wird, nicht.

Fairerweise: Auch mit systemd geht Zero-Downtime, nur nicht mit einem Befehl. Die üblichen Wege sind zwei Instanzen über eine Template-Unit (app@1.service, app@2.service) hinter einem Reverse Proxy wie nginx, die nacheinander neu gestartet werden, oder Socket-Aktivierung, bei der systemd den Port hält. Das haben wir für diesen Artikel nicht gemessen, deshalb stehen dazu hier auch keine Zahlen. Es ist aber mehr Handarbeit, und genau die nimmt PM2 dir ab.

Autostart nach dem Reboot: die Falle mit pm2 save

Unter systemd ist Autostart eine Zeile: systemctl enable dienstname. Die Unit-Datei liegt auf der Platte, und nach jedem Reboot ist der Dienst wieder da.

Unter PM2 sind es drei Schritte, und der dritte wird ständig vergessen:

pm2 startup        # erzeugt die systemd-Unit für den PM2-Daemon
pm2 start app.js   # App starten
pm2 save           # aktuelle Prozessliste nach ~/.pm2/dump.pm2 schreiben

Beim Booten führt die Unit pm2 resurrect aus und startet alles, was in dump.pm2 steht. Wir haben getestet, was ohne pm2 save passiert: App gestartet, Daemon beendet, pm2 resurrect ausgeführt. Ergebnis: 0 Prozesse. Mit pm2 save dazwischen kam die App sauber zurück.

Das heißt auch: Der Zustand deines Servers lebt bei PM2 in einer Datei, die nur dann aktuell ist, wenn du nach jeder Änderung daran denkst. Startest du eine neue App und vergisst pm2 save, ist sie nach dem nächsten Kernel-Update weg. Bei systemd ist die Unit-Datei selbst der Zustand. Es gibt nichts zu vergessen.

Logs: journald gegen Dateien, die wachsen

systemd schickt alles, was deine App auf stdout und stderr schreibt, ins Journal. Du liest es mit journalctl -u dienstname -f, kannst nach Zeit filtern (--since "1 hour ago") und musst dich nicht um Rotation kümmern, weil journald eine Obergrenze hat. Bei uns liegt die bei SystemMaxUse=1G, aktuell belegt das Journal 807,6 MB für den ganzen Server, und es wächst nicht darüber hinaus.

PM2 schreibt Logs in Dateien unter ~/.pm2/logs/, zwei pro App (out und error). Standardmäßig ohne Rotation. Dafür gibt es das Modul pm2-logrotate, das du extra installieren musst. Wie schnell das schiefgeht, haben wir auf unserem eigenen Server gesehen:

98 MB  nyx-gateway-error.log   (zuletzt beschrieben: 14. Juni 2026)
39 MB  nyx-gateway-out.log     (zuletzt beschrieben: 14. Juni 2026)
131 MB insgesamt in ~/.pm2/logs

Eine Error-Log-Datei von 98 Megabyte für einen Dienst, der seit Juni nicht mehr unter PM2 läuft. Die Dateien sind nie rotiert worden und liegen einfach da. Wenn du PM2 nutzt, installiere pm2-logrotate gleich am ersten Tag, oder hänge ~/.pm2/logs/*.log in deine normale Rotation ein. Wie das geht, zeigen wir in logrotate einrichten. Und falls die Platte schon voll ist: Linux-Festplatte voll.

Unser eigener Fund: der Daemon, der nichts tut

Beim Vorbereiten dieses Artikels haben wir auf unserem Server nachgesehen, was PM2 dort eigentlich macht:

$ systemctl list-units 'pm2*'
pm2-root.service  loaded active running  PM2 process manager

$ cat ~/.pm2/dump.pm2
[]

Der Dienst ist aktiv, der Daemon läuft, startet bei jedem Reboot mit, belegt 18 MB echten Speicher. Und er verwaltet nichts. Die Prozessliste ist leer. Irgendwann im Sommer sind wir mit unseren Node-Diensten auf reine systemd-Units umgezogen (inzwischen laufen auf dem Server rund 90 Dienste, alle direkt unter systemd), aber der PM2-Daemon ist geblieben.

Das ist kein Drama, aber ein typisches Muster: Eine Schicht, die nichts mehr tut, fällt nicht auf, weil sie auch nichts kaputt macht. systemctl status sagt „active (running)“, und genau das liest man als „alles in Ordnung“. Wenn du von PM2 auf systemd umsteigst, räum am Ende auf:

pm2 unstartup systemd   # entfernt die pm2-<user>.service-Unit
pm2 kill                # beendet den Daemon
npm uninstall -g pm2    # optional

Weitere Unterschiede auf einen Blick

Der Punkt Sicherheit wird oft übersehen. systemd kann einen Dienst einsperren: nur Lesezugriff auf das System, kein Zugriff auf /home, keine neuen Rechte, eigenes /tmp. In unserem systemd-Artikel kam ein Test-Dienst damit von 9,6 auf 1,5 Punkte im eingebauten Sicherheits-Check. PM2 hat nichts Vergleichbares. Ein typisches PM2-Setup läuft außerdem häufig als root, weil pm2 startup mit dem aktuellen Benutzer arbeitet und viele Anleitungen alles als root machen. So war es auch bei uns (User=root in der generierten Unit). Unter systemd ist User=nodeapp eine Zeile.

Die systemd-Unit, die PM2 für eine einzelne App ersetzt

Wenn du von PM2 umsteigen willst, reicht für die allermeisten Node-Apps diese Unit. Sie bildet die PM2-Standards nach (Neustart bei jedem Ende) und legt ein paar Dinge drauf, die PM2 nicht kann:

[Unit]
Description=Meine Node-App
After=network-online.target
Wants=network-online.target

[Service]
User=nodeapp
WorkingDirectory=/opt/meine-app
ExecStart=/usr/bin/node /opt/meine-app/server.js
Environment=NODE_ENV=production
EnvironmentFile=-/opt/meine-app/.env
Restart=always
RestartSec=1
MemoryMax=300M
NoNewPrivileges=true
ProtectSystem=strict
ReadWritePaths=/opt/meine-app/data
PrivateTmp=true

[Install]
WantedBy=multi-user.target

Danach:

sudo systemctl daemon-reload
sudo systemctl enable --now meine-app
journalctl -u meine-app -f

Zwei Stolperfallen beim Umstieg: Erstens kennt systemd deine Shell-Umgebung nicht. Wenn du Node über nvm installiert hast, findet systemd node nicht. Nimm in ExecStart immer den absoluten Pfad, den which node ausgibt. Zweitens las PM2 eventuell eine ecosystem.config.js mit Umgebungsvariablen. Die gehören unter systemd in Environment= oder eine .env-Datei über EnvironmentFile=.

Und wenn die App in Docker läuft?

Dann brauchst du in der Regel keinen der beiden für die App selbst. Docker startet Container mit restart: unless-stopped neu, und der Docker-Daemon wird seinerseits von systemd gestartet. PM2 im Container (über pm2-runtime) ist nur dann sinnvoll, wenn du den Cluster-Modus innerhalb eines Containers willst. Üblicher ist es, mehrere Container-Instanzen laufen zu lassen. Mehr zu Containern in Was ist Docker, Docker vs. Podman und in unserem Docker-Compose-Beispiel.

Unsere Empfehlung: PM2 oder systemd?

Nimm systemd, wenn …

• du einzelne Dienste auf einem eigenen Linux-Server betreibst (das ist der Normalfall),
• mehrere Sprachen im Spiel sind, nicht nur Node,
• du Ressourcen-Limits, Sandboxing oder Abhängigkeiten zwischen Diensten brauchst,
• du dich nicht um Logrotation und pm2 save kümmern willst,
• dein Server wenig RAM hat.

Nimm PM2, wenn …

• du eine Node-App auf mehrere CPU-Kerne verteilen willst und keinen Load Balancer davor bauen möchtest,
• du sehr oft deployest und Zero-Downtime ohne Zusatzaufwand brauchst,
• du gerade anfängst und die Bedienung über pm2 ls und pm2 logs für dich einfacher ist,
• du in einem Umfeld arbeitest, in dem du keinen Root-Zugriff hast und keine System-Units anlegen darfst (wobei systemd auch User-Units kann).

Bei uns ist die Antwort klar: Alle eigenen Dienste laufen direkt unter systemd, rund 90 Stück. Den Cluster-Modus haben wir nie vermisst, weil unsere Node-Dienste fast nie CPU-gebunden sind und vor allem auf Datenbanken oder externe APIs warten. Wo wir wirklich skalieren müssten, würden wir eher zwei Instanzen hinter den Reverse Proxy stellen. PM2 hat bei uns am Ende nur noch eins getan: leer mitlaufen.

Das ist kein Urteil gegen PM2. Es ist ein gutes Werkzeug mit einer sehr angenehmen Oberfläche. Aber es ist eine zusätzliche Schicht über etwas, das schon da ist, und jede Schicht will gepflegt werden.

Häufige Fragen

Was ist der Unterschied zwischen PM2 und systemd?

systemd ist das Init-System von Linux und verwaltet alle Dienste, egal in welcher Sprache. PM2 ist ein in Node.js geschriebener Prozessmanager, der vor allem für Node-Apps gedacht ist und Extras wie Cluster-Modus und Zero-Downtime-Reload mitbringt. PM2 selbst wird beim Booten wiederum von systemd gestartet.

Ist PM2 besser als systemd?

Nicht generell. PM2 ist besser beim Cluster-Modus und beim Reload ohne Ausfallzeit. systemd ist besser bei Ressourcen-Limits, Sicherheit, Logs, Abhängigkeiten zwischen Diensten und verbraucht keinen zusätzlichen Speicher. Für die meisten einzelnen Dienste auf einem Linux-Server reicht systemd.

Braucht man PM2 überhaupt noch?

Für viele Setups nicht. Wenn du keinen Cluster-Modus und kein Zero-Downtime-Deployment brauchst, erledigt systemd alles, was PM2 tut, ohne zusätzliche Installation. PM2 bleibt praktisch, wenn du eine Node-App auf mehrere Kerne verteilen willst.

Startet systemd eine Node-App nach einem Absturz neu?

Ja, mit Restart=on-failure bei Abstürzen und Exit-Codes ungleich 0. Wird die App mit einem normalen kill (SIGTERM) beendet, startet systemd sie mit dieser Einstellung nicht neu. Wer das will, setzt Restart=always.

Wie viel Speicher braucht PM2?

In unserer Messung belegte der PM2-Daemon 15 bis 18 MB echten Speicher (PSS), auch ganz ohne verwaltete App. Eine App unter PM2 brauchte zusätzlich etwa 4 MB mehr als dieselbe App unter systemd. Die RSS-Anzeige in pm2 ls ist deutlich höher, weil geteilte Bibliotheken mitgezählt werden.

Was macht pm2 startup?

Der Befehl erzeugt eine systemd-Unit (zum Beispiel pm2-root.service), die beim Booten den PM2-Daemon startet und mit pm2 resurrect die gespeicherte Prozessliste wiederherstellt. Ohne anschließendes pm2 save ist diese Liste leer, und nach dem Reboot läuft keine App.

Kann systemd mehrere Instanzen wie der PM2-Cluster-Modus starten?

Ja, über Template-Units wie app@.service, die du als app@1, app@2 usw. startest, jede auf einem eigenen Port. Die Verteilung übernimmt dann ein Reverse Proxy wie nginx oder Caddy. Das ist mehr Handarbeit als pm2 start -i 4, gibt dir aber volle Kontrolle.

Sollte ich PM2 in einem Docker-Container verwenden?

Meist nicht. Docker startet Container selbst neu, und mehrere Container-Instanzen ersetzen den Cluster-Modus. pm2-runtime im Container lohnt sich nur, wenn du ausdrücklich mehrere Node-Prozesse in einem Container willst.

Wie steige ich von PM2 auf systemd um?

Für jede App eine Unit-Datei anlegen (Vorlage oben), mit systemctl enable --now starten, prüfen, dann die App aus PM2 entfernen (pm2 delete name), pm2 save ausführen und zum Schluss mit pm2 unstartup systemd und pm2 kill den Daemon selbst abschalten. Vergiss nicht, alte Logdateien in ~/.pm2/logs aufzuräumen.

Was ist mit Zeitplänen, ersetzt PM2 Cronjobs?

PM2 kann Apps mit cron_restart zeitgesteuert neu starten, aber keine beliebigen Aufgaben planen. Dafür gibt es klassisch Cronjobs oder systemd-Timer, die wir im systemd-Artikel zeigen.

Fazit

Im Vergleich PM2 vs systemd gewinnt keiner auf ganzer Linie. PM2 hat die schönere Oberfläche, einen eingebauten Cluster-Modus und in unserem Test 600 von 600 Anfragen beim Reload durchgebracht. systemd ist schon da, braucht keinen Extra-Speicher, sperrt Dienste auf Wunsch ein, rotiert Logs von selbst und kennt keinen Zustand, den man mit pm2 save vergessen kann.

Für eine einzelne Node-App auf einem eigenen Server ist systemd die schlankere Wahl. Für eine CPU-hungrige Node-App, die auf alle Kerne verteilt werden und ohne Unterbrechung deployed werden soll, ist PM2 bequem. Und wer PM2 nicht mehr braucht: Schau mit cat ~/.pm2/dump.pm2 nach, ob dein Daemon überhaupt noch etwas tut. Unserer tat es nicht.

Wenn du gerade erst einen Server aufsetzt, fang bei Linux-Server einrichten an.