Welcome to the Servy Frequently Asked Questions guide. Servy is a purpose-built Windows service manager designed to run non-service applications, including those written in Node.js, Python, Go, or .NET, as reliable and first-class Windows services.

Many background applications begin life as simple console processes. In production environments, however, they often require structured lifecycle management such as automatic restarts, graceful shutdowns, and continuous monitoring of resource usage. Servy bridges the gap between portable application code and the Windows Service Control Manager (SCM) by providing a centralized way to manage logs, environment variables, process health, and recovery behavior without requiring changes to the application itself.

This FAQ is intended for IT administrators modernizing legacy workloads as well as power users building automated systems and CI/CD pipelines. It covers topics ranging from initial setup and configuration to advanced lifecycle hooks and process tree management.

1. What's the use case for Servy?
2. Should I run an app as a service or a tray app?
3. Things that should be a service should just already be a service?
4. Why choose a Windows service instead of building outside the Windows ecosystem?

1. Is Servy the same as Windows Task Scheduler?
2. How does Servy compare to sc.exe?
3. How does Servy compare to NSSM?
4. How does Servy compare to WinSW?
5. How does Servy compare to SrvAny?
6. How does Servy compare to Docker Desktop?
7. How does Servy compare to Tanuki's wrapper and is it compatible with Waratek RASP?
8. Can Servy replace PM2 for Node.js on Windows?
9. Why not Microsoft.Extensions.Hosting.WindowsServices?

1. What types of applications can Servy run as a service?
2. How do I run scripts like batch or PowerShell with Servy?
3. Does Servy support both console apps and GUI apps?
4. Can I set a custom working directory?
5. Does Servy support running services under custom user accounts?
6. How do I update a service configuration?
7. Can I use Servy in automated deployments (CI/CD)?

1. Does Servy support automatic restarts?
2. What happens if the monitored process crashes?
3. Does Servy support running a script on service failure?
4. What is the pre-launch hook in Servy?
5. What happens if the pre-launch hook fails?
6. Can I pass arguments and environment variables to the pre-launch process?
7. Is the pre-launch hook synchronous or asynchronous?
8. What is the post-launch hook in Servy?
9. When is the post-launch process executed?
10. What happens if the service stops while the post-launch process is waiting?
11. Can I pass arguments to the post-launch process?
12. Can I use post-launch for long-running scripts?
13. What is the difference between a Pre-Stop and a Post-Stop hook?
14. If the timeout is 0, does the Pre-Stop hook still run?
15. What is the danger of a 0-second timeout on a Pre-Stop hook?
16. Is the service recreated after config change?

1. Can I capture stdout and stderr logs?
2. Is there a way to view service logs in real time?
3. Can Servy send notifications or emails on service failures or restarts?
4. Does Servy provide CPU and RAM monitoring?

1. How does Servy stop the app?
2. How does Servy prevent zombie processes?
3. Will Java shutdown hooks run when a Servy service running a Java app shuts down?
4. Does Servy make requests for additional service shutdown time?
5. When exactly does the Pre-Shutdown signal occur?
6. What happens if the OS shuts down or reboots?

1. Why do I need admin privileges?
2. Is Servy compatible with older Windows versions?
3. Does Servy work on offline servers?
4. Can Servy be used as part of an installer without requiring extra dependencies?
5. What happens if I uninstall Servy?

1. Does Servy support environment variables for the wrapped process?
2. Does Servy support service dependencies?
3. Does Servy support gMSA and AD log on?
4. Why does Excel COM automation fail when my application runs as a Windows service?
5. Can Servy run OneDrive as a Service using Azure Login?
6. Does Servy support ClickOnce-like update behavior?
7. Can Servy run Windows Update from a PowerShell script as a service?

The main use case is running non-service apps as proper Windows services in a reliable and observable way.

This is useful when you have background apps like web servers, workers, schedulers, or long-running tools written in Node.js, Python, Go, or .NET. For example, an internal REST API, a background job processor, a file watcher that syncs data, a message queue consumer, a local build agent, a monitoring or metrics collector, or an automation tool that needs to run continuously in the background.

These types of applications usually need to start automatically on boot, restart if they crash or hang, run under specific local or domain accounts, expose logs for troubleshooting, and shut down cleanly during reboots or deployments without leaving orphaned processes behind.

