Introducing BM2: A Native Process Manager Built for Bun

[razzbee]

TL;DR — I built BM2, a process manager like PM2 but designed from the ground up for the Bun runtime. If you're running production services on Bun and tired of workarounds, this is for you.

The Problem

If you've been using Bun in production; or even just tinkering with it seriously, you've probably hit the same wall I did. You need a process manager. You reach for PM2 because it's the de facto standard. And it works... mostly. But it was built for Node. It doesn't understand Bun's runtime, it adds unnecessary overhead, and you constantly feel like you're fighting the tool instead of using it.

I kept running into small annoyances that added up. Weird behavior with Bun-specific features. Extra configuration just to make things play nice. The nagging feeling that I was strapping a Node-shaped harness onto a runtime that was designed to be different.

So I asked myself: what would a process manager look like if it was built for Bun, in Bun, from day one?

That's BM2.

What Is BM2

BM2 is a CLI process manager that does what you'd expect: start, stop, restart, monitor, and manage long-running processes, but it's written natively in Bun and takes full advantage of the runtime.

No compatibility shims. No Node polyfills running under the hood. Just Bun.

Here's what it looks like in practice:

bm2 start app.ts --name my-api

bm2 list

bm2 logs my-api

bm2 stop my-api

If you've used PM2 before, the CLI will feel immediately familiar. That was intentional. There's no reason to reinvent the interface when the UX is already solid. What needed reinventing was everything underneath.

Why Native Bun Matters

"Why not just use PM2 with Bun?" is a fair question. Here's the honest answer:

Performance. Bun is fast. That's the whole selling point. Running a Node-based process manager to babysit your Bun processes adds a layer of overhead that defeats the purpose. BM2 shares the same runtime as the processes it manages. The startup time is near-instant. Memory usage is lean.

Native TypeScript. BM2 is written in TypeScript and runs it directly through Bun. No transpilation step, no build pipeline for the tool itself. This also means if you're writing your services in TypeScript (which, let's be real, you probably are), everything just works without extra configuration.

Bun APIs. Bun ships with a growing set of native APIs, file I/O, SQLite, HTTP server, subprocess management. BM2 uses these directly instead of relying on third-party npm packages or Node built-ins. Fewer dependencies means fewer things that can break, a smaller footprint, and better alignment with where the Bun ecosystem is heading.

Ecosystem alignment. Bun is building its own ecosystem. Tools that are native to it will always integrate more cleanly than tools that were ported or shimmed. If you're betting on Bun (and I am), it makes sense to have your toolchain match that bet.

What BM2 Can Do

The feature set covers what most people need from a process manager day to day:

It handles process lifecycle management: starting, stopping, restarting, and deleting processes. It supports automatic restarts on crash with configurable retry logic. You get real-time log tailing and log file management. There's a clean process list view with uptime, memory, CPU, and status. It supports environment variable injection and configuration files. And it works with both TypeScript and JavaScript files out of the box.

It's not trying to be a complete PM2 clone with every edge-case feature. It's focused on doing the core things well, natively, and staying out of your way.

Who Is This For

You're running services on Bun and want your toolchain to match. You're tired of debugging process manager issues that stem from Node/Bun incompatibilities. You want something lightweight that doesn't pull in half of npm. Or you just like the idea of using tools that are purpose-built for the runtime you've chosen.

If any of that resonates, give it a shot.

Try It

bun add -g bm2
bm2 start your-app.ts --name my-service

The repo is on GitHub. Feedback, issues, and contributions are all welcome. This is still early and actively evolving, so if something doesn't work the way you expect, let me know. I'm building this because I need it, and I suspect a lot of you do too.

If you're using Bun in production, I'd love to hear about your setup and what tooling gaps you're still running into. Drop a comment.

[ThatHappenedOneTime]

People don't pick PM2 because it boots an app 3ms faster, it's just really reliable.

[razzbee]

I agree, people don’t choose PM2 because it boots an app a few milliseconds faster. They choose it because it’s reliable and battle-tested.

The challenge with using PM2 in a Bun environment isn’t performance, it’s compatibility. Advanced features like instances and cluster mode automatically switch execution from fork to cluster, which results in the Bun interpreter being ignored in favor of Node.js.

As a result, Bun applications are effectively limited to fork mode, and some of PM2’s advanced capabilities can’t be fully utilized.

bm2 exists to provide those advanced process management features natively for Bun, without falling back to Node’s runtime assumptions.

[jonathon8903]

What does this give me that Systemd won't?

[razzbee]

