Data residency and ownership
Device data, credentials, and remote sessions stay on infrastructure you control, in the country you choose. The data sits in a database you can query, back up, and take with you.
Self-hosted RMM · 2026
Self-hosting an RMM puts the most privileged software in your stack on infrastructure you control. This guide covers why teams do it, what a deployment needs, the security work you take on, and how the options differ.
The short answer
Self-host when data residency, client contracts, or auditability matter enough that you are willing to own updates, backups, TLS, and host security for a system with admin reach into every endpoint. If nobody on your team wants that job, use a hosted plan. Breeze does both: the full platform self-hosted under AGPL-3.0 from a Docker Compose file with one PostgreSQL database, or the same platform hosted for you, with a migration path between them.
If you are new to the category, start with what RMM is. The case for self-hosting it comes down to control, and these are the reasons that come up over and over.
Device data, credentials, and remote sessions stay on infrastructure you control, in the country you choose. The data sits in a database you can query, back up, and take with you.
Healthcare, legal, and government contracts increasingly specify where management tooling can live. A self-hosted RMM answers that question cleanly, and open source platforms can run air-gapped when a contract requires it.
An RMM agent runs with administrative privileges on every machine it manages. When the platform is open source, you can read what the agent does, see what data it collects, and build it from source.
Per-device pricing grows linearly with your fleet. A self-hosted instance mostly does not. The larger you get, the better the math, provided you count your own time honestly.
Paying nothing is a separate question from owning the deployment. If price is the main driver, our free RMM guide covers free tiers, trials, and what self-hosting really costs in server and time.
Self-hosted RMM software has a reputation for sprawling stacks, and some of it is earned. Breeze deliberately keeps the footprint small.
A Go agent on each managed device (Windows, macOS, Linux), a Hono/TypeScript API, and one PostgreSQL database. The AI operator is a fourth layer on top, and the RMM is fully functional without it.
A Linux VPS with 4 GB RAM and 2 vCPUs is a reasonable starting point. Deployment is a Docker Compose file on your own infrastructure, and a single properly sized VPS runs it.
Backups are a database dump. Upgrades are a compose pull. It is still your server to patch and monitor, but the surface you operate is small on purpose.
The quickstart in the Breeze documentation walks through the deploy, and a setup wizard handles initial configuration, agent deployment, and your first device enrollment. The source is on GitHub.
Self-hosting an RMM is not like self-hosting a blog. If the server is compromised, the attacker has administrative access to every managed endpoint. RMM platforms have been targeted in supply-chain attacks because of that leverage.
You patch the host operating system, the container runtime, and the RMM itself. When a hosted vendor has a vulnerability, their team patches it. When your deployment has one, you patch it, and the clock starts when you notice.
Back up the database, encrypt the backups, and test a restore before you need one. Breeze keeps everything in a single PostgreSQL database, so a backup is a database dump rather than a multi-store choreography.
Agents have to reach your server, so certificates have to stay current and the firewall should expose only what is needed. Restrict database access and keep access logs.
Anyone with admin rights in the console has reach into every managed endpoint. Enforce MFA and review who holds access. In Breeze, remote sessions are MFA-gated and audited at the session level.
Whoever controls the code-signing certificate on an RMM agent controls what those machines will run. Since v0.105.0, Breeze self-hosters sign agent packages under their own certificate. Each official release publishes the unsigned Windows build outputs plus a signed release manifest. A template repository verifies that manifest before any step that touches your signing credentials, then signs the Windows artifacts, signs and notarizes the macOS artifacts under your Apple Developer ID, and publishes a release your instance trusts. If the release repository and manifest key configured on your instance disagree, the API refuses to boot rather than silently freezing fleet updates.
The tradeoff is real: the public Windows installer is now unsigned, so a bare download will trip SmartScreen until you sign it yourself. Setup is about an afternoon. Hosted Breeze deployments are unaffected. Read why we built it this way, or go straight to the signing guide.
Same platform either way. The difference is who carries the pager.
Current plans, including self-host support, are on the pricing page.
Four projects you can run on your own server, compared on the things that matter for a self-hoster: license, scope, what you have to operate, and where the limits are. For the capability-by-capability matrix, see the open source RMM guide.
| Project | License | Scope | What you operate | Limits |
|---|---|---|---|---|
| MeshCentral Full comparison → | Apache-2.0 (OSI-approved) | Remote access toolkit: remote desktop, terminal, file transfer. No monitoring, alerting, or patch management. | Node.js server with NeDB or MongoDB. A 1 to 2 GB RAM VPS handles hundreds of agents. | Nothing gated behind a commercial tier. |
| Tactical RMM Full comparison → | Custom Tactical RMM License. Source-available, not OSI-approved. Commercial or hosted resale needs written approval from AmidaWare. | Script-driven RMM: script-based monitoring and alerting, strong Windows patch management, remote access through a bundled MeshCentral integration. | Django, PostgreSQL, Redis, Celery, Nginx, and MeshCentral, deployed with Docker. 4 GB RAM minimum, 8 GB recommended for production. | No device cap. Code-signed agent builds, SSO, and reporting require a paid sponsorship tier. |
| NetLock RMM Full comparison → | AGPL-3.0 | Core RMM with multi-tenancy, remote tools, security baseline enforcement, and whitelabel. | .NET 8 server with MySQL. Docker and Kubernetes supported, and it can run fully air-gapped. | Free Community Edition is capped at 25 devices. A paid Professional tier lifts the limit. |
| Breeze Features → | AGPL-3.0 (OSI-approved) | Full RMM scope in 64 modules, including patching on Windows, macOS, and Linux, plus ticketing and a built-in AI operator. | Go agent, Hono/TypeScript API, one PostgreSQL database, deployed with Docker Compose. | No device or technician limit and no feature gating. The AI operator runs on your own Anthropic API key. |
MeshCentral
Tactical RMM
NetLock RMM
Breeze
The fair summary: if remote access is the whole job, MeshCentral is mature and has nothing paywalled. Tactical RMM has a long production track record and an active Discord community, and suits teams that want script-driven monitoring and are comfortable running its stack. NetLock RMM fits EU teams that value data sovereignty and fit under its device cap. Breeze is the one to look at when you want the full commercial RMM scope, self-hosted, under an OSI-approved license. Its community is smaller and newer than Tactical RMM's, and its PSA integration ecosystem is narrower than the long-established commercial platforms.
A self-hosted RMM is remote monitoring and management software that you install and run on your own server, rather than using a console the vendor hosts. The agents on your managed devices report to your server, and the data stays in a database you control. The trade is that updates, backups, TLS certificates, and host security become your job.
It depends on the platform. MeshCentral runs on a 1 to 2 GB RAM VPS and handles hundreds of agents. Tactical RMM runs a multi-component stack and needs 4 GB RAM minimum, with 8 GB recommended for production. NetLock RMM needs roughly 2 to 4 GB RAM for its 25-device Community Edition. Breeze runs from a Docker Compose file with a single PostgreSQL database, and a Linux VPS with 4 GB RAM and 2 vCPUs is a reasonable starting point.
It can be, but the responsibility is yours. If your RMM server is compromised, the attacker has administrative access to every managed endpoint, which is why RMM platforms are a target. You own host hardening, TLS, database access, backups, and access logging. The upside of self-hosting an open source RMM is that you can inspect the agent code and, with Breeze, sign agent packages under your own certificate so the trust chain ends at your key.
Yes. Breeze Cloud runs the same platform as the self-hosted Community edition. Migration tooling carries your data, configuration, and device enrollments from self-hosted Community onto Breeze Cloud, with no re-enrollment and no rebuilding your setup.
Not in the OSI sense. Tactical RMM is source-available under its own Tactical RMM License. You can read, self-host, and modify the code, but commercial or hosted resale requires prior written approval from AmidaWare, and derivative works must publish their source. MeshCentral is Apache-2.0, and NetLock RMM and Breeze are AGPL-3.0.
Disclosure: this page is published by Breeze, and Breeze is one of the options on it. We are not neutral. Statements about other projects are drawn from our reviewed comparison pages. Projects change, so check each one's own documentation before you decide, and tell us if something here is out of date.
One Docker Compose file, one PostgreSQL database, no device limit, and no license fee. Or start the Cloud beta and move to self-hosted when the fleet justifies it.
Related reading
Still evaluating Breeze?
Get your questions answered by the team that builds it. 20 minutes, no deck.
Book a call