Servy: wrapping any Windows process as a managed service

From any executable to a Windows service without rewriting source code

Windows services run before any user logs in and survive reboots, but the Windows Service Control Manager requires an application to implement its own API. Servy sits in between: it registers itself as the service and then manages your process. Node.js servers, Python scripts, Go binaries, and anything else that runs from a command line can act as Windows services without any modifications to their source code.

The configuration options cover more ground than most wrappers. Each registered service gets its own name, description, startup type, process priority, CPU affinity, working directory, command-line parameters, environment variables, and dependency list. Environment variables can appear inside parameter strings and path fields, so a single configuration can reference variables that differ across machines.

Services can run under Local System, a local or domain account, or a group managed service account (gMSA). That last option matters in enterprise environments where every service is expected to run as a named, audited principal rather than under the built-in system account. The project's stated use cases include web servers, LLMs, background workers, sync tools, daemons, task runners, and schedulers, covering the range of processes most teams need to persist across reboots.

WinGet, Chocolatey, Scoop, and a fallback for older Windows

Three package managers carry the self-contained modern build: WinGet, Chocolatey, and Scoop. That build covers Windows 10 (build 1809 or later), Windows 11, and Windows Server 2016 or later on x64 and ARM64.

winget install servy

Chocolatey users run:

choco install -y servy

For Scoop, the extras bucket must be added first:

scoop bucket add extras
scoop install servy

Systems that pre-date those versions use a separate path. Download `servy-x.x-net48-x64-installer.exe` or `servy-x.x-net48-x64-portable.7z` directly from GitHub Releases. That build requires .NET Framework 4.8 and covers Windows 7 SP1, Windows 8.x, and Windows Server 2008 R2 or later, but only on x64. ARM64 is not listed as a supported architecture for the legacy build. Servy is also available in the Patch My PC catalog for enterprise deployment via Microsoft Intune and Configuration Manager (SCCM), covering automated update distribution across a managed device fleet.

The servy-cli install command and what each flag controls

Registering an existing application as a service takes one elevated PowerShell call. All servy-cli commands that install or remove Windows services require an administrator prompt, because those operations need elevated privileges.

The README gives a Node.js example that covers the minimum required flags:

servy-cli install `
  --name="MyService" `
  --path="C:\Program Files\nodejs\node.exe" `
  --startupDir="C:\MyServer" `
  --params="server.js" `
  --enableHealth

This registers a service named MyService. `--path` is the executable, `--startupDir` sets the working directory used at startup, and `--params` passes arguments to the process. `--enableHealth` switches on health monitoring so that Servy restarts the process on crash or hang. The startup directory is separate from the executable path, which lets the Node.js binary sit in its own folder while the server script resolves relative to the working directory.

Pre-launch, post-launch, pre-stop, and post-stop hooks are available as additional flags, each with configurable retries, timeouts, and failure handling. The wiki documents additional examples for Python, Java, Go, and other runtimes beyond the Node.js case in the README.

Health checks, heartbeat pings, and three termination paths

Automatic restart fires on crashes, hangs, and stops, based on health checks rather than on process exit codes alone. That difference matters for processes that hang without exiting: a pure exit-code check would never trigger a restart for a frozen server.

External heartbeat pings are a separate mechanism. Servy can send pings to an external URL, with healthchecks.io given as the example, so a monitoring service receives a signal that the process is still functioning rather than merely that the service entry exists in Windows SCM. A missed ping is a signal the process is unhealthy even if it has not exited.

Stopping a process cleanly is a harder problem than starting one. Servy uses three strategies depending on the application type: Ctrl+C for console applications, a close message for GUI applications, and Ctrl+C propagation to child processes for those that spawn child trees. Force termination applies when the process does not respond to those signals within the configured timeout. Servy also terminates the entire process tree on stop, preventing orphaned child processes from accumulating after the parent exits.

Notification delivery uses both Windows notifications and email, so operators receive alerts when a service crashes or stops outside of scheduled maintenance windows.

AES-256 with HMAC authentication and named-pipe isolation arrive in v10.2

Version 10.2, released on 2026-10-05, added the security features the project describes as enterprise-grade isolation. The IPC model uses Windows named pipes between Servy components, with kernel-level PID validation and Discretionary Access Control List (DACL) checks on each connection. A process that is not the expected Servy component cannot send commands through the pipe even if it knows the pipe name.

Credential storage combines DPAPI, HKDF, and AES-256 with HMAC-based authenticated encryption. The vault ACL is hardened automatically when a service is installed, restricting access to that data to the service's own account. Per-service isolation means one service's vault data is not readable by another service's account, which matters when multiple services share a machine but run under different principal accounts.

All releases, including those before v10.2, ship with signed binaries, Software Bill of Materials (SBOMs), and continuous vulnerability scanning. Those controls predate v10.2; the per-service isolation and encryption features are the addition in that version. Security.md and Architecture.md in the wiki document the model in detail.

ARM64 is supported on the modern build but absent from the legacy net48 installer

Platform support splits into two tracks with a hard difference at the architecture level. The modern, self-contained build supports Windows 10 (build 1809 or later), Windows 11, and Windows Server 2016 or later on both x64 and ARM64. The ARM64 entry appears only in this track.

The legacy build, identified by the net48 suffix in release filenames, requires .NET Framework 4.8 and supports Windows 7 SP1, Windows 8.x, and Windows Server 2008 R2 or later. The published platform list for the legacy build specifies x64 only. Anyone deploying Servy on an ARM64 device running Windows 8 or Server 2008 R2 falls outside the documented support range.

Servy runs only on Windows. The description reads "Enterprise-Grade Windows Service Wrapper", and every security and IPC mechanism it uses, Windows named pipes, DACL, DPAPI, and the Windows SCM itself, is specific to the Windows platform. If your deployment includes Linux or macOS servers, Servy does not apply.

Export, import, and the Manager app for multi-service oversight

Three management surfaces exist beyond the CLI. The desktop app provides interactive access to service creation and configuration. The Manager app covers a different scope: it shows all installed Servy services at once, with live CPU and RAM usage graphs, real-time log tailing, and a dependency tree view showing the status of each service in the chain.

Service configurations can be exported and imported, supporting backup, migration, and the kind of reproducible setup where a reference configuration moves between environments. The PowerShell module (Servy.psm1) enables the same operations inside CI/CD pipelines, so a deployment script can install, configure, and start services as part of a larger automation sequence without manual steps.

Log collection captures both stdout and stderr to files, with size-based or date-based rotation configured per service. Live log tailing and search are available in the Manager app and the desktop app, so debugging a misbehaving service does not require opening a separate log viewer. The wiki documents examples and recipes for Python, Java, Go, and other runtimes in addition to the Node.js example, and each runtime may need different parameter conventions.

Editorial conclusion

Servy suits Windows shops that need to turn background applications into managed services with crash recovery, health monitoring, and automated restart, without changing the application code. The v10.2 security model adds per-service credential isolation and AES-256 encryption, which matters when services run under separate accounts. Skip it for any deployment that includes Linux or macOS, because all its mechanisms are Windows-only. Before relying on it in production, check whether the enterprise security features in v10.2 apply to your account model, read Security.md and Architecture.md in the wiki, and verify the platform track against your OS version and architecture, since the legacy net48 build does not cover ARM64.

Frequently asked questions

Official sources

1. aelassas/servy on GitHub
2. License: MIT
3. Project website
4. README
5. Releases