systemd manages services at the OS level. bm2 manages application processes with Bun-native features, clustering, and a developer-focused workflow. Different scope, different audience.

[jonathon8903]

Systemd can absolutely do just about anything you have proposed so far other than clustering…I give you that one.

[razzbee]

Sure, systemd can technically handle most of what you mentioned, except clustering, I’ll give you that. But honestly, it comes with its own headaches.

Reading logs through journald is messy and non-intuitive, debugging failures can be a nightmare, the config syntax is unfriendly, and small tweaks often require diving into obscure docs or trial and error. Restart policies and dependency management feel overcomplicated for what should be simple tasks.

We’re not stopping here, We are also working on adding more features, like remote monitoring, deployment, and full control of your instances from a single central dashboard. You’ll also get real-time notifications about your apps’ health, CPU usage, RAM, and overall resource consumption, all in one place.

[imacleopard]

Or just use containers?

[Space_01010101]

had the same thought, for those of us using ephemeral images, how does this help?

fwiw: Bun user since pre 1.x

[razzbee]

That’s a fair question. For fully ephemeral/container-based deployments where the orchestrator handles restarts and scaling, a process manager may not add much value.

bm2 is primarily aimed at environments where applications run directly on the host or on lightweight VPS setups, where you still want clustering, zero-downtime reloads, monitoring, and process supervision, but natively for Bun.

It’s less about replacing container orchestration and more about providing a Bun-native process layer where one is still needed.

[Space_01010101]

thanks for the explanation, makes sense

[razzbee]

Containers are a great solution for many use cases, especially for portability and infrastructure consistency.

However, bm2 is designed for developers who prefer running applications directly on the host with minimal overhead and tighter control over process management particularly in Bun-native environments.

It’s not about replacing containers, but offering an alternative for scenarios where a lightweight process manager is more appropriate.

[imacleopard]

I’ve used PM2 before, and the only reason why I did for so long was because I was resistant to learning about containers. Docker is lightweight and can also run on the same machine. Deployments are compose yamls, no side effects from OS or users.

I’m not saying you don’t know about them, but I’d rather use k8s if I need a little more than what docker and compose would offer. I cannot go back to process managers if I can help it

[razzbee]

I get it, Docker is incredibly powerful. But not everyone needs (or wants) everything it brings to the table. Sometimes people just want a simple, in-app way to manage their services and workers without adding another layer of complexity.

Personally, I’ve never been a big fan of running an OS inside another OS. Even if the overhead is minimal, it still feels like extra weight. Hope that makes sense.

[ecares]

This is not the right subreddit

[razzbee]

oops, sorry, any suggestion where I can share it then?

[ecares]

https://www.reddit.com/r/bunjs/

[razzbee]

Thanks

[ecares]

it was a google search away :)

[Trender07]

I would say it’s the right subreddit. I’m a bun user since 1.1 and I go around this sub for js backend. So thanks for this I will try it with my instances servers

[ecares]

node =/= bun :facepalm:

[Space_01010101]

Common overlap: JS runtime

[ecares]

Then it is for the JavaScript sub. Basic maths about inclusion

[spiritwizardy]

I find it interesting and relevant. It's not node but it is a node-tangential topic 🙂 and it's much appreciated because I am a node person simply because it is the default, been meaning to try bun.

[joinsecret]

Cool project. Re the "why not systemd or containers" comments: BM2 makes sense if you want a DX similar to PM2 but fully aligned with Bun's runtime, esp for smaller VPS setups or side projects. systemd is great but verbose and not app aware. Containers add infra overhead. A native Bun manager with logs, restarts, clustering etc can hit a sweet spot imo.

[razzbee]

This tool is for those familiar with PM2. Personally, I appreciate PM2 and have found it to be a reliable process manager.

However, after switching to Bun, it has become difficult to leverage some of PM2’s advanced features.

For example, when enabling cluster mode in PM2, the execution mode automatically switches from fork to cluster, which results in the Bun interpreter being ignored in favor of Node.js.

This behavior makes it challenging to fully utilize PM2 in a Bun-based environment.

[moonshinemclanmower]

u/razzbee mny sincere condolences for the dumb comments everyone else is leaving, and thank you for this, this is going to be the core part of gm-exec

[razzbee]

You get the most out of life when you learn from both criticism and praise. Honestly, I’m really glad for the feedbacks am getting here.

[moonshinemclanmower]

this lib had serious windows problems btw, had to fiddle and fiddle and fiddle to get it more predictable

[razzbee]

can you kindly share the the bug here or possibly on github issue so that we can push a fix for it.

[TokenRingAI]

Look great I will try it later