How-To · Windows · aktualisiert 2026

NSSM unter Windows 11/10: Download, Installation & Windows-Service einrichten

tiny-tool.de

NSSM (Non-Sucking Service Manager) macht aus einer normalen Anwendung einen Windows-Dienst – zum Beispiel aus einem Java-Jar, Node.js-Server, Python-Skript oder Worker. Hier findest du den sicheren NSSM-Download, die Installation per GUI und CLI, Beispiele für Java, Node und Python sowie Logging, Restart-Strategien, Troubleshooting und mit Zeus Herald ein aktuelles Praxisbeispiel aus einem realen Node.js-Dauerbetrieb.

Aktualisiert: 10. August 2026 · Von Guido Zeuner · Praxisguide für Windows 10/11 und Windows Server

NSSM in 60 Sekunden

Download: NSSM immer von der offiziellen Seite nssm.cc beziehen.
Windows 10/11: Die stabile Version 2.24 ist alt. Die offizielle NSSM-Seite empfiehlt für Windows 10 Creators Update, Server 2016 und neuer mindestens den Pre-Release-Build 2.24-101 oder einen neueren offiziellen Build.
Installation: NSSM braucht keine klassische Installation. nssm.exe kommt in einen festen Ordner und bleibt dort.
Service anlegen: nssm install MeinDienst öffnet die GUI; per CLI geht es vollständig skriptbar.
Praxis: Java/Spring Boot, Node.js und Python lassen sich mit Working Directory, Environment, Restart und Logging sauber betreiben.
Aktuelles Praxisprojekt: Zeus Herald zeigt den Windows-Dauerbetrieb eines Node.js-Projekts mit zwei getrennten NSSM-Diensten für Ingest und Bewegungserkennung.
Wichtig: NSSM ist praktisch, aber das Projekt ist alt. Für neue standardisierte Deployments lohnt sich auch ein Blick auf WinSW oder einen nativen Windows-Service.

Was ist NSSM?

NSSM steht für Non-Sucking Service Manager. Das Tool ist ein Wrapper für den Windows Service Control Manager: Statt eine Anwendung selbst als echten Windows-Service programmieren zu müssen, lässt du NSSM den Prozess starten, überwachen und bei Bedarf neu starten.

Typische Kandidaten sind Java-Jars, Spring-Boot-Anwendungen, Node.js-Server, Python-Skripte, Worker oder andere Konsolenprogramme, die dauerhaft im Hintergrund laufen sollen.

Der entscheidende Unterschied

NSSM macht nicht aus deinem Programmcode einen nativen Windows-Service. NSSM selbst wird als Dienst registriert und startet bzw. überwacht deine Anwendung. Genau deshalb ist das Setup so schnell.

NSSM Download: Welche Version für Windows 11/10?

Die wichtigste Regel zuerst: Lade NSSM nur von der offiziellen Website herunter. Die offizielle Download-Seite ist:

https://nssm.cc/download

Achtung bei der stabilen Version 2.24

Die stabile Version NSSM 2.24 stammt aus dem Jahr 2014. Auf der offiziellen Download-Seite wird ausdrücklich darauf hingewiesen, dass Nutzer von Windows 10 Creators Update, Windows Server 2016 oder neuer mindestens den Pre-Release-Build 2.24-101 oder einen neueren offiziellen Build verwenden sollten, weil 2.24 beim Starten von Diensten Probleme verursachen kann.

Die Build-Seite warnt gleichzeitig zu Recht davor, dass Development-/Pre-Release-Builds auf eigenes Risiko verwendet werden. Für produktive Systeme gilt daher: Version bewusst auswählen, testen und die verwendete nssm.exe anschließend nicht einfach austauschen.

Meine Empfehlung: Für aktuelle Windows-Systeme nicht blind die alte 2.24-ZIP aus irgendeinem Download-Portal nehmen. Starte auf der offiziellen NSSM-Seite, lies den Versionshinweis und verwende einen dort angebotenen Build, der den Fehler für neuere Windows-Versionen behebt.

Funktioniert NSSM unter Windows 11?

Die offizielle NSSM-Dokumentation ist sichtbar in die Jahre gekommen und nennt Windows 11 nicht ausdrücklich in ihrer Kompatibilitätsliste. Sie weist aber für Windows 10 Creators Update, Server 2016 und neuere Systeme auf die korrigierten Pre-Release-Builds hin.

Für Windows 11 würde ich NSSM deshalb nicht als „offiziell für Windows 11 zertifiziert“ verkaufen. Praktisch ist es weiterhin ein verbreiteter Service-Wrapper – aber du solltest einen aktuellen offiziellen Build verwenden und dein konkretes Setup testen.

Schnellstart: In 3 Schritten zum Windows-Service

cmd · Minimaler NSSM-Workflow

:: 1) nssm.exe in einen FESTEN Ordner legen, z. B.
C:\tools\nssm\nssm.exe

:: 2) Installationsdialog öffnen
C:\tools\nssm\nssm.exe install MeinDienst

:: 3) Dienst starten
C:\tools\nssm\nssm.exe start MeinDienst

