I have roughly 60 Python scripts that need to run continuously, mostly event handlers. At the moment, a separate launcher starts each script, checks its PID, and restarts it when necessary. It works, but becomes difficult to manage when updating a shared module, restarting everything after a deployment, or identifying scripts that crash repeatedly.
I'd like a more robust solution that works on Windows, can access several Samba shares through UNC paths, automatically restarts failed processes, and makes it easy to restart all services manually after an update. All of the scripts use the same Python environment.
The options I'm considering are Docker, PM2, and NSSM. Docker seems like it could add unnecessary complexity on Windows, especially around UNC paths and permissions. PM2 looks easier to configure, although it's more commonly associated with JavaScript, while NSSM seems straightforward for installing services but may offer less monitoring. What would you recommend?
5 Answers
PM2 works well with Python. You can specify the Python interpreter in its configuration, and it provides process supervision, automatic restarts, logs, and commands for restarting groups of applications. It isn’t limited to JavaScript in practice, so it’s worth trying for this use case.
Before choosing a tool, consider whether all 60 processes are really necessary. Some might be combined into a single application using separate workers, threads, or processes, which would reduce memory usage and simplify deployment. That said, keeping them separate can be the right choice when third-party libraries are not thread-safe or when one script launches external programs that can fail independently. In that situation, an operating-system process supervisor is safer than putting everything behind one entry point.
Another option is a maintained Windows service wrapper such as Servy. You could install one main supervisor as a Windows service and have it launch and monitor the scripts, or install the scripts individually if they truly need separate lifecycles. Windows Task Scheduler can also work for simpler setups, but it is less natural for long-running services.
Docker and Kubernetes would probably be excessive here, particularly on Windows with UNC shares, credentials, and file permissions. Containers can work, but you would be adding another layer to solve a problem that Windows services or a process manager already handles. If the application is eventually moved to Linux, mounted shares and container volumes may become more attractive, but keeping the current Windows environment should be simpler for now.
NSSM is a practical Windows-native option for turning each script into a service. It can restart crashed processes and redirect output to log files, and it handles ordinary Windows service management well. The drawbacks are that it feels somewhat dated, monitoring and reporting are fairly basic, and deployment requires managing the NSSM executable along with the service definitions.
That was the direction I was already leaning toward, so I’ll investigate its Python configuration and monitoring features.