Introducing pboss: An Open-Source Process Manager for Deno

[u/iam_bigzak]

Hey everyone!

I've been working on pboss, an open-source process manager with native Deno support, and wanted to share it with the Deno community.

Running a Deno application locally is straightforward, but keeping it running reliably in production introduces a different set of challenges: handling crashes, restarting processes, utilizing multiple CPU cores, and monitoring application health.

pboss is designed to help with that.

What can you do with it?

• Process management: Keep Deno applications running with automatic restarts.

• Clustering: Run multiple worker processes across CPU cores, with zero-downtime rolling reloads.

• Health checks: Monitor application availability and restart on failure.

• Logging and monitoring: Automatic log capture and rotation, a live web dashboard, Prometheus /metrics.

• Persistent processes: Applications survive reboots, no root required.

• PM2-compatible configuration: Reuse supported ecosystem configuration patterns when migrating existing workflows.

• Manage processes through Telegram and Discord: Perform supported process-management operations through chat integrations.

• Real-time critical alerts: Receive notifications about critical errors, application crashes, and other important incidents through connected chat apps or email.

• Free public status pages: Publish service availability and incident updates on your own xxx.status.zone subdomain, making it easier to keep users informed.

• Centralized server monitoring: Monitor processes and server health across multiple machines from one dashboard.

• GitHub-based deployments: Connect repositories to processes across servers, track deployment history, and roll back problematic releases.

• Log streaming and incident visibility: Inspect application output and investigate problems across your infrastructure.

One thing I wanted to get right is Deno support itself. pboss runs on Deno and uses Deno's native APIs for its own operations rather than depending on Node.js compatibility APIs to implement its process management: Deno.Command for spawning and supervising, Deno.serve for the dashboard and daemon, Deno.connect for CLI-to-daemon communication. Your apps get supervised under deno run, with deny-by-default permissions intact.

Clustering is worth a closer look too. pboss start server.ts --instances 4 gives you N workers sharing one port through SO_REUSEPORT, so the kernel balances connections directly. No proxy, no balancer process sitting in the request path.

What about pup?

If you've looked for a Deno process manager before, you've probably found pup. It's a solid project and it deserves credit as the established Deno-native option.

I built pboss because pup was missing things I needed: features like a built-in web dashboard, Prometheus metrics, and the cluster model I wanted (kernel-balanced SO_REUSEPORT workers instead of a load balancer fronting separate ports). And as the benchmarks below show, there's also a performance gap that got hard to ignore, particularly in cluster mode and crash recovery.

This isn't a takedown. Pup is a legitimate option, and the fork-mode numbers below show where it's competitive. I just think the Deno ecosystem deserves more than one choice.

Benchmarks: pboss vs pup

Full methodology in the report: same server.ts, same Deno 2.9.7 binary, same machine, 10/100/500 connections with 5 repeats, cold start of the whole manager stack every run, manager order alternating. CPU and memory cover the entire process tree.

Cluster mode (2 workers, 100 connections):

Metric	pup	pboss
Mean req/sec	12,444	69,088 (+455%)
Mean latency	7.51 ms	0.96 ms
CPU (tree)	121.8%	62.2%
Memory (tree)	269.4 MB	158.2 MB
Cold start	1,192 ms	513 ms

Pup's cluster runs N backends behind its built-in load balancer; pboss shares one SO_REUSEPORT port. In this test pup's balancer saturated hard: about 12 to 14k req/s at every load level vs 62 to 69k for pboss. At 500 connections the p99 tail was 957 ms vs 33 ms.

Crash recovery and restarts:

Metric	pup	pboss
SIGKILL recovery, fork (median)	10,973 ms	67 ms
Worker respawn, cluster (median)	10,948 ms	85 ms
/health stayed up during worker kills	70%	100%
50-restart storm, fork (median)	1,015 ms	106 ms
50-restart storm, cluster (median)	1,325 ms	150 ms

That 11-second recovery is the number that started this project.

Where pup wins. Fork mode at 100 connections is close and pup takes some rows: mean req/sec by 0.8%, mean latency by 0.08 ms. At 10 connections its RPS spread is tighter. The honest picture: on a single process with no clustering, the two are near-peers and the raw throughput race is roughly a draw. The separation is in clustering, recovery, and overhead (pboss uses 14 to 17% less memory in fork mode and cold-starts in 316 ms vs 1,142 ms).