Im Installationsdialog brauchst du für den Anfang nur drei Dinge: Application Path, Startup Directory und – falls nötig – Arguments. Danach kannst du Logging, Restart-Verhalten, Service-Account und weitere Optionen ergänzen.

Warum NSSM und nicht Taskplaner?

Der Windows-Taskplaner ist gut für zeitgesteuerte oder ereignisbasierte Jobs. Für einen Prozess, der wie ein echter Dienst dauerhaft laufen, beim Booten starten und kontrolliert neu gestartet werden soll, ist er aber oft nicht die sauberste Abstraktion.

NSSM registriert sich beim Service Control Manager (SCM) und startet deine Anwendung als überwachten Kindprozess. Dadurch kannst du den Dienst über services.msc, sc.exe oder NSSM selbst verwalten – inklusive Starttyp, Service-Account, Abhängigkeiten und Restart-Verhalten.

Wann NSSM fast immer die beste Abkürzung ist

Du hast eine “normale” App (Jar, Node, Python, Go, .NET Console) und willst 24/7 Betrieb.
Du willst Auto-Restart bei Crash, aber ohne eigene Watchdog-Skripte.
Du willst Logs + Rotation in einem Rutsch.
Du willst pro Service eigene Environment-Variablen setzen (ohne globalen System-Murks).
Du willst Least Privilege (dedizierter Account, minimale NTFS-Rechte).

Grundlagen: SCM, Session 0 und das “Warum sehe ich kein Fenster?”

Windows Dienste laufen (seit Vista) in Session 0. Das ist Absicht: Dienste sollen nicht auf dem
Benutzer-Desktop rumturnen. Konsequenz: Eine GUI siehst du nicht, Tray-Icons funktionieren nicht,
gemappte Laufwerke sind oft weg – und relative Pfade sind im Service-Kontext schnell “überraschend”.

Goldene Regel

Teste deine App zuerst manuell im selben Kontext wie später: gleicher Ordner, gleiche Pfade, gleiche User-Rechte. Danach erst als Dienst. Ein Service “macht nichts kaputt” – er macht Probleme nur sichtbar, die vorher versteckt waren.

Installation & Setup (GUI/CLI)

NSSM hat keinen klassischen Installer. Die offizielle Dokumentation empfiehlt, nssm.exe an einen festen Ort zu legen – idealerweise in einen Ordner, den du dauerhaft beibehältst.

Wichtig: Nach der Installation eines Dienstes solltest du nssm.exe nicht verschieben oder löschen. Windows registriert NSSM selbst als ausführbare Datei des Dienstes. Änderst du später den Pfad, musst du den Dienst entsprechend anpassen oder neu installieren.

cmd · Version prüfen und GUI öffnen

C:\tools\nssm\nssm.exe version
C:\tools\nssm\nssm.exe install MeinDienst

Für den ersten Dienst ist die GUI angenehm. Für reproduzierbare Deployments ist die CLI besser:

cmd · Dienst vollständig per CLI anlegen

C:\tools\nssm\nssm.exe install MeinDienst "C:\services\myapp\myapp.exe"
C:\tools\nssm\nssm.exe set MeinDienst AppDirectory "C:\services\myapp"
C:\tools\nssm\nssm.exe set MeinDienst AppParameters "--config C:\services\myapp\config.yml"
C:\tools\nssm\nssm.exe start MeinDienst

SEO-Suchbegriff „NSSM install“ – kurz beantwortet: nssm install öffnet die GUI. Mit nssm install [arguments] kannst du die Installation direkt per Kommandozeile durchführen.

NSSM Feature-Tour: die Parameter, die wirklich zählen

NSSM speichert Konfiguration pro Dienst in der Registry (unter dem jeweiligen Service-Key).
Du musst die Registry nicht anfassen – aber es hilft, die “Bausteine” zu kennen.
Unten sind die wichtigsten Werte, die du im Alltag wirklich brauchst.

Feature	NSSM-Setting / Registry	Beispiel	Warum es wichtig ist
Arbeitsverzeichnis	`AppDirectory`	`C:\services\myapp`	Relative Pfade, Config-Files, Log-Ordner funktionieren zuverlässig.
Parameter	`AppParameters`	`-jar app.jar --profile=prod`	Du startest die App exakt so, wie sie produktiv laufen soll.
Stdout/Stderr	`AppStdout` / `AppStderr`	`C:\services\myapp\logs\service.log`	Für zusammengeführte Ausgabe bei beiden Parametern exakt denselben Dateipfad setzen.
Log-Rotation	`AppRotateFiles`, `AppRotateOnline`, `AppRotateBytes`	`1`, `1`, `10485760`	Aktiviert Rotation und kann bei 10 MB auch während des Betriebs rotieren. Achtung: NSSM verwaltet keine feste Anzahl aufzubewahrender Logdateien.
Exit-Actions	`AppExit Default`	`Restart` / `Ignore`	Steuert: Neustart bei Crash? Oder “Exit 0” ist okay?
Backoff / Crash-Loop Schutz	`AppThrottle`, `AppRestartDelay`	`2000`, `5000`	Verhindert CPU-Vollgas bei “sofort wieder starten”.
Environment pro Dienst	`AppEnvironmentExtra`	`NODE_ENV=production`	Sauberer als System-weit – und pro Service getrennt.
Service-Account	`ObjectName`	`.\svc_myapp`	Least Privilege statt “LocalSystem, weil YOLO”.
Stop-Methoden	`AppStopMethod*`	Console + WM_CLOSE + Terminate	Damit deine App bei Stop “sauber” runterfährt (wichtig bei DB/Queues).
Dependencies	`DependOnService` (Windows-Feature)	`Tcpip`, `MSSQLSERVER`	Steuert die Startreihenfolge. Eine Service-Abhängigkeit garantiert aber nicht, dass eine Datenbank oder API bereits fachlich „ready“ ist.

