ProcBoss: The Runtime-Agnostic Process Manager for Javascript Backends
Run, deploy, monitor, and manage JavaScript backends across Node.js, Bun, and Deno.
Running a JavaScript or TypeScript application in production is rarely just about starting the application.
You need something to keep it alive, restart it when it crashes, manage multiple instances, monitor its health, handle logs, schedule tasks, and deploy new versions without turning every server into a collection of shell scripts.
There are plenty of tools that solve parts of this problem.
ProcBoss started with a much smaller goal: build a process manager that I actually wanted to use.
It has grown considerably since then.
ProcBoss is a runtime-agnostic process manager built for running and managing production JavaScript and TypeScript applications across servers.
It supports Bun, Node.js, and Deno natively, while also being capable of managing applications written in other languages and runtimes.
From a Bun process manager to runtime-agnostic
ProcBoss originally started as a Bun process manager.
The initial idea was straightforward: use Bun's native APIs to build a lightweight way to run production applications.
But as the project grew, one limitation became increasingly obvious.
A process manager shouldn't force a JavaScript runtime onto the applications it manages.
If a server runs Node.js, ProcBoss should be able to use Node's APIs.
If it runs Bun, it should use Bun's APIs.
If it runs Deno, it should use Deno's APIs.
That led to a major architectural change.
ProcBoss became runtime-agnostic without trying to hide the differences between runtimes behind a single compatibility layer.
The same published ProcBoss package can run on Bun, Node.js, or Deno, using the native APIs of the runtime it is running under.
For example:
| Capability | Bun | Node.js | Deno |
|---|---|---|---|
| Process spawning | Bun.spawn |
node:child_process |
Deno.Command |
| Filesystem | Bun.file |
node:fs/promises |
Deno filesystem APIs |
| HTTP server | Bun.serve |
node:http |
Deno.serve |
| WebSockets | Native | ws |
Native |
The core process manager doesn't need to know which runtime provides those APIs.
Instead, runtime adapters provide the capabilities ProcBoss needs.
This means runtime-specific behavior stays runtime-specific while the process-management layer remains consistent.
Install ProcBoss
Installation is designed to be straightforward.
ProcBoss provides a universal installer for Linux, macOS, and Windows.
The installer checks the available environment, lets you choose whether ProcBoss should run under Node.js, Bun, or Deno, and handles the installation for you.
Linux and macOS
curl -fsSL https://procboss.com/install.sh | sh
Windows
powershell -c "irm https://procboss.com/install.ps1 | iex"
You can also explicitly specify the runtime during installation when needed.
The selected runtime is persisted locally, so ProcBoss doesn't need to make the decision again every time it starts.
You can change the runtime later with:
pboss runtime change
This is intentional.
A machine might have Node.js, Bun, and Deno installed simultaneously. ProcBoss doesn't need to guess which one you meant to use.
For the complete installation options, see the ProcBoss installation documentation.
Running JavaScript and TypeScript applications
JavaScript and TypeScript are where ProcBoss is primarily focused.
A process configuration can point directly to your application:
{
"name": "api",
"script": "server.ts"
}
ProcBoss handles the runtime needed to execute the application.
Bun, Deno, and Node.js are supported as native execution paths, and you can explicitly specify an interpreter when you need complete control.
This makes it possible to use the same process-management tooling across different JavaScript runtimes.
You might have one application running under Bun and another under Node.js on the same server.
ProcBoss doesn't need to force them onto the same runtime.
Process management
At the core, ProcBoss does what a process manager should do.
You can:
Start applications
Stop applications
Restart applications
Reload applications
Delete applications
Run multiple instances
Automatically restart crashed processes
Apply memory limits
Persist process configurations across reboots
ProcBoss also provides a local dashboard with live process information, resource usage, controls, and logs.
The objective is simple:
keep your applications running and make it easy to understand what they're doing.
Native clustering
Production applications often need multiple instances.
ProcBoss provides native cluster support for supported JavaScript runtimes, allowing you to run multiple workers of the same application.
Workers can have their own environment configuration, and ProcBoss can handle port allocation and process lifecycle management.
Rolling reloads allow workers to be replaced without taking the entire application offline.
The important part is that clustering uses the native process APIs of the runtime ProcBoss is running under.
A Node.js installation uses Node's process APIs.
A Bun installation uses Bun's process APIs.
A Deno installation uses Deno's process APIs.
There isn't another JavaScript runtime sitting underneath them just to make clustering work.
Namespaces
As applications become more complex, managing individual processes independently becomes cumbersome.
A typical production application might contain:
API
├── Web
├── Worker
└── Scheduler
ProcBoss namespaces provide a logical boundary around related processes.
Starting a namespace is atomic.
If something fails during startup, ProcBoss rolls back the processes started by that particular invocation.
Already-running processes are preserved.
This distinction matters when you're operating production systems: a failed deployment or startup shouldn't randomly take down unrelated processes.
Namespaces can also be used with dependencies.
Process dependencies
Applications rarely exist in isolation.
Your API might depend on PostgreSQL.
A worker might depend on Redis.
Another service might depend on the API being available first.
ProcBoss supports dependencies such as:
{
"name": "api",
"script": "server.ts",
"dependsOn": ["postgres"]
}
Dependencies are resolved recursively and can span namespaces.
ProcBoss first checks whether the dependency is another ProcBoss-managed process.
If it isn't, it can check the system service manager for an external service.
That means an application can depend on something like PostgreSQL without requiring ProcBoss to take ownership of PostgreSQL itself.
The default behavior is intentionally conservative: external services are inspected, not automatically started or stopped by ProcBoss.
Health checks
A process being alive doesn't necessarily mean the application is healthy.
An API can still have a running process while its HTTP endpoint is broken.
ProcBoss supports HTTP health checks so applications can be monitored based on whether they're actually responding.
Health checks can be combined with restart policies to automatically recover applications that become unhealthy.
This moves process supervision beyond:
Is the process running?
toward:
Is the application actually working?
Logs and metrics
ProcBoss automatically captures application logs and provides:
Log rotation
Retention policies
Gzip compression
Real-time log tailing
CPU and memory monitoring
Prometheus metrics
The Prometheus endpoint makes it possible to integrate ProcBoss with existing monitoring systems and dashboards.
The local dashboard provides the immediate operational view, while Prometheus gives you the flexibility to plug ProcBoss into the monitoring stack you already use.
Cron jobs
Production applications often need scheduled tasks.
ProcBoss includes cron functionality for both scheduled process operations and standalone jobs.
For example:
pboss cron run everyday@9:11 "bun /srv/backup.ts"
Or:
pboss cron run every-sunday@10:10 "sh /srv/cleanup.sh" --name cleanup
You can also schedule process restarts using cron expressions.
The idea is to keep common operational tasks close to the applications they're managing instead of requiring another tool for every small job.
Deployments
Keeping a process alive is only half of production management.
You also need to get new versions onto the server safely.
ProcBoss includes SSH-based deployment functionality with Git-based releases.
A deployment can:
Pull a configured Git reference.
Create a timestamped release directory.
Run deployment hooks.
Update the
currentsymlink.Start or reload the application.
Clean up older releases.
Multiple hosts can be included in the same deployment configuration.
This gives JavaScript and TypeScript applications a straightforward deployment workflow without requiring them to be packaged into containers.
Docker and Kubernetes
ProcBoss doesn't require Docker.
If you're running applications directly on a VPS, ProcBoss can manage them without adding a container layer.
But if containers are part of your infrastructure, ProcBoss can also run in foreground mode:
pboss --noDaemon
This allows ProcBoss to run without its background daemon and makes it suitable for container environments where ProcBoss can act as the main process.
Beyond JavaScript and TypeScript
Although JavaScript and TypeScript are the primary focus, ProcBoss isn't restricted to them.
It can manage applications and processes written in:
Go
Python
Rust
Ruby
PHP
Java
Shell
Native binaries
Other executable workloads
The process manager doesn't need to understand the language of the application.
If the operating system can execute it, ProcBoss can generally manage it.
The runtime-agnostic architecture is particularly important for JavaScript and TypeScript because Bun, Node.js, and Deno have different native APIs.
For other languages, ProcBoss simply manages the underlying executable process.
ProcBoss Cloud
The open-source pboss CLI is designed to work independently.
ProcBoss Cloud is an optional hosted layer for managing multiple servers.
Instead of connecting to every server individually, you can link your machines to ProcBoss Cloud and get a centralized view of your infrastructure.
A server establishes an outbound connection to the Cloud service.
You don't need to expose an inbound management port or give the Cloud service SSH access to your server.
Once linked, you can see your fleet from one place:
Servers
Processes
CPU and memory usage
Logs
Alerts
Deployments
Process state
You can also perform remote process operations from the dashboard.
The CLI continues to work locally even without Cloud.
That separation is important:
pboss is the open-source process manager. ProcBoss Cloud is the optional hosted management layer.
Monitoring and alerts
Managing one application is relatively easy.
Managing dozens of applications across several servers is different.
ProcBoss Cloud adds centralized monitoring and alerts for conditions such as:
CPU spikes
Sustained CPU usage
High memory usage
Memory growth
Restart loops
Event-loop latency
File-descriptor and handle growth
Server CPU pressure
Server memory pressure
Alerts use hysteresis so that temporary fluctuations around a threshold don't constantly trigger and clear notifications.
Hosted status pages
ProcBoss Cloud also provides hosted status pages.
Organizations get a status page at:
<organization>.status.zone
Custom domains can be connected through DNS verification.
This gives applications a public place to communicate service availability without requiring another third-party status-page service.
Why runtime-agnostic matters
There are already many process managers.
The interesting problem isn't simply creating another command that runs:
start
stop
restart
The real problem is doing that well across modern JavaScript runtimes.
Node.js, Bun, and Deno have different APIs and different approaches to process management, filesystems, HTTP servers, and networking.
ProcBoss doesn't try to pretend those differences don't exist.
Instead, it isolates them behind runtime adapters.
That gives the application-management layer a consistent interface while allowing each runtime to use its own native capabilities.
The result is a process manager that can follow the runtime rather than forcing the runtime to follow the process manager.
Where ProcBoss is going
ProcBoss started as a Bun process manager.
Today, it is a runtime-agnostic process manager focused primarily on production JavaScript and TypeScript applications.
The direction from here is to keep building the operational layer around those applications:
processes → dependencies → health → deployments → monitoring → infrastructure
The goal isn't to replace every infrastructure tool.
It's to make the common production workflow simpler without requiring developers to give up control of their own servers.
You can run your applications on your own VPS.
You can use Node.js, Bun, or Deno.
You can run without containers.
You can use the open-source CLI without ProcBoss Cloud.
And when you need centralized management across servers, Cloud is there as an additional layer.
That's what ProcBoss is becoming: a runtime-agnostic way to run and operate production JavaScript and TypeScript applications without adding unnecessary infrastructure around them.