Short answer: PM2 remains a credible, actively maintained process manager for Node.js, and now Bun, on a single Linux server. The v7 line is the version to evaluate. It is a good fit if you want supervised restarts, log capture, boot-time process restoration, and cluster mode without hand-writing systemd units. Before production, confirm the AGPL-3.0 terms fit your distribution model, make sure your apps run on Node.js 18+, test Bun cluster mode (an open issue reports it not working), and verify startup and update behavior on your exact distribution. This is an observed source and documentation review based on the GitHub repository, release notes, and open issues as of August 7, 2026; no runtime testing was performed.
Key facts at a glance
| Fact | Snapshot as of the review date |
|---|---|
| Review date | August 7, 2026 |
| License | README states AGPL-3.0; GitHub API lists Other (NOASSERTION); confirm before use |
| Stars | 43,254 (snapshot) |
| Language | JavaScript |
| Latest release | v7.0.3, published June 29, 2026 |
| Verification level | Observed: source and documentation review |
What PM2 is and what changed in v7
PM2 is described by its maintainers as a production process manager for Node.js/Bun applications with a built-in load balancer. Per the README, it keeps applications alive, reloads them without downtime, and supports Linux, macOS, and Windows with Node.js 18+ and Bun 1+. The v7 series landed on May 2, 2026, followed by three patch releases within two months, so this is an actively moving target.
v7.0.0: breaking change and security work
- Node.js 16 support dropped. The maintainers now require Node.js 18.0.0 or newer.
- Bun runtime support added. The release notes mention new Bun process containers and Bun support in the test runner.
- Supply-chain refactor. Several npm modules (pm2-axon, pm2-axon-rpc, pm2-io-bpm, pm2-io-agent, fclone, multimeter, charm) were internalized to reduce the dependency surface, and needle was replaced with native fetch.
- Security fixes. The maintainers list fixes for CVE-2025-5891 (ReDoS), CVE-2026-27699 (proxy-agent and basic-ftp), command injection in several open() paths, prototype pollution in configuration handling, and an env-stripping bug in the HTTP interface.
- Dependency changes. OpenTelemetry tracing was added as direct dependencies, and pidusage was updated from 3.0.2 to 4.0.1.
- Testing additions. A Docker parallel test runner with Node and Bun support, plus a Windows test suite, were added.
v7.0.1: regression fixes
- Fixed a Python (and other non-Node) interpreter regression on Ubuntu caused by Bun detection matching any path containing “bun”, such as /home/ubuntu.
- Reverted a Windows cmd.exe launcher regression by returning the bin/pm2 files to a node shebang.
- Documented the workaround for Bun-only installs: symlink node to bun so the shebang resolves.
v7.0.2: output, metrics, and dependency bumps
- Fixed pm2 serve returning 403 on Windows, plus pm2 ls table and terminal-width issues.
- Replaced the old vizion module and the bundled pm2-sysmonit/systeminformation stack with an internal SysMetrics collector on Linux and macOS.
- Bumped js-yaml to 4.3.0 (GHSA-h67p-54hq-rp68), ws to 8.21.0 (GHSA-58qx-3vcg-4xpx, GHSA-96hv-2xvq-fx4p), and @pm2/js-api to 0.8.1. The maintainers state that production dependencies are now advisory-free, based on npm audit –omit=dev.
v7.0.3: daemon boot fix
The only documented change is a fix for the daemon failing to boot on Node.js below 14.18, because the embedded vizion code used node:-scheme requires and now uses bare specifiers. Note the tension: v7.0.0 requires Node.js 18+, so the release note’s reference to Node.js below 14.18 is not explained by the maintainers and is worth checking if your environment boots the daemon with an older system Node.
Who should consider PM2
The strongest case is one or more Node.js services on a single Linux VM or VPS where you want restart-on-crash behavior, log capture, cluster mode on multi-core machines, and processes restored after a reboot. The README’s core workflow is short:
pm2 start app.js
pm2 startup
pm2 save
Monitoring is available in the terminal with pm2 monit, and if you already run containers, pm2-runtime is offered as a drop-in entrypoint for Node in Docker.
Who should be cautious
- Node.js 16 deployments. v7 requires Node.js 18+, so you must either stay on the v6 line (v6.0.14, November 2025) or upgrade Node first.
- Bun cluster users. Issue #5893, open and updated as recently as May 2026, reports that clustering with Bun spawned fork mode instead of cluster mode in the reporter’s setup.
- AGPL-sensitive businesses. The README says PM2 is AGPL-3.0 and offers other licenses on request. If you distribute or modify it as part of a commercial product, get legal review before adopting.
- Windows-first operations. Windows is listed as supported, but long-open issues (popup windows since 2016, .mjs launch errors) suggest extra validation effort.
- Container-first teams. If you are already on Kubernetes or a managed container platform, an in-host process manager overlaps with what the orchestrator already does.
What to check before production
- License terms. The GitHub API reports the license as Other (NOASSERTION) while the README states AGPL-3.0; resolve that discrepancy before depending on it.
- Runtime compatibility. Verify every managed app runs under Node.js 18+; check interpreter paths for Python or other non-Node scripts after the v7.0.1 regression fix.
- Boot persistence. Run the startup flow (pm2 startup, then pm2 save) on your actual distribution and reboot-test it; systemd startup failures are documented in issue #3924.
- Log rotation. The README directs users to install pm2-logrotate for rotation; decide your retention policy before logs grow.
- Upgrade path. The README procedure is npm install pm2@latest -g followed by pm2 update; test that on a staging server, since it restarts the daemon and processes.
- Dependency audit. The maintainers claim a clean production audit in v7.0.2; run your own npm audit against the version you actually deploy.
Deployment concerns and known rough edges
Bun support is new and partially open
v7 adds Bun support, but issue #5893 remains open and reports that Bun clustering falls back to fork mode in the reporter’s environment. If Bun cluster mode matters to you, verify it on your exact Bun version before committing.
Ecosystem files are not a full declarative config system
Issue #3742, open since 2018, reports that pm2 restart with an ecosystem.config.js does not apply changed values such as a new script path; the running process keeps its old configuration. If you treat the ecosystem file as the source of truth, test how your version applies changes, or use delete-and-start as a fallback.
Windows has a history of edge cases
v7.0.1 fixed a cmd.exe launcher regression, and v7.0.2 fixed a pm2 serve 403 on Windows, which is reassuring for a Windows workflow. Still, issue #2182 (popup windows, open since 2016) and issue #4591 (launching .mjs files) indicate the Windows path has had recurring problems. Budget time for validation if Windows is a target.
Process visibility is per-user and child processes are not tracked
Issue #1661 explains that pm2 list shows processes for the current user, so a multi-user server needs sudo to see root-started apps. Issue #1869 notes that processes your app forks manually are not shown in pm2 list/monit. Plan separate monitoring for worker processes if you rely on them.
Limitations of this review and what is unknown
This is an observed source and documentation review. The evidence is the repository metadata, README, release notes, and open issues collected on August 7, 2026; no local installation or runtime testing was performed. Statements such as zero-downtime reload, advisory-free dependencies, and Bun support are the maintainers’ claims, not independently verified results. The license discrepancy between the GitHub API and the README was not resolved here, and the v7.0.3 fix targeting Node.js below 14.18 is not explained alongside the Node.js 18+ requirement. Open-issue counts and issue states are a snapshot and will change.
Evaluation questions before you commit
- Do all production runtimes satisfy the Node.js 18+ requirement?
- Does AGPL-3.0 fit how you distribute or sell your software?
- Do you need Bun cluster mode? If yes, reproduce issue #5893 in your environment first.
- Do you manage apps through ecosystem files and expect restarts to apply config changes? Issue #3742 says test that.
- Do you run many small Node services on one server, or one large service? PM2’s value is highest with the former.
- Do you need cross-user process visibility or child-process monitoring? Issues #1661 and #1869 cover those gaps.
- Is Windows a deployment target? If so, validate serve, log paths, and launcher behavior.
Verdict
PM2 is a reasonable default for Node.js on a single Linux VM. The v7 line addresses dependency and security concerns, the maintainers are shipping patches quickly, and the basic workflow remains simple. The decision changes if you are on Node.js 16 (stay on 6.0.14 or upgrade), if Bun cluster mode is required (test first), or if AGPL-3.0 is a blocker (use native systemd units or a container platform instead). Plan the v7 move as a small project: confirm licensing, update Node, reboot-test startup, and re-run your own dependency audit.
If you are planning a PM2 v7 migration or auditing a server that already runs an older PM2 release, I help with exactly these checks: runtime compatibility, startup and log configuration, and a documented upgrade path matched to your stack. That is the Linux server deployment and maintenance work I do at XP812, and I am happy to review your setup before you commit to it.
Sources
- Unitech/pm2 repository
- PM2 v7.0.3 release notes
- PM2 v7.0.2 release notes
- PM2 v7.0.1 release notes
- PM2 v7.0.0 release notes
- PM2 v6.0.14 release notes
- Issue #5893: Clustering not working with Bun
- Issue #3742: pm2 restart ecosystem.config.js does not reload app details
- Issue #3924: pm2 startup systemd failure
- Issue #2182: Windows 10 popups
- Issue #1661: process visibility across users
- Issue #1869: child process monitoring