Praxis-Shortcut: NSSM als “Config-Tool” verwenden

Du kannst Dienste komplett über CLI aufsetzen. Das ist ideal, wenn du Install-Skripte baust,
oder mehrere Maschinen identisch konfigurieren willst (Dev/Test/Prod).

Praxis 1: Java / Spring Boot als Dienst (robust & wartbar)

Java und Spring Boot sind klassische NSSM-Use-Cases. Für einen Konsolenprozess würde ich hier bewusst java.exe verwenden. Der Grund: NSSM kann beim Stoppen zunächst ein Control-C-Ereignis an die Konsole senden, und die NSSM-Dokumentation weist ausdrücklich darauf hin, dass Java-Anwendungen darauf typischerweise gut reagieren.

java.exe oder javaw.exe? javaw.exe ist laut Java-Dokumentation im Wesentlichen java.exe ohne zugeordnetes Konsolenfenster. Bei einem Dienst bringt dir „kein sichtbares Fenster“ wenig, weil Windows-Dienste ohnehin in Session 0 laufen. Für einen sauber stoppbaren Konsolenprozess ist java.exe deshalb meist die sinnvollere Wahl.

cmd · Java/Spring Boot komplett per CLI installieren

:: Beispiel-Ordnerstruktur:
:: C:\services\spring-prod\app.jar
:: C:\services\spring-prod\logs\

nssm install MeineSpringApp "C:\Program Files\Eclipse Adoptium\jdk-21\bin\java.exe"

nssm set MeineSpringApp AppDirectory  "C:\services\spring-prod"
nssm set MeineSpringApp AppParameters "-Xms512m -Xmx2048m -jar app.jar --spring.profiles.active=prod"

:: Pro-Service-Environment
nssm set MeineSpringApp AppEnvironmentExtra "TZ=Europe/Berlin" "JAVA_TOOL_OPTIONS=-Dfile.encoding=UTF-8"

:: stdout + stderr in dieselbe Logdatei
nssm set MeineSpringApp AppStdout "C:\services\spring-prod\logs\service.log"
nssm set MeineSpringApp AppStderr "C:\services\spring-prod\logs\service.log"

:: Rotation aktivieren; online ab 10 MB
nssm set MeineSpringApp AppRotateFiles  1
nssm set MeineSpringApp AppRotateOnline 1
nssm set MeineSpringApp AppRotateBytes  10485760

:: Neustart-Strategie
nssm set MeineSpringApp AppExit         Default Restart
nssm set MeineSpringApp AppThrottle    2000
nssm set MeineSpringApp AppRestartDelay 5000

nssm start MeineSpringApp

Wichtig bei Java: „Stop“ soll nicht brutal sein

Wenn dein Service Daten verarbeitet, willst du einen geordneten Shutdown. NSSM versucht mehrere Stop-Methoden nacheinander und kann als letzte Stufe den Prozess hart beenden. Gib deiner Anwendung ausreichend Zeit, selbst sauber herunterzufahren.

cmd · Stop-Timeouts für einen Java-Service

nssm set MeineSpringApp AppStopMethodConsole 15000
nssm set MeineSpringApp AppStopMethodWindow  15000
nssm set MeineSpringApp AppStopMethodThreads 15000
nssm set MeineSpringApp AppKillProcessTree    1

Hinweis: Die drei Timeouts sind separate Wartezeiten für unterschiedliche Stop-Methoden. Im ungünstigen Fall addieren sie sich, bevor NSSM zur nächsten Stufe übergeht. Also nicht einfach riesige Werte setzen, sondern passend zur Anwendung testen.

Tipp aus der Praxis: Lass Spring Boot seine eigenen Logs schreiben oder nutze NSSM-I/O-Redirect bewusst. Doppeltes Logging kann sinnvoll sein, ist aber oft unnötig.

Praxis 2: Node.js als Dienst – generisches Muster (Worker oder HTTP-Service)

Node-Dienste sind oft entweder:
(a) ein kleiner HTTP-Server (Webhook, API, Health-Endpoint) oder
(b) ein Worker, der Dinge pollt (Ordner überwachen, Queue lesen, Kamera-Snapshots verarbeiten …).
NSSM ist für beide Varianten super – solange du zwei Dinge beachtest: Working Directory und Environment.

Beispiel-Szenario (absichtlich generisch)

Ein Node-Worker überwacht einen Ordner (incoming\)
Verarbeitet Dateien (z.B. Bilder/JSON) und schreibt Ergebnisse nach processed\
Optional: sendet Benachrichtigungen (Mail/Chat/Webhook)