Servy is intended for developers, IT administrators, and power users who want more control and visibility than basic service wrappers provide, especially around logging, lifecycle hooks, health checks, and monitoring.

Tray apps work well when the app is tied to an interactive user session, but a Windows service addresses a different set of needs. Services are useful when an app must run independently of a logged-in user. They start at system boot and continue running even when no one is signed in, which is important for background workloads or machines accessed over remote sessions.

Services also integrate with SCM (Service Control Manager), which provides predictable startup and shutdown behavior, automatic restart on failure, and consistent handling during system updates or reboots. Tray apps often stop when a user logs out or a session disconnects, while services continue running uninterrupted. This makes them more reliable for long-running processes such as local APIs, background workers, schedulers, or monitoring agents.

Security is another important factor. Services can run under dedicated accounts with limited permissions, which is not always practical for user-session applications. In practice, tray apps make sense for user-facing tools that require interaction, while services are better suited for infrastructure-style workloads that need to operate consistently regardless of who is logged in.

Ideally, anything that is intended to run long term on a server should be implemented as a proper Windows service from the start.

In practice, though, wrappers and service managers exist because real environments are not always ideal. A lot of software that ends up running on Windows Server was not originally written as a service. That includes legacy internal tools, third-party software where the source is not available, cross-platform apps that were designed to run as console processes, and vendor utilities that assume a Linux-style supervisor rather than the Windows Service Control Manager.

This is not limited to any one language. Node.js, Python, Java, Go, and some legacy apps often start life as console applications because that is the most portable and simplest execution model. Rewriting them as native Windows services is not always feasible or cost-effective, especially when the application already works reliably and only needs predictable startup, shutdown, and recovery behavior.

Windows services are still relevant in enterprise, regulated, and on-prem setups where Windows remains the standard. A lot of production workloads are not cloud native and cannot easily be moved to containers or Linux.

Servy is not about promoting Windows over other platforms. It is about solving a real, recurring problem for teams that already run on Windows and need reliable background processes with proper lifecycle management, logging, and recovery. For those environments, a Windows service is still the correct and supported solution.

Not exactly. While Task Scheduler can run tasks at boot, it's not as reliable or fully featured as a proper Windows service manager, which starts at boot, continuously supervises the process, and applies restart and recovery behavior.

Where Servy differs is in intent and ergonomics rather than raw capability. Task Scheduler can be made to behave like a service, but doing so usually requires careful trigger configuration, credential management, recovery logic via additional tasks, and external monitoring. That works, but it’s not its primary design goal.

Servy is purpose-built to manage a single long-running process as a Windows service. It starts at boot, runs under the Service Control Manager, continuously supervises the process, and applies restart, health, logging, and lifecycle rules in one place.

sc.exe doesn't wrap any app as a service; it only manages binaries already specifically written to communicate with the Windows Service API. If you try to force a regular executable through it, the service will usually time out and fail because it doesn't know how to talk to the Service Control Manager (SCM). Servy acts as that necessary bridge, allowing you to run any app as a service without rewriting a single line of code.

Beyond just staying alive, Servy replaces many tools with a single dashboard. Instead of jumping between Task Manager for RAM, Event Viewer for system errors, and raw text files for logs, you get live telemetry and searchable stdout/stderr in one view. It also handles complex lifecycle logic like running cleanup scripts, post-stop hooks, checking dependencies or pre-launch hooks, that sc.exe simply isn't built to handle.

Servy and NSSM let you run any app as a native Windows service, but they solve related but slightly different problems.

Where Servy differs is visibility and day-to-day operations. With Servy you can see what a service is doing in real time, including CPU and RAM usage, live stdout and stderr output, dependency tree, and searchable logs, all from one place. This avoids jumping between Event Viewer, log files, and Task Manager when diagnosing issues.

Servy also treats service lifecycle as a first class concept. It allows running pre-launch, post-launch, pre-stop, and post-stop actions with proper logging, timeouts, and failure handling.

WinSW is a solid tool but lacks some flexibility. It doesn't have a graphical user interface and is primarily an XML-configured wrapper. While WinSW supports setting a working directory, its health check and automatic recovery features are limited compared to Servy. WinSW's restart strategies rely mainly on exit codes but don't provide active health checks (like heartbeat monitoring) or advanced recovery options such as restarting the child process or the entire system after repeated failures.