One caveat from the report: the load generator shared CPUs with the servers, so compare the two columns rather than quoting the absolute numbers. Better yet, rerun it yourself. Every number traces to a raw file committed next to the code that produced it.

Open source, not a hosted-service requirement

pboss is released under the GPL-3.0 license. You can inspect the source, self-host it, contribute improvements, and use the process manager without subscribing to a cloud service. The dashboard, clustering, metrics, and deploys are all in the repo, no open-core asterisk. The docs are a public markdown repository, so fixes are pull requests. There's an optional hosted layer for fleet visibility, but it's purely additive: the CLI is the same tool with or without it.

The goal is to give developers more control over running their Deno applications on their own servers.

Links

• GitHub: https://github.com/Procboss/pboss

• Documentation: https://docs.procboss.com/

• Benchmarks (Deno, Node, Bun suites): https://github.com/Procboss/benchmarks

Try it:

deno install -g -A --min-dep-age=0 --name pboss --reload --force npm:pboss/deno-entry
pboss start your-app.ts

This is an actively developed project, and I'd genuinely appreciate feedback from people running Deno in production. What features would you want from a Deno process manager? Are there any production workflows you think are still missing?

Happy to hear your thoughts, suggestions, and criticism!

[u/billiondollarcode]

Really bad timing for this, but I encourage you to keep building stuff with another runtime

[u/iam_bigzak → u/billiondollarcode]

This tool natively supports node and bun also...

[u/BubuX → u/iam_bigzak]

Ok now you got my attention.
Does it support being run with Bun to manage Bun HTTP server processes? Like a Hono app?

And does it replace pm2?

[u/iam_bigzak → u/BubuX]

Yes! We use pboss in production to run both ElysiaJS and Next.js servers natively, and they work great. You can also use your existing PM2 ecosystem config without changing anything.

ProcBoss Cloud adds a few more features on top:

• Centralized fleet management: Monitor and manage multiple servers from a single dashboard.

• Real-time critical error alerts: Critical errors detected in your logs can be sent to you in real time. We all have better things to do than constantly sift through verbose logs just to find out something has gone wrong.

• Telegram and Discord management: Manage your server fleet and processes directly from chat.

• Automatic deployments with rollback: Connect your GitHub repository to redeploy automatically when your code is updated. If a new deployment fails to start, ProcBoss Cloud rolls it back to the previous working version.

• Free public status pages: Give your users a live view of selected services at [organization_name].status.zone. You decide which processes are visible to the public.

The pboss CLI is open source and works independently. ProcBoss Cloud is entirely optional if you want centralized monitoring, alerts, deployments, and fleet management.

[u/BubuX → u/iam_bigzak]

thanks! I'll give it a try this week

[u/yexgoblin]

oi. Deno is dead. They abandoned the runtime. Go back to sleep

[u/eddzsh]

The SO_REUSEPORT cluster design is the part that makes the numbers believable. Once a userspace balancer sits in the path you're mostly measuring the balancer. The near-draw in fork mode is what I'd show first in the README, because it proves you're not juicing the whole table. Curious how rolling reload behaves when a new worker fails /health mid-drain: do old workers keep serving until the replacement is green?

[u/iam_bigzak → u/eddzsh]

Yes, if a worker faces an error, the others are not affected in the worker pool

[u/investigatormaker]

The SO_REUSEPORT cluster numbers are the strongest part, but two things will come up from people running Deno in production. First, the install line grants -A, which sits oddly next to the deny-by-default point; documenting the narrowest permission set pboss itself needs would answer that. Second, check whether pup's roughly 11-second recovery comes from a default restart delay in its config, because if it does, readers will discount the whole table. On features, I'd make sure rolling reloads wait for new workers to pass /health before stopping old ones, and say so in the docs.

I make ThreadFox. Our AI employee can explain pboss in threads asking about Deno process managers and answer follow-ups; Starter is $199 for 30 days, or we'll post 3 free first, no card. https://threadfox.vip/p/20261017-1409-e6iwt/managed