(Das Muster passt 1:1 auch auf “Snapshotter/Client”-Setups – nur ohne Tool-Spezifika.)

cmd · Node-Service installieren (Worker)

:: Ordnerstruktur:
:: C:\services\node-worker\worker.js
:: C:\services\node-worker\logs\

nssm install NodeWorker "C:\Program Files\nodejs\node.exe"

nssm set NodeWorker AppDirectory        "C:\services\node-worker"
nssm set NodeWorker AppParameters       "worker.js --watch incoming --out processed"

:: Pro Service Env
nssm set NodeWorker AppEnvironmentExtra "NODE_ENV=production" "TZ=Europe/Berlin"

:: Logs + Rotation
nssm set NodeWorker AppStdout           "C:\services\node-worker\logs\service.log"
nssm set NodeWorker AppStderr           "C:\services\node-worker\logs\service.log"
nssm set NodeWorker AppRotateFiles      1
nssm set NodeWorker AppRotateOnline     1
nssm set NodeWorker AppRotateBytes      10485760

:: Neustart-Strategie (Crash-Loop Schutz)
nssm set NodeWorker AppExit             Default Restart
nssm set NodeWorker AppThrottle         3000
nssm set NodeWorker AppRestartDelay     8000

nssm start NodeWorker

Häufiges Missverständnis: „Wenn’s crasht, starte ich sofort neu – dann läuft’s wieder.“
So sieht’s in der Praxis aus: Sofortige Restarts können den Schaden vergrößern (Crash-Loop, 100% CPU, Log-Spam). Mit AppThrottle + AppRestartDelay baust du einen simplen, aber wirksamen Backoff.

Wenn du statt Worker einen HTTP-Service hast, sieht’s praktisch identisch aus – nur die Parameter ändern sich:

cmd · Node-HTTP-Service (z.B. Express) mit PORT & Health

nssm install NodeApi "C:\Program Files\nodejs\node.exe"

nssm set NodeApi AppDirectory        "C:\services\node-api"
nssm set NodeApi AppParameters       "server.js"

nssm set NodeApi AppEnvironmentExtra "NODE_ENV=production" "PORT=8080"

nssm set NodeApi AppStdout           "C:\services\node-api\logs\api.log"
nssm set NodeApi AppStderr           "C:\services\node-api\logs\api.log"
nssm set NodeApi AppRotateFiles      1
nssm set NodeApi AppRotateOnline     1
nssm set NodeApi AppRotateBytes      10485760

nssm set NodeApi AppExit             Default Restart
nssm set NodeApi AppThrottle         2000
nssm set NodeApi AppRestartDelay     5000

nssm start NodeApi

Praxis 3: Python-Daemon als Dienst

Python ist oft “ein Script, das dauerhaft laufen soll”: Scheduler, Poller, Watcher, ETL-Mini-Jobs.
NSSM macht daraus einen echten Dienst – ohne dass du mit Windows-Service-APIs kämpfen musst.

cmd · Python-Daemon installieren (einfach & stabil)

nssm install PyDaemon "C:\Python312\python.exe"

nssm set PyDaemon AppDirectory  "C:\services\py-daemon"
nssm set PyDaemon AppParameters "main.py --config prod.ini"

nssm set PyDaemon AppStdout        "C:\services\py-daemon\logs\service.log"
nssm set PyDaemon AppStderr        "C:\services\py-daemon\logs\service.log"
nssm set PyDaemon AppRotateFiles   1
nssm set PyDaemon AppRotateOnline  1
nssm set PyDaemon AppRotateBytes   10485760

nssm set PyDaemon AppExit       Default Restart
nssm set PyDaemon AppThrottle   3000
nssm set PyDaemon AppRestartDelay 8000

nssm start PyDaemon

Praxis aus dem echten Einsatz: Zeus Herald mit NSSM

Aktuelles Praxisprojekt statt Demo-Code

Zeus Herald ist ein lokal betreibbarer Node.js-Dienst für Kamera-Snapshots, Bewegungserkennung und mobile Benachrichtigungen über Telegram, ntfy oder beide Kanäle. Das Projekt ist der aktuelle schlanke Nachfolger früherer Setups mit upcam-client, SnapShotter oder Browser-Automation.

Für diesen Artikel ist Zeus Herald besonders interessant, weil die Architektur ziemlich genau zeigt, wann mehrere getrennte Windows-Dienste sinnvoller sind als eine große Start-Batchdatei. Der eigentliche Kamera-Flow besteht bewusst aus zwei langlebigen Prozessen:

zeus-herald-ingest

npm run ingest ruft Kamera-Snapshots ab und schreibt sie in images/received/. Bei Reolink kann zusätzlich der kameraeigene Motion-State als Trigger genutzt werden.

zeus-herald-motion

npm run motion verarbeitet neue Bilder, bewertet Bewegung, verschiebt Frames nach images/filtered/ oder images/sent/ und reicht akzeptierte Bilder an Telegram und/oder ntfy weiter.

