PatchMon: a self-hosted Linux patch platform with outbound-only agents

The problem PatchMon targets: patch state scattered across hosts

Most small fleets start with a cron job and an SSH key. That works until someone asks which hosts are behind on security updates, who approved last Tuesday's kernel upgrade, and whether a package transaction was ever previewed before it ran. PatchMon is built for that second stage. The README describes it as a single pane of glass to monitor, patch and secure a Linux fleet, with FreeBSD and Windows agent support, which places it in the same category as configuration management suites and dedicated patch tools rather than as a general remote-execution layer.

The intended user is an operations team, not a single administrator with three servers. The feature list leans on multi-user concerns: RBAC with custom roles and granular permissions, OIDC single sign-on with group-to-role mapping, and alerts that can be assigned to team members. If nobody else ever reads your patch reports, most of that machinery is overhead you are paying for in deployment complexity.

How the agent and server actually communicate

The architecture is a control plane plus a per-host agent, and the direction of traffic is the defining constraint. According to the README, the agent communicates outbound-only to the PatchMon server on your schedule, so monitored hosts need no inbound ports, no SSH exposure and no VPN. That single design decision explains several other choices: enrolment uses tokens with IP allow-lists, and the README states that rate limiting is applied on every endpoint.

Live patch output travels the same way. The README says agent stdout and stderr are streamed over WebSocket to the browser during a patch run, and that a run can be stopped mid-flight. The web SSH terminal offers a proxy mode that routes through the agent instead of connecting directly, which keeps the no-inbound-port property intact for interactive access too.

On the server side, the repository layout is more informative than the README. The top level holds agent-source-code/, server-source-code/, frontend/ and docker/. The README states the server is a single Go binary with the React frontend embedded, so there is no Node runtime at deploy time. The root package.json confirms the split: dev:server runs the Go server from server-source-code, dev:frontend runs the frontend workspace, and build:server and build:frontend are separate targets. That matters if you plan to build from source rather than pull a container.

Installing PatchMon with Docker Compose

The README calls Docker the fastest way to try PatchMon. The quick start is four commands: create a directory, run the setup script, bring the stack up, then open the UI. The setup script is fetched from the repository's docker/ directory and, based on its name, writes the environment file that Compose expects.

mkdir patchmon && cd patchmon
bash -c "$(curl -fsSL https://raw.githubusercontent.com/PatchMon/PatchMon/refs/heads/main/docker/setup-env.sh)"
docker compose up -d

After that, the README says to open http://localhost:3000, create an admin user, add a host in the UI and copy the generated install command onto the target server. That last step is the real first use: the server issues a per-host enrolment command, you run it on the machine you want to manage, and the agent begins checking in outbound. The UI is where you then see inventory, package state and repository lists for that host.

Note the port. The related searches include a query about the PatchMon port, and the README answers it directly for the Docker path: 3000. If you are placing this behind a reverse proxy, that is the upstream you point at. The README also lists other deployment routes, including Docker manual, Proxmox LXC and PatchMon Cloud, and points to patchmon.net/docs for the full set. The README does not document a rollback procedure for a failed deployment, so plan your own snapshot step before you migrate an existing host inventory into it.

Dry-run validation is the feature that justifies the agent

The strongest argument for PatchMon over a shell script is the approval flow. The README states that a dry run previews the exact package transaction on a host before anything changes, and that every run captures the full plan. Approval then converts a validated dry run into a real patch run, with a per-host audit trail of who approved what and when. Scheduled patching is expressed as policies: immediate, maintenance window, or delayed rollout, so you can approve now and execute later.

That is a meaningful separation of duties. The person who decides a patch is safe does not have to be the person who triggers it, and the record of the decision survives. Selective patching narrows the blast radius further: the README says you can target specific packages, security-only updates, or a full upgrade, across apt, dnf, yum, apk, pacman and FreeBSD pkg.

Be clear about what a dry run is and is not. It is a preview of the package transaction the host would perform. It is not a test of whether your application survives the upgrade. Nothing in the README suggests PatchMon stages packages or rolls back a completed run, so a kernel upgrade that breaks a driver is still your problem.

