PatchMon turns Linux patch day into a single approval queue, without the SSH crawl
On October 23, 2026, the selfh.st newsletter spotlighted PatchMon, an AGPL v3 self-hosted patch-management platform that drives Linux, FreeBSD, and Windows updates from one queue with dry-run, approval, and audit. For fleets beyond a few dozen machines that must answer to auditors, it replaces the SSH crawl and homegrown playbooks.
October 23, 2026. The selfh.st weekly newsletter puts PatchMon in its Content Spotlight: a self-hosted, AGPL v3 patch-management platform that drives Linux, FreeBSD, and Windows updates from a single web dashboard. The same week. The project claims 70,000 managed servers, more than 4,000 live installations, and 3,500 GitHub stars. The same week, again. Its documentation walks through a Docker deployment in three commands — provided you add an external PostgreSQL and Redis. The point that matters: PatchMon does not just patch packages — it turns patch day, the ritual where an operator chains SSH sessions, into an approval queue where every step leaves an audit trail.
The problem PatchMon claims to solve: patch day without a system
Before judging the tool, look at the problem it attacks. In a team that runs a few dozen servers without a dedicated platform, patching almost always collapses into one of three rituals.
The SSH crawl. You log into every host, run apt update && apt upgrade, read the output, repeat forty-seven times, and miss the one machine that mattered.
The Ansible sprawl. Three playbooks for three distributions, --dry-run output nobody reads, and a “did it actually run?” that no one can answer without logging in again.
The spreadsheet. One row per host, a “done” column, a date typed by hand. When the auditor asks for evidence, you open the spreadsheet and pray.
PatchMon replaces all three with a single queue: what is pending, who approved it, what shipped, and what you can show an auditor. That is a precise positioning — not yet another interface wrapped around apt.
What the agent does: outbound-only, multi-OS, no inbound ports
The architecture deserves attention, because it is what makes the tool credible on a real fleet. The PatchMon agent is a lightweight Go binary that communicates outbound only to the server — no inbound ports are required on the monitored hosts. No firewall changes, no SSH or WinRM exposure, no mandatory VPN.
The server itself is a single Go binary with the React frontend embedded: one container, no Node runtime to deploy. The agent covers seven package managers — apt, dnf, yum, apk, pacman, zypper, and pkg (FreeBSD) — plus Windows Update. It is multi-OS by design, not a Linux tool with a Windows bolt-on.
The minimal deployment fits in a Docker Compose file, but it has to be said plainly: PatchMon requires external PostgreSQL and Redis services for storage and job queues. That is a real operational cost, especially for a small homelab that only wanted to “just” watch three machines.
From dry-run to audit: the patching loop
PatchMon’s value concentrates in its patching loop, which enforces a discipline that is often missing elsewhere.
Dry-run first. Every run captures the full package-transaction plan before it touches production. You know exactly what would change.
Approve next. One click turns the validated dry-run into a real run, with a per-host trail of who approved what and when.
Scheduling. Patch policies decide the timing: immediate, maintenance window, or delayed rollout. Approve now, execute later.
Selective patching. Target specific packages, security-only updates, or a full upgrade — across all seven managers.
History. Every run is searchable: exit code, duration, packages touched, approver, and host.
Live streaming completes the picture: agent output is pushed to the browser over WebSocket, with the ability to stop a run mid-flight. For an SRE who has watched an upgrade take off on the wrong machine, that is a concrete safety net.
Compliance as the deciding argument
The most serious differentiator is not technical — it is regulatory. PatchMon ships OpenSCAP scans against CIS benchmarks and Docker Bench assessments against container hosts. You see which rules pass and fail, with severity and remediation steps, and track the compliance score over time.
Translated into practice: when the auditor asks for evidence, the report is ready in minutes, not days. That is the argument that tips the adoption of a patching tool — especially in organizations subject to frameworks that demand demonstrable patch traceability.
What PatchMon does not replace
PatchMon is not alone in this space, and saying so plainly helps settle the verdict. Uyuni, the community successor to SUSE Manager, handles patching, configuration, and the lifecycle of SUSE and Red Hat systems — but its scope extends beyond updates, making it a full configuration-management tool that is heavier to adopt. Canonical Landscape does comparable work for Ubuntu, in exchange for an Ubuntu Pro license on covered hosts. Ansible AWX and Semaphore cover “I run playbooks”, but leave audit and compliance to you.
PatchMon sits in between: it does not do configuration management, it does not replace a CMDB, and it does not score the criticality of the CVEs hitting your packages — a point to keep in mind if your requirement is risk-based prioritization. What it excels at is one precise thing: turning “is it patched?” into an answer that is traceable and approvable. If that is exactly the question you are asked, this is exactly the tool that answers it.
What to do
Trying PatchMon is fast.
mkdir patchmon && cd patchmon
bash -c "$(curl -fsSL https://raw.githubusercontent.com/PatchMon/PatchMon/refs/heads/main/docker/setup-env.sh)"
docker compose up -dOpen http://localhost:3000, create an admin user, add a host, and copy the generated agent install command onto the target machine. The end-to-end path is designed for the first few minutes.
Before deploying to production, three checks apply. Size PostgreSQL and Redis: they are external dependencies, not options. Lock down authentication: OIDC (Authentik, Keycloak, Okta), TOTP, and granular RBAC all exist — enable them before exposing anything. Test the SSH terminal’s proxy mode: browser-based SSH/RDP access can route through the agent’s outbound link, so you avoid opening SSH inbound on hosts.
Verdict
If you manage more than a few dozen Linux machines and must answer for them — a production team, a service provider, an audited entity — PatchMon replaces the SSH crawl and homegrown playbooks with an auditable approval queue, and its outbound-only agent simplifies network deployment. The PostgreSQL/Redis overhead pays for itself the moment traceability has a price tag. If you have three machines in a homelab, it is too much infrastructure for the benefit: a tuned unattended-upgrades or a small playbook stays leaner. The lesson extends beyond PatchMon: patch day becomes an engineering problem again the moment you must prove you did it — and that is exactly what this generation of self-hosted tools exists to solve.