ProcBoss Cloud is the dashboard layer for pboss — the open-source, Bun-native process manager you already trust. Watch your whole fleet, deploy on push, and get pinged before your users notice. Not after.
servers · 4
fleet cpu
processes · 6 online · 1 recovering
cpu / mem
uptime
12d 4h
12d 2h
31d 9h
0d 0h
$
Built on the open core
pboss — the open-source CLI that powers ProcBoss — is a zero-dependency, Bun-native process manager. You self-host it, you run pboss locally, and you get a dashboard for free. Table stakes, no card required:
GPL-3.0, forever
$
50ms
daemon cold start
12MB
memory overhead
0
runtime dependencies
100%
Bun-native TypeScript
pboss daemon vs. PM2 — same box, same load, fewer excuses.
“All of that, for free, forever, self-hosted. ProcBoss Cloud is for when you need to stop tailing logs by hand — and stop finding out about outages from your users.”
The unpaid part of the job
pboss handles the staying-up part beautifully. The operational drudgery around it — the hopping, the grepping, the finding-out-late — is what ProcBoss takes off your plate.
Five tabs. Three servers. One guess. Checking what's running means hopping between machines, running the same command everywhere, and hoping the green dots are still green. That's not observability — that's cardio.
$ ssh root@do-2 && pboss list # tab 2 of 5
pboss keeps it running — ProcBoss helps you understand why it broke. The crash-restart works fine; the part where you learn why it crashed is the missing piece. Until it exists, every incident starts with tailing 400MB of logs.
$ pboss list # alive. but why did it die?
Restart a process from Telegram or Discord — no SSH session, no dashboard, no laptop. Your phone becomes the incident room: alerts land where you already are, and the fix is one message away.
you, from your phone: /restart api
The command center
Monitoring, alerting, deploying, and the public status page — usually four side projects duct-taped together over a weekend. Here they ship as one product that already talks to itself.
Every server, every process, live CPU and memory — one screen instead of five SSH tabs.
live · every second
Crashes arrive explained: clustered traces, the correlated deploy, the memory trend.
ECONNRESET :5432
first crash 14m after deploy a3f8c21
Push to main. Build, health-check, zero-downtime swap — the pipeline is ours to break, not yours.
release #214 serving · prev kept warm
A public status page your users can read at 3am without waking you up. Free forever.
all systems operational
/status/your-slug · public
What the cloud layer adds
Now let ProcBoss watch your fleet, ping you before things break, and deploy for you. Five things the CLI can't do from one server — plus a chat control room that fits in your pocket:
01 · Deploy
Connect your GitHub repo and every push to your deploy branch builds, health-checks, and reloads with zero downtime. No manual pboss deploy, no deploy scripts rotting in package.json.
Zero-downtime by default
New processes boot, pass health checks, then traffic swaps over. The old release never goes down first.
Failed checks never ship
If the new build doesn't come up healthy, the previous release keeps serving. Automatically.
Deploy from anywhere
Dashboard, CLI, or a chat message — same pipeline, same audit trail, same zero downtime.
alternative to
⇅push to main detected · a3f8c21 · 14:02:11
$git pull --ff-only
←ok 3 files changed, 41 insertions
$bun install --frozen-lockfile
←ok 214 packages · 1.9s
$bun run build
←ok build complete · 14.2s
✓health check 200 OK · new pid 5290
✓zero-downtime reload · 0 requests dropped
deploy #214 · 21.4s total · rollback available
$
failed health check = old release keeps serving. automatically.
02 · Fleet
The fleet dashboard shows every box, every region, every process with live CPU, memory, restarts, and uptime. Retire the tab-hopping ritual — you already know which dots should be green.
Live metrics per process
CPU, memory, restart count, and uptime — streamed from every server, grouped however your brain works.
One-line onboarding
A single install script registers a new server into the fleet in under a minute. No agents to babysit.
Region & host grouping
fra1, nyc3, sgp1 — see which processes run where, and which box is the one that's always warm.
alternative to
cpu 18%
mem 3.1 / 8 GB
procs 6
cpu 9%
mem 1.8 / 8 GB
procs 4
cpu 14%
mem 2.4 / 4 GB
procs 5
cpu 38%
mem 3.6 / 4 GB
procs 2
do-2 · queue-consumer recovering — crash report ready → view
03 · Alerts
Logs are streamed live from your servers and analyzed as they flow — never stored on our side. ProcBoss clusters the noise and flags what actually matters, pushed to email, Telegram or Discord while it's still a small problem, not an outage postmortem.
Streamed, never stored
Log lines flow through ProcBoss to your dashboard and chat channels in real time. Nothing is written to disk on our side — your logs live on your machines.
Error clustering
3,912 identical stack traces become one issue with a count and a trend — not 3,912 lines you grep through.
Email, Telegram & Discord built in
No alert-stack side project required. Add Slack or PagerDuty when your team grows into it.
alternative to
3,912 errorscollapsed into1 issue— identical stack, 6-minute window
AI summary — flagged 14:32, before you noticed
severity: highECONNREFUSED on db-pool — started 14:32, six minutes after deploy a3f8c21. Rate 4/min and climbing. Likely: connection pool exhausted after schema migration, not a network issue.
04 · Crash analysis
When a process dies, ProcBoss doesn't only restart it — it reconstructs what happened: clustered stack traces, the correlated deploy, and the memory trend that led up to the crash.
Stack-trace clustering
23 identical crashes are one root cause, not 23 mysteries. Patterns surface themselves.
Deploy correlation
“First crash 14 minutes after deploy a3f8c21” — the timeline you'd otherwise rebuild by hand.
Memory trend replay
Watch RSS climb for six hours before the kill. Leaks stop being heisenbugs and start being charts.
alternative to
process died 03:12:04 · restarted in 1.8s · exit code 1
most likely root cause
Memory leak — RSS 412MB → 1.2GB over 6h. GC pauses grew until the worker timed out and exited mid-task.
stack cluster
23 identical traces TypeError: Cannot read properties of undefined ('id') at Worker.process (worker.ts:412)
memory trend · 6h before crash
412MB → 1.2GB · +184%
correlated event: deploy a3f8c21 — first crash 14 min after rollout
05 · Scheduled jobs
pboss runs standalone scheduled commands beside your processes, and every job reports in: next run, last exit code, run count. A job that starts failing alerts you through the same channels as a crash — no more silent cron.
Full job lifecycle, visible
Schedule, next run, last exit code and run count for every job — streamed live from each server's agent.
Failures are first-class alerts
A cron job exiting non-zero fires a cron alert through Telegram, Discord or email — resolvable like any other incident.
Run now, pause, resume
Trigger a job out of schedule or pause it without touching crontab — from the dashboard or chat, with an audit trail.
alternative to
every day at 03:00 · next in 4h 12m
last exit 0 · 41s
every monday at 05:30 · next in 2d 7h
last exit 0 · 2s
every-30-seconds · next in 18s
last exit 1 · 0.4s
friday@18:00 · next —
last exit 0 · 12s
metrics-rollup failed 3× in a row → alert pushed to telegram · run now from the dashboard
06 · ChatOps — Telegram & Discord
Alerts land in the chat you already have open — and the fix is one message away. /restart from the beach. /rollback from dinner. Real commands, role-gated, fully audited. No SSH client on your phone, no dashboard tab juggling.
no app to install — the bot lives in the chat · iOS · Android · desktop
9:41
ProcBoss bot
online · fleet admin
⚡ queue-consumer on do-2 crashed — exit 1, 2nd crash in 1h. Crash report ready.
/rollback queue-consumer
✓ rolled back to release #213 · zero downtime · pid 5512 online
memory leak, RSS +184% over 6h — correlated with deploy a3f8c21.
/status
fleet: 4 servers · 16 processes online · 1 recovering · avg cpu 14%
/status · /restart · /logs · /scale · /rollback — same commands as the CLI
Pricing
Every account gets 14 days of the Growth plan. After that, monitoring stays free — your servers, alerts and public status page keep running.
Every paid feature, on one server.
billed yearly — save $12/yr
Your side project became a company.
billed yearly — save $36/yr
Serious fleets, serious cadence.
billed yearly — save $36/yr
Operations at the speed of your pager.
billed yearly — save $36/yr
Join the indie hackers, solo founders, and small teams who trust ProcBoss with their fleets.
“Got the crash report in Telegram with the deploy diff attached. Rolled back from bed. Went back to sleep. That used to be a 40-minute laptop-on-face incident.”
“Alerting bot, status page host, cron babysitter, deploy scripts — cancelled all four the week I moved in. One bill, and the status page is nicer than the one I was paying for.”
“Degradation hit at 2am; the status page flipped amber before support woke up. The first ticket of the morning was “saw the incident, thanks for the heads-up.””
“23 identical crashes became one issue with a memory chart and the guilty deploy hash. I've paid consultants more for worse postmortems.”
“I came for the pboss CLI and stayed for the cloud. Same commands, same philosophy — but I stopped SSH-ing into my Sunday evenings.”
“Two servers, one #ops channel, role-gated restarts. Our junior dev resolved his first incident without touching SSH — the audit trail shows it.”
Nothing breaks. Your monitoring keeps running for free — server health, alerts, cron outcomes and your public status page. Process control, log streaming and deployments lock until you upgrade, and everything unlocks again the moment you do.
No. Logs stream live from your servers to your dashboard, terminal, or chat channels — and are analyzed as they flow. Nothing is written to disk on our side. Your logs live on your machines, full stop.
One machine running the pboss daemon and linked to your ProcBoss account — a VPS, a bare-metal box, or the Raspberry Pi under your desk.
Nothing breaks — your existing servers keep reporting and pboss keeps every process alive. You just can't link new servers until you upgrade.
Yes. Stream live logs, get alerts, and run commands — /status, /restart, /rollback — from either app, with role gating and a full audit trail.
Yes — plans are month-to-month, cancel from the dashboard. Your servers keep running either way: pboss is open source and stays on every box.
open source · live numbers
pboss · GPL-3.0
final boarding call
Start free with one server — the CLI you already run, plus eyes on it from the outside. Add the automation when the 3am pages find you. They will.
2-minute setup · cancel anytime · your servers stay yours