nssm-redux

README

nssmr (Non-Sucking Service Manager Redux)

Currently a work in progress, but early feedback is welcome! See the compatibility notes for details on the current scope and design decisions.

nssmr is a Go port of NSSM, the Non-Sucking Service Manager for Windows.

This repository is intentionally starting with a strong CLI and service-runtime core instead of trying to port the legacy GUI first. The current codebase already installs and runs arbitrary executables as Windows services, persists settings in the familiar Parameters registry layout, and ships CI/release automation for Windows binaries.

Table of Contents

• Status
• Quick Start
• More Configuration Examples
• Build
  • Windows hosts (PowerShell)
  • Unix-like hosts (make)
• Docs
• Credits
• License

Status

nssmr is an early CLI-first Go port of NSSM focused on Windows service installation, configuration, and runtime supervision.

The current milestone covers the core management commands, registry-compatible Parameters storage, restart policy, hooks, process controls, and log rotation.

The legacy GUI is intentionally out of scope for now. See the compatibility notes for detailed parity coverage and current gaps, and the GUI parity checklist for a feature-by-feature comparison with classic NSSM.

Quick Start

nssmr wraps an existing executable and runs it as a Windows service. In the examples below, worker.exe is your application, not part of nssmr.

1. Install a service for your application:

   nssmr install MyService "C:\apps\worker.exe" --config "C:\apps\worker.yml"
   

   Everything after the executable is stored as AppParameters.

2. Configure the working directory, logs, and startup behavior:

   nssmr set MyService AppDirectory "C:\apps"
   nssmr set MyService AppStdout "C:\logs\worker.out.log"
   nssmr set MyService AppStderr "C:\logs\worker.err.log"
   nssmr set MyService DisplayName "My Worker Service"
   nssmr set MyService Start SERVICE_DELAYED_AUTO_START
   

3. Start the service and inspect the stored configuration:

   nssmr start MyService
   nssmr status MyService
   nssmr get MyService AppParameters
   

More Configuration Examples

Show more configuration examples

After install, you can layer on more advanced behavior:

nssmr set MyService AppDirectory "C:\apps"
nssmr set MyService AppStdout "C:\logs\worker.out.log"
nssmr set MyService AppStderr "C:\logs\worker.err.log"
nssmr set MyService AppEnvironment "ENV=prod" "PORT=8080"
nssmr set MyService AppEvents Start/Pre "C:\hooks\before-start.cmd"
nssmr set MyService AppRotateFiles 1
nssmr set MyService AppRotateOnline 1
nssmr set MyService AppTimestampLog 1
nssmr set MyService AppPriority ABOVE_NORMAL_PRIORITY_CLASS
nssmr set MyService AppAffinity 0-3
nssmr set MyService AppStopMethodSkip 0
nssmr set MyService ObjectName "NT AUTHORITY\LocalService"
nssmr set MyService Start SERVICE_DELAYED_AUTO_START

Inspect or export configuration:

nssmr get MyService AppParameters
nssmr processes MyService
nssmr rotate MyService
nssmr dump MyService

[!NOTE] The service subcommand is the internal SCM entrypoint used by the installed Windows service and is not intended for normal interactive use.

Build

Source builds currently require Go 1.26.1 or newer, matching go.mod.

Windows hosts (PowerShell)

Show Windows build instructions

Use the PowerShell helper from the repository root with PowerShell 7+ (pwsh):

.\build.ps1 test
.\build.ps1 build
.\build.ps1 build-windows

This writes the host binary to bin\nssmr.exe and the Windows release artifacts to:

• dist\nssmr-windows-amd64.exe
• dist\nssmr-windows-arm64.exe

build.ps1 keeps GOCACHE and GOMODCACHE inside the repo at .gocache/ and .gomodcache/, which avoids depending on a writable user-profile cache.

Windows VERSIONINFO fields are read from build/windows-versioninfo.json. Edit that file to change the embedded product metadata, or point build.ps1 at another JSON file with -VersionInfoFile.

Run .\build.ps1 help to see the full task list, including vet, lint, fmt, and clean.

VS Code workspace tasks are under .vscode/tasks.json and use pwsh on Windows, so you can run the same flows from Terminal -> Run Task.

Unix-like hosts (make)

Show Unix-like build instructions

If you already have GNU make and a POSIX shell available, the existing Makefile targets still work:

make test
make build
make build-windows

[!Note] You can build on non-Windows hosts and run most tests, but the install command, service control, and the managed-process runtime only work on Windows.

Windows cross-builds also embed VERSIONINFO metadata from build/windows-versioninfo.json. You can override that path with make build-windows WINDOWS_VERSIONINFO=/path/to/versioninfo.json.

Docs

• Changelog
• Documentation index
• Compatibility and parity notes

Credits

• NSSM for the original design and registry model

License

MIT