If you're a modern JavaScript or TypeScript developer, you've probably played a little runtime roulette.
One legacy project runs on Node.js. Your newer service uses Deno. Another project runs on Bun because you want its performance and built-in tooling.
The problem isn't choosing a runtime.
The problem is managing all of them.
Production tooling often assumes one runtime, which can leave you juggling different process managers, custom scripts, or compatibility layers just to keep your applications running.
That's the problem the latest version of ProcBoss (pboss) is designed to solve.
One Process Manager. Multiple Runtimes.
The latest ProcBoss update makes it runtime-agnostic without sacrificing native runtime APIs.
You don't need one process manager for Node.js, another solution for Deno, and something else for Bun.
You can use a single pboss installation to manage applications running on all three.
For example:
pboss --runtime=bun start --name bun_server ./bun_server.ts
pboss --runtime=deno start --name deno_server ./deno_server.ts
pboss --runtime=node start --name node_server ./node_server.ts
One process manager.
Three runtimes.
One consistent operational workflow.
And importantly, ProcBoss doesn't force those applications onto the same runtime.
Runtime-Agnostic Doesn't Mean "Use Node.js Everywhere"
There are different ways to build a multi-runtime tool.
The easy approach is to pick one runtime's APIs and build compatibility layers around everything else.
That wasn't the approach I wanted for ProcBoss.
Bun, Node.js, and Deno each provide their own native APIs for process management, filesystem access, HTTP servers, and other capabilities.
ProcBoss uses a runtime adapter architecture to preserve those differences instead of hiding them.
For process spawning, for example:
Bun → Bun.spawn
Node.js → node:child_process
Deno → Deno.Command
The core process manager works with capabilities rather than directly depending on one runtime.
The runtime adapter provides the native implementation.
So when ProcBoss runs under Bun, it uses Bun's APIs.
When it runs under Node.js, it uses Node's APIs.
When it runs under Deno, it uses Deno's APIs.
There isn't a Node.js compatibility layer sitting between ProcBoss and Bun or Deno.
That's what makes the runtime-agnostic architecture useful rather than simply being a compatibility wrapper.
The Same Applies to Clustering
This is where the update gets particularly interesting.
A process manager that can start applications across different runtimes is useful.
A process manager that can scale those applications using native process capabilities across those runtimes is much more useful.
ProcBoss provides native cluster mode for Bun, Node.js, and Deno.
You can run multiple instances of an application:
pboss start server.ts --name api --instances max
Or specify the number of instances:
pboss start server.ts --name api --instances 4 --port 3000
Each instance is a supervised process managed by ProcBoss.
That means clustering isn't tied to node:cluster.
Instead, ProcBoss uses the appropriate process APIs for the runtime being managed.
The result is a consistent clustering model across runtimes.
Scale Without Changing Your Tooling
Suppose you have three applications:
Bun API
Deno API
Node.js API
They can all be managed by the same ProcBoss installation.
You can scale them independently and manage their lifecycles through the same process manager.
For a running application, you can change its instance count:
pboss scale my-api 8
And perform a graceful reload:
pboss reload my-api
This allows workers to be replaced progressively rather than simply killing everything and starting it again.
The exact behavior depends on the application's runtime and configuration, but the important part is that the process-management layer remains the same regardless of which JavaScript runtime your application uses.
It Goes Beyond start
Runtime support is only part of the update.
ProcBoss is designed to handle the operational problems that appear once your application is actually running.
Namespaces
Group related processes into a namespace and manage them as a unit.
For example:
api
worker
scheduler
Namespace startup is atomic. If a startup operation fails, ProcBoss can roll back the processes started by that invocation without unnecessarily affecting processes that were already running.
Dependencies
Applications often depend on other services.
An API might depend on PostgreSQL.
A worker might depend on Redis.
ProcBoss supports dependency declarations so required dependencies can be resolved before a process starts.
Dependencies can also refer to external system services rather than only ProcBoss-managed applications.
Health Checks
A process being alive doesn't necessarily mean the application is healthy.
ProcBoss supports health checks so you can monitor whether an application is actually responding, not just whether its process still exists.
Logs and Metrics
ProcBoss provides automatic log capture, rotation, retention, compression, real-time log tailing, and Prometheus metrics.
So the same tool managing the process can also provide the operational information needed to understand it.
Installation
ProcBoss provides a universal installer for Linux, macOS, and Windows.
Linux and macOS
curl -fsSL https://procboss.com/install.sh | sh
Windows
powershell -c "irm https://procboss.com/install.ps1 | iex"
The installer lets you select whether ProcBoss should run under Bun, Node.js, or Deno.
You can also explicitly choose the runtime when needed:
pboss --runtime=bun ...
pboss --runtime=node ...
pboss --runtime=deno ...
The selected runtime can be persisted locally, and you can change it later with:
pboss runtime change
The important distinction is that runtime selection is about how ProcBoss itself executes. The processes it manages can still use their appropriate runtime.
That is what makes mixed-runtime servers possible.
Why This Matters
The JavaScript ecosystem no longer revolves around a single runtime.
That's a good thing.
Bun, Node.js, and Deno each bring different ideas and capabilities to the ecosystem.
Developers should be able to choose the runtime that makes sense for a particular project without having to rebuild their production tooling around that decision.
That's the problem ProcBoss is trying to solve.
You can have:
project A → Bun
project B → Node.js
project C → Deno
and still have:
ProcBoss
│
┌────────────┼────────────┐
│ │ │
Bun Node Deno
│ │ │
native native native
APIs APIs APIs
One process manager. Multiple runtimes. Native APIs.
And because clustering is runtime-aware as well, you don't need a separate scaling solution for each runtime.
What's Next?
ProcBoss started as a Bun process manager.
The project has now evolved into a runtime-agnostic process manager for modern JavaScript backends.
The goal isn't to make Bun, Node.js, and Deno behave identically.
It's to give them a consistent operational layer without taking away what makes each runtime different.
If you're running applications across multiple JavaScript runtimes, you can now manage them with one pboss.
Learn more
Have you been running different process-management tools for different JavaScript runtimes? I'd be interested to hear how you're handling mixed-runtime deployments.
Top comments (0)