Patch visibility and control with PatchMon

Overview

PatchMon is an open-source, self-hostable Linux patch management and fleet-monitoring platform: a single dashboard shows which packages are outdated across every managed host, and lets you preview, approve, and roll out updates on a schedule rather than trusting that a cron job somewhere is quietly doing the right thing.

The detail that matters most for a security-conscious rollout: the agent on every managed host connects outbound only to the PatchMon server. There's nothing to open inbound, no SSH exposure to manage, no extra firewall rule to justify to a security review — the host reaches out to report its patch state and pull instructions, rather than the server reaching in.

[ PatchMon server ]  ◄── outbound only ──  [ Agent — host 1 ]  (apt / Debian, Ubuntu)
   web UI + API                        ◄── outbound only ──  [ Agent — host 2 ]  (dnf/yum / RHEL family)
                                        ◄── outbound only ──  [ Agent — host 3 ]  (apk / Alpine)
                                        ◄── outbound only ──  [ Agent — host N ]  (pacman / Arch)

No inbound port opened on any managed host at any point in this diagram.

1. Deploying the server

The server itself ships as a single Go binary with the web UI bundled in — no separate Node runtime, no Java/Tomcat stack to patch and babysit in its own right. Two supported paths:

• Docker — the documented/preferred route, one container running the whole server
• Native installer — a one-line install script that walks through the setup questions interactively, for a bare-metal or LXC deployment where Docker isn't the house style

Either way, first boot gives you a clean web UI to create the admin account and start adding hosts — there's no separate database or reverse-proxy configuration required to get a usable first deployment running.

2. Installing the agent

Each host is added from the dashboard first, which generates a one-line install command scoped to that host; running it on the target server installs the agent and registers it with the server in one step. The same agent binary handles every supported package manager, so a mixed estate — Debian/Ubuntu, RHEL family, Alpine, Arch — is genuinely one workflow, not one per distro family:

Hosts are organized into groups (by environment, role, or criticality) so a patch policy or a dashboard view can be scoped to "all dev web servers" rather than treating the whole fleet as one undifferentiated blob.

3. The dry-run → approve → deploy workflow

This is the part that separates PatchMon from "just SSH in and run the upgrade command": every patch run has a preview step before anything touches a host.

1. Dry-run — PatchMon previews the exact package transaction that would happen on a given host: what would be upgraded, added, or removed, captured as a full plan before any of it executes.
2. Approve — a one-click approval turns a validated dry-run into an actual patch run, with a per-host audit trail recording who approved what and when — the artifact an auditor actually wants to see, generated as a side effect of the normal workflow rather than as separate paperwork.
3. Policy — patch policies decide when an approved run executes: immediately, in a defined maintenance window, or as a delayed rollout — so "approve now" and "apply now" are deliberately two different moments.
4. Live execution — once a run starts, output streams to the browser in real time over WebSocket, with the ability to stop a run mid-flight if something looks wrong partway through.

Runs can also be scoped narrowly — security-only updates, a specific package, or a full upgrade — rather than always being all-or-nothing.

4. Compliance scanning

Beyond raw patch status, PatchMon can run OpenSCAP and CIS benchmark scans against managed hosts (and Docker Bench scans against container hosts), tracking a compliance score over time rather than a one-off snapshot. For an environment with a recurring audit cycle, this turns "prove your patch posture" from a manual evidence-gathering exercise into something that's already sitting in the dashboard when the question comes up.

5. Browser-based remote access

Managed hosts can also be reached via an in-browser terminal session routed through the agent's existing outbound connection — useful for a quick look at a host without opening a direct SSH path to it, or juggling a separate bastion/jump-host setup just to get a shell.

Verdict: how good is it for patching Linux systems?

For the specific problem of "what's actually outdated across my fleet, and how do I roll updates out without surprises" — genuinely strong, and the outbound-only agent model is the single best design decision in it. It removes an entire category of "why does this monitoring tool need an inbound hole in the firewall" conversation before it starts.

• Where it shines: visibility (one screen, every host, every outdated package), and the dry-run/approve/audit-trail loop, which maps naturally onto a change-management process that already expects an approval step.
• Where to plan around it: it's a patch orchestration layer on top of your distro's own package manager, not a replacement for good baseline images or a testing/staging rollout discipline — a bad package is still a bad package whether PatchMon approved the run or a human typed the command by hand.
• Fits well alongside: Grafana/Zabbix for performance metrics, LibreNMS for network device visibility, and PatchMon specifically as the patch/compliance layer — each tool doing the one job it's actually good at, rather than one platform stretched thin over all of them.

Rollout checklist

• Server deployed (Docker preferred) and reachable only from hosts that need to report in — not exposed more broadly than necessary
• Hosts grouped by environment/role before onboarding the full fleet, not after
• Dry-run reviewed at least once per host group before the first real approval, so the plan output itself is trusted
• Patch policy set deliberately per group — immediate for low-risk dev hosts, maintenance-window for anything customer-facing
• Compliance scanning (OpenSCAP/CIS) enabled and baseline score captured before treating it as an ongoing metric
• Access to the PatchMon dashboard itself scoped with RBAC — it can trigger real changes across the fleet, so it's not a "everyone gets admin" tool