ServerBee: A Rust Agent and Axum Server for Self-Hosted VPS Monitoring
Lightweight VPS monitoring with agent + server + web dashboard. Rust + React monorepo.
At a glance
- What is it?
- ServerBee pairs a small Rust agent with an Axum server, embedded SQLite, and a React dashboard to collect VPS metrics over WebSocket. It is a beta-stage project with an unusually broad feature surface, and the licensing and maturity caveats matter as much as the feature list.
- Who is it for?
- Adopt ServerBee if you run a handful of VPS instances, want the agent and server under your own control, and are comfortable running pre-1.0 software from a single maintainer. Do not adopt it if you need a stable API contract, long-term support, or permissive licensing for a closed product.
- Can I use it commercially?
- Yes, with strict conditions. AGPL-3.0 is a network copyleft licence: if people use a modified version over a network, for example as a hosted service, you must offer them its source code under the same licence.
- Is it still maintained?
- Yes. The repository last received commits 23 days ago.
- What is it written in?
- Mainly Rust, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem ServerBee targets: many small VPS instances, no central view
The project is aimed at people who rent several VPS instances from different providers and want one dashboard instead of one per host. The README frames it as watching all your servers from one place, with a central server receiving metrics from lightweight agents. That is a narrower audience than general infrastructure monitoring. It is not a Kubernetes observability tool and the material shows no service-discovery integration, so hosts are added by hand through an Add Server flow. The feature list suggests the intended user is an individual or small team running a mixed fleet: monitoring, alerts, ping and network-quality probes, a web terminal, a file manager, firewall blocklists, Docker container stats, and status pages are all in scope. If you already run Prometheus with node_exporter, ServerBee overlaps heavily with that setup but makes different trade-offs around storage and configuration, which are covered below.
Agent, server, SQLite, WebSocket: the data path
The architecture is three parts. An agent runs on each monitored host and collects CPU, memory, disk, network, load, temperature and disk I/O metrics. A central server receives those metrics over WebSocket, stores them in embedded SQLite, and serves a React dashboard that updates in real time over a WebSocket connection. The server binary embeds the web UI, so there is no separate frontend deployment. Collection cadence is set on the agent side: the README shows a collector interval of 3 seconds in agent.toml, described as seconds between reports. That interval drives both bandwidth and SQLite write volume, so the retention and rate-limiting settings referenced in the configuration documentation are worth reading before pointing an agent at a busy host. Historical charts are offered over 1h to 30d ranges, which implies the server downsamples or prunes older rows, though the README does not describe the retention mechanism itself. The server also exposes 180+ endpoints behind OpenAPI/Swagger docs, and those routes are what the React dashboard and the iOS companion app consume.
Installing the server and enrolling an agent
The server install is a one-line script with a method flag: curl -fsSL https://raw.githubusercontent.com/ZingerLittleBee/ServerBee/main/deploy/install.sh | sudo sh -s -- server --method docker. Docker is the README's recommendation for the server; --method binary is the alternative, and omitting the flag prompts interactively. The dashboard then listens on port 9527, and the admin password is auto-generated and printed to the startup log, which the README says to change on first login. Agent enrollment is deliberately stateful. You sign in as admin, choose Add Server, and copy the generated command, which carries a one-time enrollment code bound to that server and expiring in roughly ten minutes. The agent command looks like: curl -fsSL https://raw.githubusercontent.com/ZingerLittleBee/ServerBee/main/deploy/install.sh | sudo sh -s -- agent --method binary --server-url http://YOUR_SERVER:9527 --enrollment-code YOUR_ONE_TIME_CODE. The README recommends the native binary for agents because it has the smallest footprint and access to full host-level metrics; --method docker runs the agent in a container instead. Configuration lives in TOML files such as /etc/serverbee/server.toml and /etc/serverbee/agent.toml, or in environment variables prefixed with SERVERBEE_, where a double underscore separates nested keys (SERVERBEE_AUTH__MAX_SERVERS is the given example). The server config keys shown are listen, data_dir, and an admin password that can be left empty to auto-generate.
The agent token flow, and why the enrollment code is not reusable
The README is explicit that the agent generates and persists its run token before claiming the enrollment offer, then reconnects automatically afterwards, and that the code is only needed once. That ordering is the part worth understanding: the agent writes its own credential to disk first, so a failed or interrupted claim does not leave the agent without a token. The enrollment offer is single-use and server-bound. The practical consequence is that a code cannot be shared across a batch of hosts, and a code left in a shell history or a CI log is a live credential for its roughly ten-minute window. It also means provisioning many machines is a loop of generate-and-run rather than one script fanned out to the fleet. The README does not describe an API for generating enrollment codes programmatically, so if you manage dozens of hosts, that step is the one to check against the OpenAPI docs before committing.
Where the design gets uncomfortable: beta status, single maintainer, AGPL
Two facts sit above every feature in the list. The project is at v1.0.0-beta.1 by the release history, and the README's own note says ServerBee is in active development and to expect rapid iteration. The release cadence shown is roughly monthly since July 2026, with pre-release tags throughout. Anything you build against the 180+ documented endpoints is exposed to that churn. The second is scope. Alerts, notifications, a web terminal, a sandboxed file manager with Monaco, nftables blocklists, Docker stats, GeoIP, cost insights, and an iOS app are all maintained in one repository, which is a lot of surface for a project still in beta. The material does not name maintainers or a governance model, so treat the feature breadth as something to verify rather than assume. Licensing is AGPL-3.0. For internal self-hosted monitoring that is usually unproblematic, but if you intend to offer ServerBee as part of a hosted service, or to modify and distribute it, the copyleft obligations are the thing to review with someone qualified rather than infer from the badge. On footprint, the README cites about 4.3 MB at cold start and about 27 MB in steady state for agents. Those are the project's own figures and this article has not reproduced them.
ServerBee versus Prometheus and node_exporter
The closest comparison in this space is Prometheus scraping node_exporter endpoints. The difference is architectural, not cosmetic. Prometheus pulls over HTTP on a scrape interval and writes to its own time-series database, with alerting handled by a separate component and rules expressed in PromQL. ServerBee pushes: the agent opens a WebSocket to the server, and the server writes into embedded SQLite. That removes two moving parts (no external TSDB, no separate alerting service) and gives you a dashboard, alerts, and a web terminal from one binary. It also changes the failure model. With Prometheus, a scrape failure is visible as a gap and the target keeps serving metrics to whoever asks. With a persistent WebSocket, the agent must stay connected, and the README's note that agents reconnect automatically after enrollment implies disconnection is an expected state. What you give up is the ecosystem: PromQL, long-term storage backends, and the breadth of exporters. If your questions are ad hoc queries across months of data, SQLite behind a fixed set of 1h to 30d chart ranges is the wrong shape. If your questions are which box is hot right now, ServerBee's model is simpler to stand up.
Upgrades, the management CLI, and reverse proxy requirements
The installer places a serverbee CLI at /usr/local/bin/serverbee. The documented subcommands are status, upgrade with -y, upgrade with --channel beta, restart, config, and uninstall agent -y. Upgrades are therefore a single command per host, and the beta channel is selectable, which fits a project whose releases are currently all pre-release. The cost that does not appear in the README is the migration path for embedded SQLite as the schema evolves during beta; the material does not describe a migration or rollback procedure, so back up data_dir before upgrading. The README does list backup and restore as a feature, which is the mechanism to look for. Deployment behind Nginx or Caddy has a specific requirement: proxy / to 127.0.0.1:9527, and make sure the WebSocket routes /api/ws/ and /api/agent/ws forward the Upgrade and Connection headers with a long read timeout. A proxy that strips those headers or times out idle connections will break the real-time dashboard and agent connections in ways that look like a ServerBee bug. The README points to a ready-to-use Nginx config in the deployment documentation rather than reproducing one.
Editorial conclusion
Adopt ServerBee if you run a handful of VPS instances, want the agent and server under your own control, and are comfortable running pre-1.0 software from a single maintainer. Do not adopt it if you need a stable API contract, long-term support, or permissive licensing for a closed product. Before installing, verify three things: that the enrollment code is still valid (the README says it expires in about ten minutes), that your reverse proxy forwards Upgrade and Connection headers for /api/ws/ and /api/agent/ws, and whether you need GPU metrics, because prebuilt binaries exclude them and you would have to build the agent with --features gpu.
Community notes