Die Trennung ist Absicht: ein Prozess = ein Dienst. Beide Worker besitzen eigene Prozess-Locks, können getrennt gestartet oder diagnostiziert werden und lassen sich unabhängig neu starten. Genau dafür ist NSSM als Wrapper praktisch.

Vor NSSM: Zeus Herald einmal sauber testen

cmd · Projekt einrichten und Funktion prüfen

git clone https://github.com/gzeuner/zeus-herald.git
cd zeus-herald
npm install

copy .env.example .env
:: .env jetzt lokal konfigurieren – niemals committen

npm run lint
npm test
npm run check:banned

:: Einzeltests vor dem Dauerbetrieb
npm run ingest:once
npm run notify:latest
npm run motion:once

Erst testen, dann als Dienst verpacken

Wenn ingest:once, notify:latest oder motion:once schon interaktiv scheitern, löst NSSM das Problem nicht. Der Service-Wrapper macht aus einem kaputten Prozess nur einen kaputten Prozess mit Dienstnamen.

Zwei NSSM-Services für den Dauerbetrieb

Die Betriebsdokumentation von Zeus Herald sieht unter Windows genau zwei Services vor. Als Application Path dient npm.cmd, als Startup Directory der Projektordner.

NSSM · Service-Modell für Zeus Herald

Service: zeus-herald-ingest
Path: C:\Program Files\nodejs\npm.cmd
Startup directory: C:\services\zeus-herald
Arguments: run ingest

Service: zeus-herald-motion
Path: C:\Program Files\nodejs\npm.cmd
Startup directory: C:\services\zeus-herald
Arguments: run motion

Der Node.js-Pfad kann auf deinem System anders aussehen. Mit where npm findest du den tatsächlich verwendeten Pfad zu npm.cmd.

Dasselbe reproduzierbar per CLI

cmd · Zeus Herald als zwei NSSM-Dienste anlegen

:: Pfad zuerst prüfen
where npm

:: Ingest
nssm install zeus-herald-ingest "C:\Program Files\nodejs\npm.cmd"
nssm set zeus-herald-ingest AppDirectory "C:\services\zeus-herald"
nssm set zeus-herald-ingest AppParameters "run ingest"
nssm set zeus-herald-ingest AppStdout "C:\services\zeus-herald\logs\ingest-service.log"
nssm set zeus-herald-ingest AppStderr "C:\services\zeus-herald\logs\ingest-service.log"
nssm set zeus-herald-ingest AppExit Default Restart
nssm set zeus-herald-ingest AppRestartDelay 5000

:: Motion
nssm install zeus-herald-motion "C:\Program Files\nodejs\npm.cmd"
nssm set zeus-herald-motion AppDirectory "C:\services\zeus-herald"
nssm set zeus-herald-motion AppParameters "run motion"
nssm set zeus-herald-motion AppStdout "C:\services\zeus-herald\logs\motion-service.log"
nssm set zeus-herald-motion AppStderr "C:\services\zeus-herald\logs\motion-service.log"
nssm set zeus-herald-motion AppExit Default Restart
nssm set zeus-herald-motion AppRestartDelay 5000

nssm start zeus-herald-ingest
nssm start zeus-herald-motion

Warum getrennte Logdateien? Zeus Herald schreibt strukturierte JSON-Logs auf stdout/stderr. Mit getrennten NSSM-Redirects siehst du sofort, ob ein Problem beim Kamera-Ingest oder in der Motion-/Notifier-Pipeline entsteht.

Health, Locks und Cleanup: der Teil nach „Service läuft“

Ein grüner Dienststatus bedeutet nur, dass der Prozess läuft. Zeus Herald ergänzt deshalb eigene Betriebsmechanismen:

Health-Datei: standardmäßig state/health.json mit Laufzeit-, Queue- und Notifier-Status.
Prozess-Locks: ingest und motion verhindern doppelte Worker über Lock-Dateien unter .lock/.
Decision-Sidecars: optionale JSON-Dateien helfen beim Nachvollziehen und Tuning der Bewegungserkennung.
Cleanup: alte Bilder, Sidecars und Logs können automatisch entfernt werden.
Diagnostik: zusätzliche Runtime- und Netzwerk-Telemetrie lässt sich bei Bedarf gezielt aktivieren.

Genau das ist der Unterschied zwischen „Autostart“ und Betrieb

NSSM kümmert sich um den Windows-Prozess. Die Anwendung selbst muss trotzdem Health, fachliche Readiness, Logging und Fehlerdiagnose liefern. Zeus Herald ist dafür ein gutes reales Beispiel: Windows sieht zwei Dienste – die Anwendung kennt zusätzlich Queue, Notifier, Locks, Cleanup und ihren eigenen Health-Zustand.

Update-Ablauf ohne Überraschungen

cmd · vereinfachter Update-Ablauf

nssm stop zeus-herald-ingest
nssm stop zeus-herald-motion

:: Repository aktualisieren oder neues Deployment entpacken
npm install
npm run lint
npm test
npm run ingest:once
npm run notify:latest

nssm start zeus-herald-ingest
nssm start zeus-herald-motion

Secrets bleiben außerhalb des Repositories

