ServerBee: a Rust agent and Axum server for self-hosted VPS monitoring

The problem ServerBee solves for people running a few VPS instances

If you rent five or twenty VPS instances from different providers, each provider gives you its own console with its own graphs and its own alerting. Assembling one view means either paying a hosted monitoring service per host or running Prometheus, a time-series database and Grafana yourself. ServerBee takes the second path but collapses it into two binaries: a server that holds state and a small agent that runs on each node. The README describes the target plainly: a central server receives metrics from lightweight agents over WebSocket, stores them in embedded SQLite, and serves a real-time React dashboard with no external database and no heavy runtime.

The audience is the operator who owns the machines. The feature list leans toward that person rather than toward a platform team: per-server traffic statistics with billing-cycle prediction, cost insights with a burn rate and a per-resource unit cost, firewall blocklist management through nftables, and a browser terminal. Those are chores of someone paying the bills, not of someone running a Kubernetes cluster. If your servers are cattle managed by an orchestrator with its own observability stack, the overlap is small.

Agent to Axum server over WebSocket, with SQLite underneath

The repository is a Rust workspace with three members: crates/common, crates/server and crates/agent. The server binary is built from crates/server and the agent from crates/agent, which is why the Dockerfile can build both with a single cargo build --release -p serverbee-server -p serverbee-agent call. A separate Bun stage builds the frontend first and copies apps/web/dist into the Rust build, so the web UI ends up inside the server binary rather than beside it.

The data path is push, not scrape. The agent collects on an interval and opens a WebSocket to the server; the topics list names axum and websocket, and the README points at two distinct routes: /api/ws/ for the dashboard and /api/agent/ws for agents. Metrics land in embedded SQLite, and the dashboard reads them back over the first route. Historical charts are offered over ranges from one hour to thirty days, which means retention is a real configuration decision rather than an afterthought; the README sends you to the documentation for retention settings instead of stating a default.

Enrollment is the part worth understanding before you deploy. You sign in as admin, choose Add Server, and the server generates an install command carrying a one-time enrollment code that is bound to that server and expires in about ten minutes. The agent generates and persists its run token before claiming the offer, then reconnects on its own. The code is used once. That design keeps a leaked install command from being replayed against a different node later.

Installing the server with Docker and enrolling your first agent

The README's quick start installs the server with a script and defaults to Docker, which it recommends for the server component. The script takes a component name and a --method flag, and the interactive path runs if you omit the flag.

curl -fsSL https://raw.githubusercontent.com/ZingerLittleBee/ServerBee/main/deploy/install.sh | sudo sh -s -- server --method docker

After it starts, open http://your-server:9527. The admin password is auto-generated and printed to the startup log, and the README says to change it on first login. The docker-compose.yml file in the repository does the same thing without the script, mapping port 9527, mounting a serverbee-data volume at /data, and setting SERVERBEE_SERVER__DATA_DIR=/data. Its healthcheck probes http://localhost:9527/healthz with wget --spider, so you can confirm the container is actually serving before you enroll anything.

If you prefer the compose file, the credentials banner appears once in the logs. Run docker compose logs serverbee-server to read it. Then enroll an agent. The README recommends a native binary for agents because it gives the smallest footprint and full host-level metrics, and you should copy the command from the Add Server dialog rather than typing one, since the enrollment code is single-use and expires in about ten minutes.

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 agent persists its run token before claiming the offer, so the code is needed only once and reconnects happen without it. Configuration on both sides can come from TOML files or from SERVERBEE_-prefixed environment variables, where a double underscore separates nested keys. The agent's report interval lives under the collector section:

# /etc/serverbee/agent.toml
server_url = "http://your-server:9527"
enrollment_code = ""   # one-time code from Add Server; only used for first claim

[collector]
interval = 3           # seconds between reports

The beta tag, the GPU caveat and the WebSocket proxy requirement

The most concrete limitation is the release channel. The newest release is v1.0.0-beta.1, published on 2026-08-10, and the README carries a note that the project is in active development and that rapid iteration is expected. The workspace version in Cargo.toml is 1.0.0-beta.1. If you need a version you can pin for a year without reading changelogs, this is not that project yet. The management CLI does have a --channel beta flag for upgrades, which implies a stable channel exists, but the current tag is a beta.

