Patch management built for MSPs.
Manage patches across every client environment from one platform. Per-tenant database isolation, not shared multi-tenant row filtering.
Why MSPs choose PatchMon
Most patch management tools were designed for single organisations. PatchMon was built with multi-tenancy from the start - real isolation, not bolted-on client separation.
Per-tenant database isolation
Each client gets their own PostgreSQL database with separate credentials. Not row-level filtering on a shared database. One client's data never touches another's.
Per-tenant branding
Custom logos, favicons, and instance branding per client. Your clients see their brand, not yours. White-label the platform to match each engagement.
Centralized management via gateway proxy
A single gateway proxy routes traffic by hostname to the correct tenant instance. Manage provisioning, updates, and monitoring from one operational layer.
No per-host licensing fees
Host counts fluctuate. Clients onboard and offboard. Per-host pricing punishes growth and creates billing friction. PatchMon has no per-host fees - ever.
Every client gets the full platform
No feature tiers per client. No premium modules locked behind higher plans. Every tenant instance runs the same complete PatchMon platform with all features enabled.
Self-hosted control
You own the infrastructure. You own the data. You control the update schedule, the network topology, and the security boundaries. No vendor has access to your clients' systems.
The multi-tenancy architecture
Multi-tenancy in PatchMon is not a feature flag or a permissions layer. It is an architectural pattern where each tenant is a fully isolated instance with its own database, its own Redis namespace, and its own hostname.
Isolated tenant instances
Each tenant runs their own PatchMon instance backed by a dedicated PostgreSQL database. Instances are provisioned and managed through the multi-tenancy layer. No shared application state between tenants.
Gateway proxy routing
A gateway proxy sits in front of all tenant instances and routes incoming traffic by hostname. client-a.yourmsp.com resolves to Client A's instance. client-b.yourmsp.com resolves to Client B's. Routing is handled at the proxy layer, not the application layer.
Separate Redis namespace per tenant
Each tenant gets their own Redis database index mapping. Background jobs, caching, and real-time data are isolated per tenant. No cross-tenant data leakage in the queue or cache layer.
TLS everywhere
All communication is encrypted in transit. Agent-to-server, browser-to-server, and internal service communication all use TLS. No data travels in the clear between any component.
The per-host pricing problem
Per-host pricing is designed for enterprises with stable, predictable host counts. MSPs do not have stable, predictable host counts. Clients onboard. Clients offboard. Projects spin up 50 servers for three months and then tear them down. Seasonal infrastructure scales up and back.
Every per-host tool turns your patch management cost into a variable that scales with your clients' infrastructure decisions, not yours. You end up either eating the cost, passing it through with markup and billing friction, or underreporting hosts and hoping nobody audits.
PatchMon has no per-host fees. You deploy it, you run it, and the cost does not change when a client adds 200 servers next Tuesday. Your margin stays predictable regardless of how your clients' infrastructure moves.
How PatchMon compares
A direct comparison with the tools MSPs typically evaluate.
| PatchMon | NinjaOne / Atera | Automox | |
|---|---|---|---|
| Pricing model | No per-host fees | Per-host/month | Per-host/month |
| Deployment | Self-hosted or Cloud | Cloud-only | Cloud-only |
| Data ownership | You own everything | Vendor-hosted | Vendor-hosted |
| Linux support | APT, DNF, YUM, APK, Pacman | Limited | APT, DNF, YUM |
| FreeBSD support | Yes - pkg | No | No |
| Windows support | Yes - Windows Update Agent | Yes | Yes |
| Source code | Open source (AGPLv3) | Proprietary | Proprietary |
| Tenant isolation | Per-tenant database | Shared multi-tenant | Shared multi-tenant |
| Vendor lock-in | None - export and leave | High | High |
What each client tenant includes
Every tenant instance runs the full PatchMon platform. No feature gating, no tier restrictions, no artificial limits per client.
- Real-time patch status across Linux, FreeBSD, and Windows
- Compliance scanning with OpenSCAP and CIS benchmarks
- Remote access via SSH and RDP through the browser
- Automated patch policies and scheduling
- Alerting and notifications (email, Slack, Teams, webhooks)
- Dashboard and reporting per client environment
- Agent auto-registration with API keys
- Custom branding - logo, favicon, and instance name
- Full API access for automation and integration
Security your clients can trust
When you manage other organisations' infrastructure, security is not optional. PatchMon's architecture is designed around the assumption that tenants must never see each other's data.
Database-level isolation
Each client's data lives in its own PostgreSQL database with separate credentials. Not a shared database with row-level security. Separate databases.
Outbound-only agents
Agents connect outbound over WebSocket. No inbound firewall rules needed on client hosts. Easier to get approved by client security teams.
No vendor access
Self-hosted means no third party has access to your clients' patch data, host inventories, or credentials. You control who sees what.
Open source and auditable
The entire codebase is open source under AGPLv3. Your clients can audit the code. Their security teams can review the agent. No black boxes.
Ready to manage patches across all your clients?
Deploy PatchMon with multi-tenancy. No per-host fees, no vendor lock-in, no artificial limits.