Zeus Herald hält Kamera-Zugangsdaten, Telegram-Tokens, Chat-IDs und ntfy-Konfiguration in der lokalen .env. Diese Datei gehört weder ins Repository noch in öffentliche Deployment-Artefakte. Für den Service-Account gilt zusätzlich: nur die Rechte vergeben, die der Prozess wirklich benötigt.

Projekt: github.com/gzeuner/zeus-herald
Betriebsdokumentation: Zeus Herald · Operations

Produktivbetrieb: Security, Accounts, Rechte, Secrets

Least Privilege: eigener Service-User
“LocalSystem” ist bequem, aber oft viel zu mächtig. Für produktive Services: eigener Account,
nur NTFS-Rechte auf C:\services\deinservice + logs.

cmd · Lokalen Service-User anlegen

:: Beispielhaft – Passwort nicht in Skripten oder Versionskontrolle ablegen.
net user svc_myapp * /add

Für eine interaktive Einrichtung ist der NSSM-Tab Log on die angenehmere Variante. Die offizielle Dokumentation beschreibt, dass NSSM dem gewählten Konto dabei die nötige Berechtigung „Log on as a service“ zuweist.

Keine echten Passwörter in Copy-&-Paste-Befehle schreiben. Für automatisierte Deployments Credentials aus einem geschützten Secret-Mechanismus beziehen, statt sie in Skripten, Shell-History oder Versionskontrolle abzulegen.

Secrets: lieber nicht in CLI-History brüllen
NSSM kann Env-Vars setzen – super für NODE_ENV, Pfade, Flags. Für echte Secrets: bevorzugt Windows Credential Manager, DPAPI-geschützte Files oder einen Secret-Store (je nach Umgebung). Wenn du Env nutzt: setze restriktive ACLs auf die Service-Registry/Ordner.

Minimal-Best-Practice: Config-Datei mit ACL nur für den Service-User + Admins.

Netzlaufwerke / gemappte Drives

Wenn deine App auf Z:\ zugreift und als Service “plötzlich” nicht mehr:
Das ist typisch. Services haben ihre eigene Session – gemappte Laufwerke existieren dort nicht zuverlässig. Nutze UNC-Pfade wie \\server\share\path und gib dem Service-Account Rechte.

Betrieb/Monitoring: Logs, Eventlog, Failure-Actions, Health

NSSM bringt schon viel mit, aber “Betrieb” ist mehr als “läuft bei mir”.
Ein gutes Setup hat immer: Logs, Rotation, Restart-Strategie,
und (wenn möglich) einen Healthcheck.

Empfohlenes Minimum für produktive Services

I/O-Redirect aktiv (oder App-Logging), Rotation an.
Crash-Loop Schutz über AppThrottle/AppRestartDelay.
Dedizierter Account + minimale NTFS-Rechte.
Windows-Failure-Actions zusätzlich setzen (zweite Sicherheitsleine).
Dokumentation: Pfade, Versionen, Parameter (damit “Future-You” nicht weint).

cmd · Windows Failure-Actions zusätzlich konfigurieren

:: Drei Neustarts, jeweils nach 60s, Reset nach 1 Tag
sc failure "MeineSpringApp" actions= restart/60000/restart/60000/restart/60000 reset= 86400

Wenn deine Anwendung einen Healthcheck anbietet (z. B. HTTP /health), solltest du ihn separat überwachen. NSSM überwacht primär den Prozess; ein laufender Prozess kann fachlich trotzdem kaputt oder festgefahren sein.

Alternativen 2026: NSSM vs. WinSW vs. nativer Windows-Service

NSSM ist schnell und pragmatisch, aber seine letzte stabile Version 2.24 stammt aus 2014; die neueren offiziellen Builds auf nssm.cc sind Pre-Releases aus 2017. Für bestehende, gut getestete Setups kann NSSM weiterhin völlig ausreichend sein. Bei neuen standardisierten Deployments sollte man die Alternativen bewusst mitprüfen.

Lösung	Konfig	Stärken	Schwächen	Wann ich’s nehmen würde
NSSM	GUI + CLI / Registry	Sehr schnell eingerichtet, Restart, I/O-Redirect, Service-Accounts	Offizielle Releases sehr alt; moderne Windows-Versionen brauchen bewusste Build-Wahl	Bestehende oder kleine, klar getestete Setups
WinSW	Dateibasierte Konfiguration	Gut versionierbar, Wrapper-Konzept für reproduzierbare Deployments	Mehr Setup; 3.x befindet sich weiterhin als Pre-Release-Linie in Entwicklung	Neue Projekte mit Config-as-Code-Fokus
.NET Worker Service	C# / .NET	Native Windows-Service-Integration, volle Kontrolle	Entwicklungsaufwand; für „nur einen Prozess starten“ oft Overkill	Wenn der Service Teil einer .NET-Anwendung ist oder tiefe SCM-Integration braucht
Task Scheduler	GUI / CLI	Gut für zeit- oder ereignisgesteuerte Jobs	Kein Ersatz für jede 24/7-Service-Anforderung	Batch-, Cron- und geplante Aufgaben

Troubleshooting: 15 häufige Probleme & schnelle Fixes

