Surface OS drift and container drift from one agent.
PatchMon gives SRE and DevOps teams a lightweight view of host-level package currency alongside Docker container, image, volume, and network state, with alerting that hooks straight into your incident pipeline.
Why DevOps and SRE teams choose PatchMon
Most patch tooling was written for static Windows or macOS endpoints and bolts Linux on later. PatchMon is the opposite: built for container and VM fleets, with a footprint that fits a CI/CD world.
Host and container drift in one view
Monitor Docker container status, image versions, volumes, and networks alongside host-level package currency from the same agent.
Lightweight Go agent
A single static binary with a 100MB memory ceiling and two reserved CPU threads. No JVM, no Python runtime, no plugin sidecars.
Webhook and API-first alerting
Every alert is a webhook. Hook directly into PagerDuty, OpsGenie, Squadcast, or your own router without a middleware layer.
OIDC SSO with RBAC
Developers get read-only patch status. Only ops leads can trigger patches. Role mappings come straight from your identity provider.
Ephemeral host-friendly
Agents auto-register with API keys, deregister cleanly, and tolerate short-lived infrastructure without leaving zombie records.
Managed Cloud, predictable cost
PatchMon Cloud runs the control plane for you. Flat per-tier pricing, isolated storage, and managed upgrades so SRE time stays on your own services.
The drift problem nobody owns
Container images age. Host OS packages age. A base image pinned six months ago is now running a libc two CVEs behind, and the team that deployed it is not the team that owns patching. When a critical vulnerability lands, someone has to produce a list of “every host and every image running this package”, fast.
The tooling for that list is usually a combination of a heavyweight CMDB (slow, stale), an image scanner bolted onto CI (catches the build, misses the fleet), and SSH-in-and-dpkg scripts (works once, does not scale). None of those answer the actual question, which is: what is running on my hosts right now, and how old is it.
PatchMon exists to answer that question. One lightweight agent per host reports package state and container state continuously. Alerts fire when something drifts beyond your threshold. The answer is a dashboard filter, not a fire drill.
What the agent reports
One binary per host. Two data surfaces: OS package state and Docker state. Reports go back over WebSocket to your PatchMon server.
- Docker container, image, volume, and network monitoring per host
- APT, DNF, YUM, APK, and Pacman package currency across Linux distros
- FreeBSD pkg support for hosts running BSD in production
- Webhook alerts fireable from any threshold rule you define
- REST API for read and write operations, plus documented WebSocket protocol
- OIDC SSO with Authentik, Keycloak, Okta, Azure AD, and Google
- Role-based access control enforced per API endpoint and UI route
- OpenSCAP and Docker Bench compliance scans scheduled per host group
- Structured JSON logs from server and agent for existing log pipelines
- pprof endpoints on the server for production performance profiling
Why not just use an RMM?
RMM tools (NinjaOne, Atera, Datto, ConnectWise) have no meaningful Docker or container monitoring. Their patching model assumes static Windows or macOS endpoints, with long-lived hosts that live for years and belong to a single user. Ephemeral Linux containers in a CI/CD-driven fleet are not the target audience.
PatchMon treats containers as first-class: image age, container state, volume and network drift all ship from the same agent that reports OS packages. PatchMon Cloud runs the control plane with isolated per-customer storage, so your SRE team only operates the agents, not another stateful service.
Where PatchMon sits in the stack
PatchMon is a read-first observability layer for patch state. It does not replace your orchestrator, your image scanner, or your CMDB. It fills the gap between them.
Below your orchestrator
Kubernetes, Nomad, and ECS own scheduling. PatchMon reports host and container state on the nodes they schedule onto.
Beside your image scanner
Trivy, Grype, and Snyk catch vulnerabilities in the CI stage. PatchMon catches the hosts still running images from two deploys ago.
Above your log pipeline
Server and agent emit structured JSON logs. Ship them to Loki, Elasticsearch, or Datadog alongside every other service.
Plugged into your incident router
Every alert is a webhook, so PagerDuty, OpsGenie, or your own routing layer see PatchMon as just another signal source.
In front of your CMDB, not replacing it
CMDB owns long-lived asset records. PatchMon owns current state. The two cross-reference cleanly via hostname or fingerprint.
Under your identity provider
OIDC is the only authentication surface that matters. Role mappings come straight from your IdP; local users are for break-glass only.
How SRE teams roll it out
Four steps from zero to drift alerts routed through your on-call rotation. Most of the work is agent rollout, not platform setup.
Start your Cloud trial
Sign up for a free PatchMon Cloud trial. Your instance is provisioned automatically, with isolated storage and no infrastructure to run.
Install the agent on your first host
One-line install via curl, Ansible, or your existing config management. The Go agent runs on every major Linux distro, FreeBSD, and Windows with a 100MB memory ceiling.
Review your drift landscape
The dashboard surfaces OS package state and Docker image/container drift per host. Set patch-age thresholds per environment and wire in OIDC SSO for the whole team.
Route alerts into your incident pipeline
Point the webhook channel at PagerDuty, OpsGenie, Squadcast, or your own router. Drift becomes just another signal source in the rotation you already run.
DevOps and SRE FAQ
Does PatchMon integrate with Kubernetes?
Not directly. PatchMon has no CRD, operator, or cluster-level controller today. If you install the agent on the host OS of a Kubernetes node, you get the same visibility you would on any Linux host: package currency and Docker state. Cluster-level concerns (pods, deployments, nodes via the Kubernetes API) sit outside PatchMon's scope today.
How does this differ from a CMDB or an asset inventory?
CMDBs are built for asset tracking at the organisation level, with long-lived records and manual reconciliation. PatchMon is built for patch state and drift detection in near-real-time, with the agent owning the source of truth and the server reflecting current state. The two complement each other; PatchMon is not trying to replace your CMDB.
Can alerts fire into PagerDuty or OpsGenie?
Yes. The generic webhook channel posts JSON to any endpoint, so PagerDuty, OpsGenie, Squadcast, Teams, and any other platform that accepts an HTTP POST can be wired in directly. PatchMon also has dedicated integrations for Slack, Discord, email, and ntfy, and you can combine multiple channels per alert rule.
Does the agent run in a container?
It can. The recommended deployment for containerised hosts is the agent as a container with access to the host's Docker socket and the host's package database. You can also run it as a systemd unit on the host. Both modes are supported and the reporting format is identical.
What is the resource footprint per host?
The agent sets GOGC=50, a 100MB memory ceiling via SetMemoryLimit, and GOMAXPROCS(2). In practice steady-state usage is well under the ceiling on hosts reporting a few hundred packages. The server-side load is similarly modest; a single small VM comfortably handles a few hundred connected agents.
Book a demo
15-minute call, no sales pitch. We'll show you the dashboard, agent deployment, and answer your questions.
Iframe blocked? Book directly at cal.com/9-technology-group/patchmon-demo.
Ready to catch drift before it catches you?
Start a free PatchMon Cloud trial. Agents on every host, drift alerts in your incident pipeline, no infrastructure to babysit.