The second limitation is hardware coverage. GPU metrics come from a self-built agent compiled with --features gpu, and the README states that prebuilt binaries exclude GPU support. So the convenient install path and the GPU path are mutually exclusive: you either build the agent yourself or you skip GPU metrics. Anyone monitoring inference boxes should plan for a build step.

The third is deployment shape. Behind Nginx or Caddy you must 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 leaves you with a dashboard that loads and then never updates, and agents that cannot connect at all. That is a configuration failure you can avoid, but it is also a failure mode that looks like a broken product until you check the proxy.

Finally, the README does not document rollback. There is an upgrade command and a config command, but nothing about reverting to a previous version or restoring a database after a bad migration. Backup and restore are listed as features, so a path exists, but its behavior is not described in the README.

How ServerBee differs from Prometheus and from Netdata

The obvious comparison is Prometheus with node_exporter and Grafana. Prometheus pulls: it scrapes an HTTP endpoint on each target on a schedule, and the target does not need to know where the server is. ServerBee pushes: the agent opens a WebSocket to a server it was told about at enrollment. Pull survives a monitoring server restart more gracefully because the target keeps serving; push depends on the agent's reconnect logic, which the README says exists but does not describe in detail. In exchange, push works through NAT and firewalls without exposing a scrape port on every node, which is the common situation with cheap VPS instances.

The storage difference matters more over time. Prometheus writes to its own time-series format and expects to be sized and tuned for retention. ServerBee uses embedded SQLite in the server, which means one file to back up and no separate database to operate, but also a single writer and a ceiling you will meet earlier on a large fleet. The README claims the server stays lightweight as your fleet grows; it does not give a host count where that stops being true.

The closer comparison is Netdata, which also ships an agent that collects and displays locally. Netdata's model puts the dashboard on each node and optionally streams to a parent; ServerBee puts one dashboard on one server and treats nodes as sources. If you want per-node detail without central infrastructure, the agent-local model is simpler. If you want one login, one alert rule set and one place to run a terminal on any node, ServerBee's shape is the one you want.

Licence terms and what an upgrade actually costs you

ServerBee is licensed AGPL-3.0, and the workspace manifest states AGPL-3.0-or-later. For an operator running it on their own servers to watch their own machines, that is unremarkable. The obligation becomes interesting if you modify the server and expose it to users over a network, because the AGPL's network clause reaches services that the GPL's does not. This is a description of the licence family, not legal advice; if you plan to embed ServerBee in something you sell, read the LICENSE file and talk to someone qualified.

Upgrade cost is low in the mechanical sense and moderate in the operational sense. The installer places a serverbee CLI at /usr/local/bin/serverbee, and the README lists status, upgrade -y, upgrade --channel beta -y, restart, config and uninstall agent -y. So the command to move forward is one line. The cost is that you are moving through beta tags, and the README documents no downgrade path. A sensible habit is to copy the SQLite data directory before running an upgrade, since a single file is easy to snapshot and the README does not promise that migrations are reversible.

Maintenance status is worth stating precisely rather than characterizing. The repository is not archived, and the last push was on 2026-08-23. The project is in beta, and the features listed in the README include several that imply ongoing work: a native iOS companion app, OpenAPI documentation covering more than 180 endpoints, and an agent auto-update mechanism. An auto-update mechanism on agents is convenient and also means your fleet's behavior can change without you touching each node, so decide deliberately whether to leave it on.

Editorial conclusion

Adopt ServerBee if you run a handful of VPS instances you own and want metrics, alerts and remote management behind one login without renting a SaaS. Do not adopt it if you need a frozen API or a stable release channel, because the newest tag is v1.0.0-beta.1 and the README itself warns that rapid iteration is expected. Before you commit, read ENV.md and the configuration pages at docs.serverbee.app to confirm that retention, rate limiting and OAuth settings cover your case, and check whether your reverse proxy forwards the Upgrade and Connection headers for /api/ws/ and /api/agent/ws.

Frequently asked questions

Official sources

1. License: AGPL-3.0
2. Project website
3. README
4. Releases
5. ZingerLittleBee/ServerBee on GitHub