Cloudflare replaces the monitoring server
At a 60-second reporting interval, CF-Server-Monitor sends each host's metrics to a Worker, writes history to D1, and pushes live changes through a Durable Object. The browser reads that same API for dashboard cards, detail charts, maps, and admin work. There is no monitoring VM to patch or database container to back up. For someone already comfortable with Cloudflare, that is the project's sharpest reason to exist.
The dashboard covers CPU, memory, swap, disk, disk IO, network use, load, process count, and uptime. Seven-day charts sit beside sampled longer-range data, monthly traffic, latency, and packet-loss views. Alerts cover offline hosts, recovery, expiry, and resource thresholds. The English README is complete rather than a short translation, and the interface can switch between Chinese and English.
One-way agents give up remote control on purpose
Since v2.8.3, the default collector has been the separate Go agent, though legacy shell and PowerShell agents remain available for cleanup. It reports outward and exposes no WebSSH, command delivery, or controller channel. That removes an entire class of admin features, but it also means compromising the dashboard does not automatically provide a terminal on every watched server.
The agent supports mainstream Linux distributions, OpenWrt, FreeBSD, macOS, Windows, Synology DSM, and Feiniu fnOS. Linux systems with systemd --user can run it without root, with files under ~/.cf-probe/. Docker is also documented for the agent. That distinction matters: the checkout contains no Dockerfile for the Worker dashboard, so the container route does not turn the whole system into a local one-command stack.
What happened when we ran it
Our sandbox installed commit dfb9bf1 in 15 seconds, pulling 102 packages and using 309 MB on disk. The build failed with exit code 1 in 4 seconds. Tests also returned exit code 1 after 7 seconds: Node's test runner counted 48 passing and 8 failing tests out of 56. Npm audit found 0 known vulnerabilities at the time of this run.
The 5.1 MB checkout held 425 files and about 40,659 source lines. It had 3 CI workflow files and a tests directory, but no Dockerfile. The build excerpt only shows an ESM loader stack ending at ModuleJob.run, then reports Node.js v18.20.8. The test excerpt shows cases 45 through 56 passing, not the 8 failures. Neither excerpt tells us why the commands failed, so assigning a cause would be guesswork.
Setup reaches Cloudflare and every watched host
Local development requires Node 18+, npm, and Wrangler 4. A hosted setup also needs a Cloudflare account, a GitHub account, a D1 database, and an API_SECRET. The recommended paths either connect a fork directly to Workers or deploy through GitHub Actions. The Actions route adds a Cloudflare API token, account ID, and D1 database ID to the repository's secrets.
After the Worker is live, you sign in at /admin#/admin, add each server, and run its generated install command. The initial admin password is the same API_SECRET used by agents, although the password can be separated later. Changing API_SECRET requires redeploying the Worker and updating every agent. That is manageable for 6 personal servers and irritating for 60, so settle the secret before enrolling the fleet.
The free tier is designed around roughly 60 servers
The project estimates roughly 60 servers at the default 60-second report interval. A 120-second interval can theoretically double that number, but the README does not present it as a capacity guarantee. Shorter intervals create more Worker requests and D1 writes. A buyer with hundreds of machines should price and load-test the actual Cloudflare account instead of treating the free tier as an unlimited monitoring backend.
Retention has similar limits. The main feature table promises 7-day history and sampled long-range views, while issue 108 asks about displaying a month or more. The repository also has cron jobs every 1 minute and every hour for alerts, rotation, cleanup, and expiry checks. This is a good fit for current-state visibility and short investigations, not an obvious replacement for a metrics warehouse kept for years.
September activity is high, but releases are informal
On September 28, 2026, GitHub listed 2,296 stars, 2,146 forks, and 5 open issues and pull requests. The open set contained 3 issues and 2 pull requests, and the repository had been pushed that same day. Issue 109, opened that day, describes a refresh loop after a Cloudflare Access callback to the private admin route. Those dates show active maintenance and an active defect queue.
The panel repository has no GitHub Releases entry, even though its README identifies the current line as v2.8.6. Operators therefore follow the branch, version file, and separate agent releases rather than one panel release artifact. The maintainer's stated scope is now mainly bug fixes and interface work, with feature requests accepted only when they do not add much complexity, security risk, or load. That restraint suits this project better than endless feature growth.
CF-Server-Monitor deserves a sandbox trial if Cloudflare is already part of your stack and an outbound-only agent is the priority. Our failed 4-second build and 8 failed tests keep it out of the set-and-forget category today. Prove the build, test private login, watch D1 usage, and only then install the agent across the rest of the fleet.