If you work with Node.js, you've probably heard of PM2. It's a popular process manager for Node.js applications and comes with several extra features, like load balancing and monitoring.
But just because it's popular doesn't mean it's the best choice for every project. In fact, there are some good reasons why you might want to think twice before using it.
This article takes a closer look at PM2 and the problems it can cause. We'll explore situations where other tools, like Docker, might be a better fit.
We'll discuss PM2's downsides, including its proprietary features and licensing issues. By the end, you'll have a clear picture of whether PM2 is right for your Node.js projects.
Problems
Before you jump on the PM2 bandwagon, it's crucial to understand the potential trade-offs and challenges it presents.
Overselling the cluster feature
Most of the online material mentions things like “PM2 has built-in load balancer” or “You can run the application in cluster module and take higher traffic volumes.”
The problem here is people talking about those features without a context. The context here is that PM2 uses a Node cluster module to make those things possible, and I already covered why you probably don’t need the cluster module.
In short, it doesn’t make much sense to have all of those features inside of a single Node server, especially when it comes to modern pipelines, CI/CD practices, and modern deployment strategies.
While it is not directly related to PM2 itself but more to the community around it, it doesn't change the fact that you'll most often encounter clusters in applications that use PM2 than without it.
Proprietary monitoring
One of the features that PM2 itself sells hard is monitoring. Monitoring is a good thing to have, and it shows you how your application and server are doing. The more data you have, the better decisions you can make. People build multi-million dollar businesses on it; take Datadog or Sentry as an example.
The problem with PM2 monitoring is vendor lock-in. You cannot take the data from what PM2 has collected and move it to a third-party monitoring service — at least not that easily. It all comes down to money. PM2 itself provides an advanced monitoring service, but to have access to it, you have to pay.
It doesn’t mean you cannot use other services' monitoring. However, if you think of monitoring as one of the PM2 cool features, you have to think about it again.
Attempts to solve too many problems
It feels like PM2 is trying to solve the problems it shouldn’t be solving but is doing so because “why not?”
It leads to poor results. Those problems are not solved well enough, and you suffer from the consequences.
To name a few:
Memory management: The process manager tries to manage the memory of the running processes by restarting a process based on the consumed memory. However, it has a 30-second window in which it checks memory consumption. Even if the process goes beyond the limit, it might take up to 30 seconds to shut it down, and you cannot do much about it.
Persistent application: PM2 can restart the process automatically whenever the machine restarts. It uses systemd daemon, which is used on UNIX-based OS. Because of it, you can run into problems with it on Windows. The other thing is you have to hassle around and update systemd daemon service whenever you want to change the Node.js version.
Deployment: Doesn’t it sound odd that the process manager is somehow involved in the deployment process? This limits you to a bare metal deployment, which means no containers.
There are more to the list, but you get the idea.
Hard to justify usage with containers
If you use containers in your Node.js application, PM2 becomes redundant.
One of the most popular solutions for working with containers, Docker, provides many similar PM2 features. The difference? They are a lot more reliable.
As a contrary example to the PM2 problems:
Superior resources management: You can limit memory usage, CPU, and GPU. Those limits are more flexible and reliable. For example, if a container reaches the limit of consumed memory, you’ll know it almost immediately. There is no fixed 30-second window.
Reliable application persistence: It is possible to configure restart policies for Docker containers. Whenever the host machine is restarted, the Docker daemon spins up and restarts all containers configured for it. The best part is that it works seamlessly on Unix-based OSes as well as Windows. Also, you don’t need to do manual work whenever you change the Node.js version. The container will do it for you.
Deployment: Containers make it extremely easy to deploy new applications because of their isolated environment. However, they do not attempt to deploy themselves as PM2 does.
Licensing
Another major issue is the licensing under which PM2 is distributed. It uses GNU AGPL-3 license. While the license might not say much to you, here are some of the implications of the license:
If your project uses a library licensed under the GNU AGPL-3 and distribute it over the internet, you are automatically forced to distribute it under the same license.
Some of the licenses are not compatible with the GNU APGL-3. If you’re using more than one library — I assume you do — you must ensure no conflicting licenses.
Projects distributed over a network, like web applications, must allow users to see and download their source code.
As you can see, those are not the best conditions, especially if we compare them with MIT.
That’s the exact reason why Google restricts any usage of code under this license.
When can it be actually useful?
To talk about the cases where it can be actually useful, we have to check a couple of points that we’ve discussed previously:
The main benefit of PM2 is simplicity. It tries to solve many problems by being a simple process manager for this exact reason.
You don't need to learn how to deploy your application, configure a load balancer, configure daemons for automatic restarts, or set up a monitoring system manually.
Just use the tool.
Conclusion
While there are certainly cases when you might see yourself using PM2, especially because of its simplicity, there are too many implications.
It tries to go beyond a simple process manager with the same user-friendly approach, which results in not-so-great implementations of those extra features, especially when compared with solutions that are meant to solve those problems, like resource management with containers.
Another huge pain point is licensing. Honestly, it is hard to imagine people willingly accepting the license condition. I assume that most users are simply not aware of the implications it brings.