For very simple scenarios, SrvAny can be sufficient when the goal is simply to start a process as a service. The trade-offs tend to appear around the service lifecycle and day-to-day operations. Once clean startup and shutdown behavior, recovery actions, and consistent logging become important, the limitations of SrvAny show. Servy provides the operational control and visibility that SrvAny lacks.

Just as Docker Desktop takes the black box of containers and gives you a visual dashboard for logs, resource usage, and lifecycle management, Servy does the same for the Windows Service Control Manager. It essentially modernizes the management of native background tasks so you don't have to hunt through system tools like Event Viewer or Services.msc just to see if your app is behaving.

The key difference is that while Docker provides an isolated environment (containers), Servy provides observability and control for native processes. It's perfect for scenarios where you want the Docker-like visibility of live stdout/stderr and resource telemetry, but you need your application to run directly on the host OS with full access to the Windows environment. It brings that modern, container-style management workflow to traditional Windows infrastructure.

Tanuki’s wrapper is tightly focused on the JVM and Java process lifecycle, often injecting native libraries. Servy is language-agnostic and treats the application as an external executable, staying outside the JVM boundary.

Because Servy does not instrument or modify the JVM, it avoids many compatibility issues with tools like Waratek RASP. As long as the JVM is launched with the correct options, Servy manages the service lifecycle without interfering with internal Java operations.

Yes. Servy can replace PM2 on Windows by running node.exe directly as a native Windows service. Instead of keeping PM2 alive, your Node.js backend is managed by the Windows Service Control Manager (SCM), which is generally more reliable on Windows.

Where Servy helps most is stability and lifecycle management: native startup and shutdown, predictable restarts, logging, recovery, hooks, environment variables, service dependencies, and resource monitoring. This avoids many of the reliability issues PM2 users encounter on Windows.

If your goal is to keep a Node.js backend running reliably on a Windows server, replacing PM2 with Servy is a straightforward solution.

Microsoft.Extensions.Hosting.WindowsServices is aimed at apps designed to be Windows services from the ground up.

Servy is for the opposite situation: when you already have an app and you can't or don't want to rewrite it. You point Servy to an exe, and it adds practical operational features like logging, restart policies, and lifecycle hooks without changing the application code.

Servy can run any executable, including Node.js, Python, .NET apps, batch scripts, and PowerShell scripts.

Run them via their interpreters (cmd.exe or powershell.exe) by specifying the interpreter as the executable and the script path as a parameter.

Yes. While services usually run background tasks, Servy can also host GUI apps as services if needed, though GUI interaction will be limited in service contexts (Session 0). This is generally discouraged by Microsoft and should only be used for legacy or transitional scenarios.

Yes, Servy allows you to specify the startup directory to avoid path issues common with Windows services.

Yes, you can run a service under LocalSystem, domain accounts, AD, gMSA, or any custom user account with the required permissions.

If a service is already installed, you can update its configuration through Servy Manager. Simply open the service's configuration, make your changes, and click Install to apply them. Finally, restart the service to ensure all changes take effect.

Absolutely. Servy provides a CLI and a PowerShell module, making it easy to script service installation and configuration as part of automated workflows.

This makes it suitable for tools like Azure DevOps agents, self-hosted runners, or internal build workers.

Yes, it includes health checks and configurable automatic recovery and restart policies.

Servy executes the configured recovery action (restart service, restart process, restart computer, run failure program, or none).

Yes, Servy provides an optional failure program to run after all recovery attempts have failed (and, when health-monitoring is disabled, when the child process exits with a non-zero code).

The pre-launch hook is an optional script or executable that runs before the main service process starts. It can be used to prepare the environment or validate dependencies.

If the pre-launch hook exits with an error, Servy stops the service startup to prevent running the main process in an invalid state, unless the Ignore Failure option is enabled.

Yes, you can configure both arguments and environment variables for the pre-launch process. Servy expands any environment variables before running the process.

The pre-launch hook runs synchronously by default. If the pre-launch timeout is set to 0, it starts in fire-and-forget mode (asynchronously).

The post-launch hook is an optional script or executable that runs after the main service process has started successfully and survived the startup health check.

Servy waits for a configurable timeout (default 10 seconds) to ensure the main process does not exit prematurely. If the process remains alive, the post-launch action is executed asynchronously.

If the service stops before the post-launch process runs, the wait is canceled and the post-launch process will not run.

Yes, you can configure both arguments and working directory for the post-launch process.

