pboss uses a daemonized architecture: the CLI communicates with a long-running daemon process over a Unix domain socket using the WebSocket protocol. Most commands need the daemon — and it’s started on demand if it isn’t running.
pboss ping#
Check if the daemon is running:
pboss pingUseful as a health check in scripts and for quickly verifying an install before anything else.
pboss kill#
Stop all processes and kill the daemon:
pboss killThis is the “everything off” switch: every managed process is stopped, then the daemon exits. Running any other pboss command afterwards starts a fresh daemon.
kill deliberately does not touch the saved process list — the dump keeps describing what should run, so a reboot (or systemctl start pboss) resurrects everything as it was. Use pboss delete <name> first if you want processes gone for good.
How the daemon fits together#
- On-demand startup — the first command that needs the daemon spawns it (under 50ms start, ~12MB RAM). A daemon that is already running is detected and used — commands never spawn a second daemon against the live socket.
- One daemon per machine — all CLI invocations, the dashboard, and the metrics endpoint talk to the same daemon over its Unix socket.
- Windows invisibility — the daemon runs with no console window, and everything it launches — apps, cluster workers, cron commands, git and deploy operations — is spawned hidden as well: a parent without a console would otherwise give each child its own visible terminal.
- Foreground exception —
--no-daemonskips all of this and supervises in-process; see Foreground mode. - Reboots — the boot service (installed automatically at install time;
pboss startup installwhen it could not be) starts the daemon at boot, and the auto-saved process list is resurrected; see Startup scripts.
Troubleshooting#
If commands hang or the socket seems stuck, check Troubleshooting — daemon won’t start for the diagnostic sequence (pboss ping, socket location, stale lockfiles).