Service startet und stoppt sofort
Ursache: App beendet sich (auch “Exit 0”).
Fix: Logs prüfen, AppStdout/AppStderr setzen. Optional: Exit-Action anpassen.
Keine Logs werden geschrieben
Ursache: Pfad falsch oder Service-Account darf nicht schreiben.
Fix: Ordner logs anlegen + NTFS-Rechte geben, absolute Pfade nutzen.
Relative Pfade funktionieren nicht
Ursache: Working Directory ist nicht dein Projektordner.
Fix: AppDirectory immer explizit setzen.
Leerzeichen in Pfaden
Ursache: nicht korrekt gequotet.
Fix: überall "C:\Pfad mit Leerzeichen\..." sauber quoten.
Gemappte Laufwerke (Z:\) gehen nicht
Ursache: Session-Kontext des Dienstes.
Fix: UNC-Pfad nutzen \\server\share + Rechte für Service-Account.
Node-Service läuft manuell, als Dienst aber nicht
Ursache: ENV fehlt (NODE_ENV, PATH), oder Working Directory passt nicht.
Fix: AppEnvironmentExtra setzen, AppDirectory korrekt.
Java findet Config/Keystore nicht
Ursache: relative Pfade / falscher Startordner.
Fix: AppDirectory + absolute Pfade in Parametern.
Stop dauert ewig oder killt hart
Ursache: App reagiert nicht auf Stop-Signale.
Fix: Stop-Methoden/Timeouts sinnvoll setzen (z. B. 15 s statt Default 1,5 s), in der App graceful shutdown implementieren. Bei Child-Prozessen AppKillProcessTree beachten.
Crash-Loop frisst CPU
Ursache: sofortiger Restart bei sofortigem Crash.
Fix: AppThrottle und AppRestartDelay erhöhen (z.B. 3–10s).
Firewall blockiert
Ursache: java/node/python darf nicht raus/rein.
Fix: Firewall-Regel für den tatsächlich verwendeten Prozess (z. B. java.exe, node.exe oder python.exe) prüfen.
Service-Account kann den Dienst nicht starten
Fix: Konto, Passwort und die Berechtigung „Log on as a service“ prüfen. Wenn du den Account über den NSSM-Tab Log on setzt, weist NSSM diese Berechtigung laut offizieller Dokumentation normalerweise selbst zu.
App braucht Netzwerk, startet aber zu früh
Fix: Service-Abhängigkeit oder Startverzögerung nutzen – und für Datenbanken/APIs zusätzlich echte Readiness-/Retry-Logik in der Anwendung vorsehen.
Du siehst kein Fenster / keine GUI
Ursache: Session 0 Isolation.
Fix: expected behavior. Für GUI brauchst du ein anderes Konzept (oder getrennte UI).
Exit-Codes spammen Eventlog
Fix: Exit-Action pro Code setzen (z.B. bestimmte Codes ignorieren, andere restart).
“It works on my machine”
Fix: Service-Kontext nachbauen: gleicher Account, gleiche Ordner, gleiche Rechte – dann debuggen.

FAQ zu NSSM

Was bedeutet NSSM?

NSSM steht für Non-Sucking Service Manager. Es ist ein Wrapper, der normale Programme als Windows-Dienst startet und überwacht.

Wo kann ich NSSM sicher herunterladen?

Am besten direkt auf der offiziellen Seite nssm.cc/download. Bei Download-Portalen weißt du unter Umständen nicht, ob die Datei unverändert und aktuell ist.

Welche NSSM-Version sollte ich unter Windows 11 verwenden?

Die offizielle Dokumentation nennt Windows 11 nicht ausdrücklich. Sie empfiehlt aber für Windows 10 Creators Update, Server 2016 und neuer mindestens Build 2.24-101 oder einen neueren offiziellen Build. Verwende deshalb nicht unkritisch die alte stabile 2.24 und teste dein Setup.

Muss NSSM installiert werden?

Nein. nssm.exe wird an einen festen Ort kopiert. Wichtig: Nach dem Anlegen eines Dienstes die Datei nicht verschieben, weil der Windows-Service auf diesen Pfad verweist.

Wie installiere ich einen Dienst mit NSSM?

nssm install MeinDienst öffnet den GUI-Dialog. Alternativ kannst du Anwendung und Argumente direkt auf der Kommandozeile übergeben.

Wie entferne ich einen NSSM-Service?

Mit nssm remove MeinDienst öffnest du den Entfernen-Dialog; nssm remove MeinDienst confirm entfernt den Dienst ohne Rückfrage. Vorsicht: NSSM kann grundsätzlich auch andere Windows-Dienste adressieren.

Ist NSSM besser als WinSW?

Nicht pauschal. NSSM punktet bei schnellem, pragmatischem Setup. WinSW ist für neue, versionierbare Deployments oft attraktiver, weil die Konfiguration dateibasiert ist. Für echte Produktsoftware kann ein nativer Windows-Service die sauberste Lösung sein.

Glossar

Kurze Begriffe, die dir beim Lesen von Logs, SCM-Meldungen und NSSM-Optionen wirklich helfen:

