Systemd also gives you cpu/memory limiting, file system isolation, locked down capabilities for the process, CPU affinity, can use different Node versions for different apps, etc. It removes the need for Docker for the vast majority of cases.

Systemd won’t do load balancing, but you should have nginx/caddy in front of Node anyway, and either will handle load balancing just fine.

What about creating new processes?

Yep, systemd is an excellent and stable process runner - it can start your processes whenever, with dependencies (eg redis/pg), or on a flexible schedule etc.

I created a Node.js binding for sd-notify to cover at least some of the use case here: https://github.com/systemd/node-sd-notify

I don't think systemd has a built-in load balancer. Also, running multiple copies of the same service isn't typical PID-1 stuff, so maybe doing that with systemd involves some friction.

Running multiple "copies" of a service is very much in systemd's wheelhouse; it's called templated units.

I know about templates, but I don't believe they are designed for fungible copies. You can run a bunch of [email protected], but it's not the same UX as `pm2 start my-app -i number-of-copies`.

They work very well for "worker" processes. The default ssh package on Debian uses systemd template units for the user process; I've used them extensively for job queue workers, in combination with max execution time and a separate timed job to monitor queue load (essentially automatic scale up/down of queue workers).

Realistically if your prod environment relies on you manually running `pm2... ` or whatever, you're doing something wrong. User Experience should have about 0% impact on how your service daemons run.

systemd can run Node.js apps easily, but unless your applocation is doing something special for multithreading that is single threaded. PM2 makes it trivial to run an application in cluster mode.