Samsara-1999/Bursar

Bursar is worth a look if you run a small Linux GPU fleet on plain SSH and need per-user accounting and limits more than a full scheduler. Its main cost is operational: a controller, a database, and an agent on every compute host, with little public evidence yet of long-running deployments. See the repository README and architecture notes for the details.

The problem

A team shares a handful of GPU hosts over SSH. There is no central record of who used which GPU, how much CPU time was spent, or what should happen when a user exceeds an informal budget. Enforcing limits or checking suspicious processes means logging into each node by hand.

With Bursar, users keep their SSH workflow while a controller collects GPU, CPU, memory, disk, process, session and agent-health data from each node. Administrators define pricing in GPU model and CPU-core-minutes, points pools, carryover, overdraft policy and per-node overrides, then apply CPU, memory, disk and GPU-visibility policies. The result is a central account of shared resources and a policy layer that can act on remote processes, without a notebook gateway or a custom job scheduler.

What's different

Bursar deliberately does not replace SSH or act as a scheduler. It puts a Go controller in front of a PostgreSQL database and a Go agent on each compute node; the agent reads OS, GPU, cgroup and SSH state and applies actions received from the controller. That split is why it can report fleet-wide usage and enforce per-node limits while leaving users' existing login habits intact. The node-agent deployment guide describes the agent side.

On top of metrics, it adds billing-like bookkeeping: GPU and CPU-core-minute pricing, points pools, carryover and overdraft rules. For a lab or small company, that is a more natural way to arbitrate a shared cluster than migrating to Slurm or Kubernetes. The trade-off is that it is governance software, not scheduling software: it does not place jobs, reserve GPUs for a queue, or replace network segmentation, OS hardening, monitoring and tested backups, as the README itself states.

The README also describes optional encrypted synchronization to a standby controller and encrypted backups to an independent repository. Those are useful operational features, but they come with their own scripts and lifecycle assumptions, so they should be treated as part of the deployment plan rather than a checkbox.

Who should try it

Good fit: a research group or small company with existing Linux GPU hosts, SSH-based workflows and a need to account for shared GPU/CPU use, approve registrations, map platform accounts to node accounts, and enforce limits without adopting a full scheduler. Teams that want temporary users or delegated administrators will find identity management included.

Poor fit: users who want a job scheduler, Kubernetes operator or hosted control plane; anyone who needs published container images (the project does not publish them and both quick-start paths build from source); or teams without the appetite to run a controller, PostgreSQL and an agent on every node. macOS is listed as a controller host, but the node agent always runs directly on compute hosts and needs cgroup, systemd, SSH and GPU-driver access.

Requirements and limitations

Setup is not a single binary. The Docker path still requires Docker Compose and four distinct random secrets; the source path additionally needs Go 1.26.6, Node.js 20.20+, pnpm 10.28.2, OpenSSL and curl, and is the expected route for HA and backup scripts. The node agent cannot be containerized and must be installed on each compute host.

Ongoing upkeep is the bigger constraint: agents, database migrations, secrets, backups and any standby controller are all yours to operate. The README explicitly defines Bursar as governance for teams already operating Linux GPU hosts, not a substitute for hardening or backups. The supplied README excerpts do not document compatibility testing against specific GPU drivers or distributions, so check that against your fleet before committing.

HotRepo's take

Bursar was created on 2026-10-18 and reached 203 total stars, ranking #8 on HotRepo's NEW-REPOSITORY board on 2026-10-25. That is a snapshot, not a daily growth measurement, and HotRepo's comparable history is insufficient to judge persistence.

The concept is coherent, but the documentation should be checked for your exact GPU-driver and Linux distribution mix before deploying agents across a fleet.