CF-Server-Monitor: a Cloudflare Workers server monitor with one-way agents
一个基于 Cloudflare Workers + D1 + Durable Objects 的免费多服务器监控探针系统，支持实时监控、离线告警，到期通知，历史数据查看、延迟追踪、地图展示等功能。兼容主流Linux系统，Alpine Linux，OpenWrt，macOS，群晖 DSM、飞牛 fnOS、Windows系统。
At a glance
- What is it?
- CF-Server-Monitor puts the dashboard, API, database and WebSocket push on Cloudflare Workers, D1 and Durable Objects, while a Go agent on each host only reports metrics upward. This is a walkthrough of the mechanism, a first install, and where the design stops being the right choice.
- Who is it for?
- Adopt CF-Server-Monitor if you already have a Cloudflare account and want a dashboard that does not need a VPS to babysit, and if your fleet fits the free-tier budget the README describes (about 60 servers at the default 60-second interval). Skip it if you need remote command execution, WebSSH, or a control channel back to the host; the project deliberately does not offer one, and that is the whole security argument.
- Can I use it commercially?
- Not without permission. GitHub finds no licence file in the repository, and without a licence all rights are reserved by default: you may read the code but not reuse it. Check the README, or ask the authors, before using it.
- Is it still maintained?
- Yes. The repository last received commits 2 days ago.
- What is it written in?
- Mainly JavaScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 17, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What CF-Server-Monitor is for, and who it fits
Most server monitors ask you to run a collector somewhere: a VPS, a container, a Prometheus instance that itself needs patching. CF-Server-Monitor moves the collector into Cloudflare. The README describes the panel, the API, the database and the real-time push as all running on Cloudflare, and the only software you install on your own machines is an agent that sends metrics one way. The stated audience is anyone watching several hosts who wants free hosting and low maintenance, and the supported agent platforms are broad: mainstream Linux distributions, Alpine Linux, OpenWrt, Synology DSM, fnOS, FreeBSD, macOS and Windows.
The design decision that shapes everything else is the one-way report. The README states there is no WebSSH, no remote command delivery and no control channel; the agent only posts metrics to the Worker. That cuts the blast radius if the monitoring component is compromised, and it also means the project cannot help you fix anything. It is an observability tool, not a remote administration tool. If you want one dashboard for CPU, memory, disk, network, latency and expiry dates across a mixed fleet, and you are comfortable with Cloudflare as the trust anchor, this is aimed at you.
The data flow: agent to Worker to D1 to Durable Object
The README's architecture diagram is short enough to read in one pass. An agent sends `POST /update` to a Cloudflare Worker. The Worker validates `API_SECRET`, writes into D1 (the README names the tables `servers`, `settings` and `history`), and broadcasts through a Durable Object over WebSocket so the front end refreshes as soon as a report lands. Browsers, mobile clients and the iOS Scriptable widget all read the same API surface, so there is one source of truth rather than a separate push service.
The interesting part is how the project defends the free tier. Recent notes describe monthly table rotation, sampling on long history queries, caching and rate limiting. Version 2.8.4 added WSS reporting from the agent with configurable WSS windows, falling back to POST outside those windows to reduce Durable Object duration consumption, and it added a Durable Object usage display in the panel. Version 2.8.6 added WSS front-end subscription with 250 ms batched reporting. Those are the numbers to keep in mind when sizing: the README says the default 60-second interval supports roughly 60 servers, and doubling the interval to 120 seconds theoretically doubles that.
One detail worth calling out because it is easy to miss: the Go agent uses the HTTP `Date` header in the Worker response to correct sample time and `boot_time`, so a host with a wrong clock does not corrupt the history charts. It does not change the system clock. That is a sensible, narrow fix.
Installing CF-Server-Monitor on Cloudflare Workers
The README lists three deployment paths and states a preference: connecting the Worker to a GitHub repository, or GitHub Actions, over the one-click button, because the one-click path is awkward to keep synced with upstream. The prerequisites are a Cloudflare account, a GitHub account, and an `API_SECRET` that is complex enough to serve both as the agent reporting key and the initial admin password.
For the GitHub-connected route, fork the repository, then in the Cloudflare dashboard open Workers & Pages, create a Worker and import the fork. The build and deploy commands are given explicitly:
npm run build:frontend
npx wrangler deployAfter the first deploy, add `API_SECRET` under the Worker's Variables and Secrets. The README does not document a rollback procedure for a bad deploy, so treat the Cloudflare dashboard's version history as your only undo.
The GitHub Actions route needs a D1 database first (the README suggests the name `server-monitor-db`), plus your Cloudflare Account ID and an API token with at least Workers edit and D1 deploy permissions. Those go into the fork's Actions secrets:
CF_API_TOKEN
CF_ACCOUNT_ID
D1_DATABASE_ID
API_SECRET
CORS_ALLOWED_ORIGINSOnly the first four are required; `CORS_ALLOWED_ORIGINS` is optional and takes comma-separated origins. Pushing to `main` deploys automatically, and the `Deploy to Cloudflare Workers` workflow can also be run by hand. The repository's `package.json` pins `wrangler` at `^4.0.0` and requires Node 18 or newer.
First real use: log in, add a server, run the generated command
After deployment the admin panel lives at the Worker domain under `/admin#/admin`. The README gives the default credentials as username `admin` with the password equal to `API_SECRET`, and advises changing the admin username and password immediately. It also notes the admin login password can be separated from `API_SECRET`, while agents keep reporting with the Cloudflare environment variable.
Adding a host is deliberately mechanical. Fill in a server name in the server management view, click add, then use the copy button and pick the target system and agent version. The README recommends using the generated command rather than writing your own, because it carries the server ID, Worker URL, secret, reporting interval, network quality nodes and interface selection. Since version 2.8.3 the default agent is the separate `cfsm-agent` project, and the installed service is named `cf-probe`.
Some parameters can be changed later from the panel and the agent will pull them on its next report: ping nodes, collection interval, HTTP and WSS report intervals, the interface used for statistics, the traffic reset day, and up/down traffic correction. Others cannot: the README states that changing the Worker address, `API_SECRET` or the auto-update switch requires re-running the install command. Plan for that before you roll an agent out to a large fleet.
Where the design runs out: no control channel, free-tier ceilings
The single biggest limitation is also the selling point. There is no remote command execution and no WebSSH, so when a host goes dark you get an alert and nothing else. If your workflow depends on the monitoring panel to restart a service or open a shell, this is the wrong tool and no configuration will change that.
The second constraint is the free tier itself. The README's own sizing is about 60 servers at a 60-second interval, doubling only if you move to 120 seconds. That arithmetic is a design target, not a promise, and it interacts with how many people keep the dashboard open: version 2.8.4 specifically mentions optimizing Durable Object broadcast when no front end is subscribed, and adding a Durable Object usage display, which suggests idle consumption was a real concern. If you have hundreds of hosts or want sub-minute resolution everywhere, you are outside the intended envelope.
Third, the README does not document a rollback path for a bad deployment, and the repository has no releases to pin. Upgrades happen by pushing to `main` or re-running the workflow. On a fleet where a broken Worker means no monitoring at all, that is a gap worth knowing about before the first incident rather than during it.
How it differs from a self-hosted control-plane probe
The obvious alternative is the traditional self-hosted probe with a central control plane, the model the README contrasts against in its comparison section. The difference is not cosmetic. In a control-plane design, the server holds a channel to each agent, so the panel can push commands, open a terminal, or trigger a restart. You pay for that by running and patching the central server, and by accepting a much larger attack surface on every monitored host.
CF-Server-Monitor inverts the trade: Cloudflare hosts the panel and the database, agents only post outward, and the feature list stops at observation. You give up remote administration and you accept Cloudflare as a dependency, including its free-tier limits and its availability. In exchange there is no VPS to maintain and the agent's compromise does not hand anyone a shell on your fleet.
A second, quieter difference is parameter delivery. The README describes the panel pushing changes such as ping nodes, intervals and traffic reset day down to agents automatically, while a few settings require reinstalling. Control-plane probes usually make everything remotely mutable. If you change collection intervals often, check which of your settings fall in the reinstall-only bucket before committing.
Maintenance, licensing and what to check before adopting
The repository is not archived and its last push was on 2026-09-17, so the codebase is being changed rather than parked. That is the only maintenance signal available here: no releases were retrieved, so there are no version tags to pin or changelogs to diff between. Upgrades therefore mean tracking `main`. The README's own recommendation, connecting the Worker to your fork or using GitHub Actions, exists precisely because the one-click deploy is inconvenient to keep in sync.
On licensing, the README and the repository both point at MIT, and the README carries a badge reading MIT, while the license field supplied with the repository is unknown. That discrepancy is worth resolving yourself by opening the licence file or the README's licence section before you depend on the terms; this is a factual gap, not legal advice. The README also lists security controls that matter for a public deployment: `API_SECRET`, admin password, JWT, Turnstile, CORS and a CSP allowlist. The `CORS_ALLOWED_ORIGINS` secret is optional, which means a default deployment has no cross-origin restriction unless you set it.
The upgrade cost is mostly operational: agent versions and Worker versions move independently, and version 2.8.4 explicitly requires agent `v1.0.10+` for WSS reporting. If you deploy the Worker without matching agents, you lose the feature, not the monitoring.
Editorial conclusion
Adopt CF-Server-Monitor if you already have a Cloudflare account and want a dashboard that does not need a VPS to babysit, and if your fleet fits the free-tier budget the README describes (about 60 servers at the default 60-second interval). Skip it if you need remote command execution, WebSSH, or a control channel back to the host; the project deliberately does not offer one, and that is the whole security argument. Before trusting it with production, verify three things yourself: the D1 database ID you put into the GitHub Actions secrets, that the generated install command carries the right server ID and Worker URL, and that your chosen notification channel actually fires on a test offline event. The repository's last push was on 2026-09-17 and it is not archived, so the code is moving, but there are no tagged releases in the repository to pin against.
Frequently asked questions
What is a server monitor, and how does CF-Server-Monitor fit that description?
A server monitor collects metrics from hosts and presents them for inspection. CF-Server-Monitor does this by having an agent on each host post metrics to a Cloudflare Worker, which stores them in D1 and pushes updates to the front end through a Durable Object.
How can I monitor my server health with CF-Server-Monitor?
Add the server in the admin panel, copy the generated install command for your system, and run it on the host. The agent then reports CPU, memory, disk, network, connection counts, load and uptime at the configured interval, and the panel raises offline and resource alerts.
How to monitor traffic on a server with CF-Server-Monitor?
The project tracks monthly traffic with correction, plus per-interface statistics, and version 2.8.6 added traffic reports. The README states you can change the interface used for statistics and the traffic reset day from the panel, and the agent picks those changes up on a later report.
What is the best monitoring tool for servers, and where does CF-Server-Monitor sit?
The README positions CF-Server-Monitor against traditional control-plane probes: it favors free hosting on Cloudflare, one-way agent reporting and low maintenance over remote administration. If you need to push commands or open a shell from the panel, it is not the right pick.
Community notes