Yes, the post-launch process runs independently of the main service process.

A Pre-Stop hook executes before the main stop signal (a Ctrl+C console control event, CTRL_C_EVENT) is sent to the process. It is used for tasks like removing a node from a load balancer or finishing current work. A Post-Stop hook runs after the process has fully exited, typically used for cleaning up temporary files, releasing locks, or sending final logs.

Yes, the hook is triggered, but the orchestrator does not block or wait for it to complete. It immediately proceeds to send the stop signal (Ctrl+C first, falling back to TerminateProcess after the stop timeout) to the main process. This is useful for "notification-only" hooks where you want to log an event but don't need to clean up before the process dies.

The main risk is race conditions. If your Pre-Stop hook is meant to "drain" traffic or save a state, and the main process exits 10 milliseconds later, the hook will likely be terminated mid-execution. Use a 0 timeout only for non-critical side effects (like sending a "Goodbye" message to a Slack channel).

Servy does not recreate the Windows service when you change the application path, parameters, or other runtime settings.

Servy acts as a service wrapper. The Windows service that gets registered in the Service Control Manager is Servy.Service.exe itself. The executable path, arguments, working directory, and other settings are stored in Servy's internal configuration. When you modify those settings, Servy updates its own configuration and uses it when launching the target process. The Windows service entry is not deleted and recreated for those changes.

If you make changes to the configuration, click Install, and then restart the service so that the changes take effect, that does not affect the Service SID or any permissions granted to it, as long as the service is not deleted and recreated.

When Install updates the existing service in place, the Service Control Manager entry remains the same. The service name does not change, and Windows does not generate a new Service SID. Since the Service SID is derived from the service name, it remains stable across configuration updates.

As a result, any permissions granted to NT SERVICE\YourService on folders, files, or other resources continue to apply.

Windows generates the Service SID based on the service name. As long as the service is not deleted and recreated, and the service name does not change, the Service SID remains the same.

If you configure a Servy service to run as Local Service and grant modify permissions to NT SERVICE\YourService on a folder, those permissions remain valid after changes to:

• Application path
• Command line parameters
• Working directory
• Other internal Servy wrapper settings

These changes do not affect the service identity or its SID.

The Service SID will only change if you:

• Delete and reinstall (uninstall then install) the service
• Recreate it under a different name
• Explicitly change the service name

In those cases, Windows generates a new SID and any permissions granted to the old SID will not carry over.

In short, configuration changes inside Servy do not impact the service SID or permissions. Only removing and recreating the Windows service itself would do that.

Yes, Servy can redirect stdout/stderr to log files with automatic rotation based on file size or date. Logs are stored as files and are separate from the Windows Event Log. They can be viewed through the Servy Manager with live tailing.

Yes, Servy Manager includes a log viewer with filtering and search, so you can quickly diagnose issues without leaving the app.

Yes, Servy can generate notifications and send emails when an error occurs, helping you stay informed about service health.

Yes, Servy Manager includes CPU and RAM monitoring accessible in two views:

• Services Tab (Grid View): Provides an overview of resource usage across your configured services in real time.
• Performance Tab (Real-Time Graphs): Displays CPU and RAM usage in real time for detailed monitoring.

Metrics details include:

• CPU: Usage is reported as a percentage of total machine capacity, which aligns with Windows Task Manager's CPU column behavior.
• RAM: Servy reports the process's committed private memory (the total unshared memory requested by the service, including memory currently paged to disk).
• Process Tree Aggregation: Servy dynamically aggregates metrics across the entire process tree. This means the reported performance data includes the core wrapped service process as well as all active child and descendant processes spawned by it.

Note on RAM values: Operators comparing Servy to Task Manager will notice that Servy's RAM values are generally higher than Task Manager's default "Memory" column. This is intentional. Task Manager defaults to showing the Private Working Set (only the memory currently sitting in physical RAM). Because Windows aggressively pages background service memory to disk under pressure, Working Set is an unreliable metric for monitoring background processes. Servy uses the Commit Size to ensure you see the true memory footprint of your service, making it much easier to detect memory leaks and actual resource consumption.

If the child process is a console app, Servy sends a Ctrl+C signal to stop it gracefully. It waits a few seconds (configurable) for the process to exit; if it doesn't, Servy forces a kill. This procedure is repeated for each child process and its descendants recursively.

