Introduction

ProcBoss comes in two parts that work independently and together:

• pboss — a runtime-agnostic process manager for Bun, Node.js, and Deno. It runs on whichever runtime your machine already has, through that runtime’s own native APIs — no compatibility layers, no lowest-common-denominator mode, no forced dependencies. Open source (GPLv3), by procboss.com.
• ProcBoss Cloud (procboss.com) — the optional hosted layer: link the servers you already run, get fleet visibility, alerts, and metrics from one dashboard.

Runtime-agnostic, not runtime-generic#

One published package, three runtimes. npm install -g pboss, bun add -g pboss, or deno install -g -A --min-dep-age=0 --name pboss --reload --force npm:pboss/deno-entry all deliver the same CLI — and the runtime that executes it is your selection:

• No runtime is forced on you. Any one of Bun, Node.js, or Deno is enough. You pick it once — at install time or on first run — and the choice is saved in ~/.pboss/.runtime; the pboss wrapper reads it back every run and dispatches to that runtime’s own entrypoint. pboss runtime change switches it any time.
• Native performance and features, per runtime. Under Bun, pboss supervises with Bun.spawn, serves the dashboard with Bun.serve, reads files with Bun.file. Under Node, it is node:child_process, node:http, and node:fs/promises. Under Deno, Deno.Command, Deno.serve, and the Deno.* file APIs. Nothing is routed through another runtime’s compatibility layer.
• Selected by you, reported honestly. pboss runtime tells you the configured selection and the engine actually executing on demand.
• Same features everywhere. Process lifecycle, cluster mode, logs, health checks, cron restarts, watch mode, the dashboard, and Prometheus metrics behave identically under all three runtimes.

See Runtimes for the full architecture — the adapter layer, the detection order, and the native API map.

Why pboss?#

pboss is a production-grade process supervisor that speaks each runtime’s native language. The daemon starts in under 50ms and idles around ~12MB of RAM on every supported runtime. It is one binary-shaped package — install once with any package manager, and it manages your JavaScript and TypeScript applications.

The managed side follows the same focus: JavaScript and TypeScript apps get first-class treatment — per-machine runner resolution (bun run → deno run -A → node, with TypeScript under Node powered by tsx).

Feature highlights#

• Runtime-agnostic core — executes under Bun, Node.js, or Deno, each through its native APIs (Runtimes).
• First-class JS/TS runtimes — managed JavaScript and TypeScript apps resolve their runner per machine: bun run → deno run -A → node, TypeScript under Node through tsx (Runtimes).
• Process management — start, stop, restart, reload, delete, scale; crash restart, restart strategies, memory-limit restarts, tree killing.
• Cluster mode — N instances, per-worker env, automatic ports, zero-downtime rolling reloads; spawned by your runtime’s native process API (Cluster mode).
• Foreground mode — --no-daemon blocks as PID 1, for Docker and Kubernetes.
• Web dashboard — live WebSocket updates, CPU/memory charts, process controls, log viewer. Zero dependencies.
• Prometheus metrics — dedicated /metrics endpoint, ready for Grafana.
• Logs — automatic capture, size-based rotation, retention, gzip, real-time tailing.
• Health checks — HTTP probes with interval, timeout, and failure threshold; unhealthy processes restart.
• Cron restarts — scheduled restarts with standard cron expressions.
• File watching — restart on changes, with configurable paths and ignore patterns.
• Ecosystem files — declare your whole topology in one JSON, JS, or TypeScript file.
• Persistence (default on) — process list saved after every change; boot service installed at install time — apps survive restarts and reboots.
• Remote deployment — SSH deploys with git pull, release directories, symlink rotation, pre/post hooks.
• Environment management — per-process env vars, with .env file support.
• Module system — plugins that hook into the process manager lifecycle.
• IPC architecture — the CLI talks to one machine-level daemon over WebSocket on a Unix socket.

pboss vs ProcBoss Cloud#

The CLI is the same tool in both cases. The cloud layer is purely additive: pboss cloud connect opens an outbound link that reports state and accepts remote commands — the CLI keeps working exactly as before, even if the machine goes offline or you unlink it.

Where to go next#

• New to pboss? Start with Installation, then the Quickstart.
• Which runtime will pboss use on your machine — and how does it stay native on each? Read Runtimes.
• Running processes in production? Read Foreground mode & Docker and Startup scripts.
• Curious how it works inside? Read Architecture.
• Want cookbook patterns? Browse Recipes.
• Want the fleet dashboard? Jump to ProcBoss Cloud.
• Looking for a specific command? Browse the CLI reference.