Compliance scanning and where the scope stops

PatchMon bundles OpenSCAP CIS Benchmarks and Docker Bench for Security, per the README, and tracks compliance scores over time with rule-level results and remediation guidance. The repository topics include openscap and cis-benchmark, which matches. For a team that currently runs oscap by hand and pastes XML into a ticket, having the results land in the same inventory as package state is a genuine reduction in work.

The limitation is that these are the two scanners named in the README. If your compliance regime requires a different benchmark profile or a scanner that is not OpenSCAP or Docker Bench, PatchMon is not a general compliance framework and the README does not present it as one. Treat the compliance view as a convenience layer over two specific tools, not as an evidence pipeline you can hand to an auditor without checking what the rule-level results actually contain.

The AI terminal assistant is the part to think hardest about

The README describes an AI chat panel inside the web SSH terminal that offers command suggestions, error diagnosis and context-aware help, working with OpenRouter, Anthropic, OpenAI or Google Gemini. This is the most opinionated thing in the product, and it is worth being blunt: an assistant that reads terminal context and sends it to a third-party model provider is a data-flow decision, not a convenience toggle. Whatever appears in that terminal, including hostnames, paths and error output, is in scope for whatever provider you configure.

The README does not state that the assistant can be disabled, nor does it describe what context is transmitted or retained. If you are evaluating PatchMon for a regulated environment, that gap is the first question to raise with the maintainers rather than something to discover after deployment. The same caution applies to the outbound-only agent model in reverse: it is excellent for firewall hygiene, but it means the agent initiates connections to your server, so the server must be reachable from every managed host.

PatchMon versus Ansible for patch orchestration

The obvious alternative for a team already automating Linux is Ansible with the apt, dnf or yum modules. The difference is where state lives. Ansible is a push-based execution engine: you hold a playbook, you run it, and the record of what happened is a log you choose to keep. PatchMon is a pull-based control plane: the agent reports inventory and package state continuously, the server holds the desired patch decision, and the agent fetches work. You get a persistent inventory and an approval record without building either.

The cost is a new always-on service with a database, a UI and an agent on every host. Ansible needs none of that. If your fleet is small, your patch cadence is simple, and nobody is asking for an approval trail, Ansible plus a scheduled run is less infrastructure to own. PatchMon earns its place when the inventory question and the audit question are the actual problem. The related searches include patchmon alternatives, and the honest framing is that the alternative is usually a tool you already have, not another patch platform.

Licence, maintenance and upgrade cost

PatchMon is licensed AGPL-3.0, stated in both the README badge and the root package.json. For self-hosting inside an organisation that is not distributing the software, that is typically workable, but AGPL-3.0 carries network-use obligations that differ from permissive licences, so have your own counsel read the terms rather than treating this paragraph as advice. The README also notes a managed cloud option, so the project has a commercial path alongside the free self-hosted one.

On maintenance, the recent release history shows v2.1.3, v2.1.2 and v2.1.1 all dated 2026-08-15, and the last push to the repository was on 2026-08-26. That is a project shipping point releases in quick succession, which cuts both ways: fixes arrive fast, and so do upgrade prompts. The repository includes renovate.json and lefthook.yml, and package.json defines audit, vuln:go, security:secrets and security:codeql scripts, so dependency and secret scanning are wired into the development workflow.

The upgrade cost you should budget for is the agent, not the server. The README lists agent-update alerts among the alert types, which implies agents are expected to be updated after the server moves. If you pin an agent version and forget it, you have a fleet of hosts running against a server that has moved on. The README does not describe a long-term support branch, so plan to track releases rather than sit on one.

Editorial conclusion

Adopt PatchMon if you run Linux at a scale where per-host SSH patch runs have stopped being auditable, and you can accept an AGPL-3.0 server plus agents that need outbound reach to your control plane. Skip it if you need a vendor support contract, or if the hosts you patch cannot dial out. Before rolling it out, verify two things yourself: that your target distros appear in the supported package manager list, and that your security team is comfortable with the AI terminal assistant, which sends terminal context to an external model provider you configure.

Frequently asked questions

Official sources

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