Servy tracks the full process tree it creates and manages it explicitly. When a service is stopped or restarted, Servy first attempts a graceful shutdown of the main process by propagating a Ctrl+C signal to the main process and all of its descendants, allowing applications to exit cleanly. If the process does not exit within the configured timeout, it is forcefully terminated.

This shutdown procedure is applied recursively to all child processes and their descendants, ensuring no orphaned processes are left behind. Any pre-launch or post-launch processes are also terminated with their entire process trees when the service stops.

As a result, Servy prevents zombie or runaway processes that continue consuming CPU or RAM after the service has been stopped.

Yes. When the service receives a stop request, Servy sends a Ctrl+C console control event to the Java process. The JVM interprets this as an interrupt signal, triggers the normal shutdown sequence and executes all registered hooks.

Yes. Servy explicitly requests extra time from the SCM when the configured start/stop timeout exceeds a threshold (configurable) using the standard RequestAdditionalTime mechanism.

It occurs when the Windows Service Control Manager (SCM) detects that the OS is shutting down or rebooting. It is sent before the standard "Stop" command. Windows waits for services that have registered for Pre-Shutdown to finish before it even begins the standard service shutdown phase. When a system shutdown or reboot is detected, Servy executes a specialized teardown workflow designed to ensure data integrity and a graceful exit.

When a system-level shutdown or reboot is initiated, Servy intercepts the Windows Pre-Shutdown signal, triggering a specialized teardown workflow that prioritizes data integrity. Servy silences the health monitor to prevent redundant recovery attempts and utilizes "Wait Hints" to grant the child process an extended window to flush buffers and commit transactions. This high-priority sequence ensures that even during a reboot, the service orchestrates a graceful departure rather than a forced termination.

Creating and controlling Windows services requires elevated permissions.

The modern build supports Windows 10 (1809+), Windows 11, and Windows Server 2016+. Legacy systems such as Windows 7 SP1 and Server 2008 R2 are also supported via a dedicated .NET 4.8 build. See the Installation Guide to choose the right version for your OS.

Yes. Servy works perfectly on offline servers. Installation does not require internet access, and there are no external dependencies to download.

Yes. The portable servy-cli.exe is a single self-contained executable and requires no additional frameworks.

Services installed with Servy remain registered in Windows and working until you explicitly uninstall them. You can remove them safely through Servy Manager or the CLI. The service continues to function because it is a standard SCM-registered service, not dependent on the Servy UI or CLI.

Yes, Servy provides full support for environment variables. You can configure these through the Advanced tab in the Servy Desktop App, the --envVars flag in the Servy CLI, or the -EnvVars parameter within the PowerShell module. Furthermore, Servy allows for environment variable expansion within process paths, working directories, and parameters, ensuring your configuration remains dynamic and flexible across different environments.

Yes, service dependencies can be managed easily within the ecosystem. You can define these dependencies via the Advanced tab in the Servy Desktop App, the --deps flag in the CLI, or the -Deps parameter in the PowerShell module. For better oversight, the Servy Manager allows you to visualize these relationships alongside real-time status indicators, where green signifies a running service, red indicates a stopped service, and orange warns of a dependency cycle.

Yes, Servy provides comprehensive support for Group Managed Service Accounts (gMSA) and Active Directory (AD) logons, alongside standard domain and local accounts. It is also compatible with passwordless accounts and built-in Windows service identities such as NetworkService and LocalService. You can configure these credentials within the Log On tab of the Servy Desktop App, by using the --user and --password flags in the CLI, or via the -User and -Password parameters in the PowerShell module. For gMSA and passwordless accounts, the password field should be left blank, allowing Servy to manage the authentication handshake automatically with the domain controller.

This is expected behavior. Microsoft Excel requires an interactive user session. When an application runs as a service, it executes in Session 0, which has no interactive desktop. The recommended approach is to use libraries like Open XML SDK or EPPlus that do not rely on COM.

OneDrive usually requires interactive login, which services cannot perform. However, you can use Servy to run a PowerShell/Graph API script that handles synchronization as a background service.

Yes, in a service-safe way. The recommended approach is to use a pre-launch hook that checks for updates before the service starts. This ensures the update happens without file locking or race conditions.

Yes, it is technically feasible, but you must ensure the script has the required administrative privileges (running under LocalSystem) and handles reboots and idempotency cleanly.