SCM (Service Control Manager): Windows-Komponente, die Dienste startet/stoppt und deren Status verwaltet.
Session 0 Isolation: Dienste laufen in einer separaten Session ohne Benutzer-Desktop – keine GUI/Tray-Interaktion.
AppDirectory: Working Directory des Dienstes – entscheidend für relative Pfade.
AppStdout / AppStderr: Umleitung von Ausgabe in Dateien. Wenn stdout und stderr zusammengeführt werden sollen, bei AppStdout und AppStderr exakt denselben Pfad eintragen.
AppRotate*: Steuert die NSSM-Logrotation. AppRotateFiles aktiviert die Rotation; AppRotateBytes setzt eine Größenschwelle. Eine feste Anzahl aufzubewahrender Dateien verwaltet NSSM nicht.
AppExit: Regel: Was macht NSSM bei Exit-Code? Restart, Ignore, usw.
Least Privilege: Der Dienst bekommt nur die Rechte, die er wirklich braucht. Weniger Risiko, weniger Chaos.

Fazit: Welche Lösung passt zu dir?

Meine Kurz-Empfehlung für 2026:

Du willst schnell einen bestehenden Prozess als Dienst betreiben: NSSM ist weiterhin pragmatisch – aber auf aktuellen Windows-Systemen die Build-Hinweise der offiziellen Seite beachten.
Du willst reproduzierbares Config-as-Code für neue Deployments: WinSW mitprüfen.
Du brauchst tiefe Windows-Integration und entwickelst die Anwendung selbst: einen nativen Windows-Service bauen.

NSSM ist alt, aber nicht automatisch nutzlos. Entscheidend ist, dass du die Versionsfrage nicht ignorierst und die Details sauber konfigurierst: fester Pfad, Working Directory, Service-Account, Stop-Verhalten, Restart-Backoff und korrektes Logging.

Und genau da trennt sich „läuft bei mir“ von einem Dienst, den man auch Monate später noch gern anfasst.

Links & Ressourcen

Transparenzhinweis

Transparenzhinweis:
Die Inhalte auf tiny-tool.de werden sorgfältig recherchiert, redaktionell geprüft und regelmäßig aktualisiert. Quellen und Zitate werden möglichst nachvollziehbar angegeben. Dennoch übernehmen wir keine Garantie für Richtigkeit, Vollständigkeit oder Aktualität der bereitgestellten Informationen. Irrtümer sind nicht ausgeschlossen.

Redaktion und Einsatz von KI: Bei der Erstellung von Inhalten können digitale Werkzeuge – darunter auch KI-basierte Assistenzsysteme – unterstützend eingesetzt werden, etwa bei Recherche, Strukturierung, sprachlicher Überarbeitung, Übersetzung, Codeanalyse oder visueller Gestaltung. Veröffentlichte Inhalte werden redaktionell geprüft, bearbeitet und von Guido Zeuner freigegeben. Auswahl, Einordnung und Veröffentlichung liegen beim Menschen. KI-Ausgaben gelten nicht als eigenständige Quellen. KI-Systeme sind keine verantwortlichen Autoren oder Redakteure. Weitere Informationen zu Texten, Bildern, Videos und digitalen Personas findest du auf unserer Seite Transparenz beim Einsatz von Künstlicher Intelligenz.

Reichweitenmessung (VG WORT / METIS): Zur Ermittlung der Reichweite einzelner Texte können Zählmarken der VG WORT eingesetzt werden. Im Rahmen der METIS-Zugriffszählung kann eine Client-ID gebildet und ein sogenanntes „METIS Session Cookie“ gesetzt werden. Die Messung dient der statistischen Ermittlung von Textzugriffen und als Grundlage für mögliche Ausschüttungen der VG WORT. Nach Angaben der VG WORT werden dabei keine personenbezogenen Nutzungsprofile erstellt; die Messung dient nicht der Werbung oder dem Marketing-Tracking. Weitere Informationen findest du in unseren Datenschutzhinweisen.

Bitte beachte: Die Inhalte dienen ausschließlich der allgemeinen Information und stellen keine fachliche Beratung dar, insbesondere keine rechtliche, steuerliche, medizinische, technische oder finanzielle Beratung. Die Nutzung der Inhalte erfolgt auf eigene Verantwortung.

Werbung und Affiliate-Links: Einige Beiträge können werbliche Hinweise oder sogenannte Affiliate-Links enthalten. Diese werden entsprechend gekennzeichnet. Beim Klick entstehen dir keine zusätzlichen Kosten; wir erhalten gegebenenfalls eine kleine Provision.

Markenrechtlicher Hinweis: Alle Markennamen, Logos und Produktbezeichnungen sind Eigentum der jeweiligen Rechteinhaber und werden ausschließlich zur Identifikation und Beschreibung verwendet. Eine Verbindung zu den genannten Unternehmen besteht nur, wenn dies ausdrücklich angegeben wird.

Externe Links: Diese Website enthält Verweise auf externe Websites Dritter. Trotz sorgfältiger Prüfung übernehmen wir keine Verantwortung für deren Inhalte. Bei Bekanntwerden rechtswidriger Inhalte werden entsprechende Links geprüft und gegebenenfalls entfernt.