Monitoring
Heartbeats plus CPU, memory, disk, and network telemetry from every endpoint, charted live in the dashboard.
Open source · AGPL server · Apache agent
Remote monitoring with a memory.
OpenRMM manages Windows, macOS, and Linux fleets: telemetry, alerting, a real terminal in your browser, scripts, and patching. And it keeps device history on two time axes, so it can answer what was true on a machine and what you believed at the time.
- One static agent binary
- Outbound-only, works behind NAT
- MCP server built in
$ openrmm-agent install --token ore_5f2…
✓ enrolled as web-01 (linux/amd64)
✓ service installed: systemd
✓ connected: wss://rmm.example.com (outbound only)
$ openrmm fleet status
NAME OS CPU MEM DISK SEEN
web-01 linux 12% 38% 61% now
mac-studio macos 4% 52% 47% 2s
win-lab-3 windows 77% 81% 92% 1s ▲ disk
$ What works today
The whole RMM job, self-hosted
One static Go binary on each endpoint, one server you control. No per-seat pricing, no phoning home, no black boxes between you and your machines.
Alerting
Threshold rules with duration windows and cooldowns, heartbeat-miss detection, delivery to email, webhook, ntfy, and gotify with retries.
Browser terminal
A real PTY on any enrolled machine, opened from the dashboard. Every session is recorded as an asciicast you can replay.
Scripts & scheduling
A script library, fleet-wide runs, and cron schedules. Jobs queue durably, so a script sent to a sleeping laptop runs when it wakes.
Inventory
Hardware, installed software, processes, and services, with full history you can rewind to any point in time.
Patch management
Scan, approve, deploy across apt, dnf, pacman, Windows Update, and macOS softwareupdate from one queue.
Agent self-update
Signed updates with automatic rollback if the new binary fails to check in. Service install for systemd, launchd, and Windows SCM.
Audit everything
Shell recordings, script runs, patch approvals, and every MCP call land in an audit log written under the identity that acted.
Bitemporal inventory
Every fact, on two time axes
Most tools store one timestamp and quietly overwrite the past. OpenRMM records when a fact was true on the machine and when the server learned about it. They differ whenever an agent reports late, which is exactly the case that matters after an incident.
Scenarioweb-01 gets patched Tuesday, then goes offline before it can report. The patch report arrives Thursday. Your incident was Wednesday.
"Was web-01 patched during Wednesday's incident?"
GET /devices/web-01/facts?as_of=wed-14:00Yes. Installed Tuesday 09:14. That was the truth on the wire.
"Did we know it was patched when we triaged?"
GET /devices/web-01/facts?knew_at=wed-14:00No. The server still believed the old version. Your Wednesday decisions make sense now.
First-class MCP server
Your fleet, legible to an assistant
OpenRMM ships an MCP server, so an AI assistant can ask real questions about your machines, including history on both time axes, and help act on the answers without ever holding the keys itself.
Read-only by default
Querying the fleet needs no special grants. Anything that changes a machine takes an explicit confirm and returns a dry-run plan without one.
Scoped per API key
Each key carries its own scopes. An assistant that can read inventory cannot run scripts unless you decided it can.
Every call logged
Successful or refused, every MCP call lands in the audit log under the key that made it. Assume someone will read it, because they will.
Which machines still have OpenSSL older than 3.0.12?
list_devices · get_device_facts
3 of 41: web-01, win-lab-3, mac-mini-2. web-01 was patched but hasn't reported since Tuesday, per record time it's still on the old build.
Queue the patch on the other two for tonight.
approve_patches confirm=false
Plan, nothing ran yet
approve openssl-3.0.12 on 2 devices · window 02:00–04:00
Architecture
Boring plumbing, deliberately
A Go agent, NATS for transport, FastAPI and PostgreSQL on the server. Pieces you already know how to run, arranged so the endpoints never have to be reachable.
Endpoints
Windows agent
macOS agent
Linux agent
one static Go binaryTransport
NATS + JetStream
auth callout pins per-agent permissionsServer · AGPL
Dispatcher
FastAPI
PostgreSQL
web dashboard · MCP serverPer-agent credentials
A NATS auth callout issues each agent its own credentials with pinned subject permissions. No agent can see another agent’s traffic, and revoking one is a database update.
Durable job delivery
Jobs queue in JetStream until the target machine is reachable. A script sent to a sleeping laptop runs when it wakes, not never.
Outbound only
Agents dial out over wss:// on 443 through Caddy. Nothing listens on the endpoint, so it works behind NAT, firewalls, and hotel Wi-Fi.
Quick start
Fleet by lunch
Docker, uv, Go 1.22+, and Node 20+ on the server box. The agent side is a single binary and an enrollment token.
1
Bring up the server
git clone https://github.com/openrmm/openrmm && cd openrmm
cp .env.example .env
cd server && uv run openrmm gen-nats-keys # paste both values into .env
cd .. && make dev
make migrate
make admin EMAIL=you@example.com2
Enroll a machine
make enroll-token # prints ore_...
cd agent && go build -o bin/openrmm-agent ./cmd/openrmm-agent
sudo ./bin/openrmm-agent install \
--server https://rmm.example.com --token ore_...Licensing
Genuinely open source
The commercial RMMs are excellent and expensive. The open-source ones are either monitoring-only or carry licenses that stop you building on them. OpenRMM picks a lane and stays in it.
AGPL-3.0
Server
Run it, modify it, offer it as a service. If you improve it and host it for others, those improvements come back. That's the deal, and it's a good one.
Apache-2.0
Agent
Permissive on purpose: the binary that runs on customer machines should be auditable, embeddable, and redistributable without a lawyer in the loop.
DCO
Contributions
Sign-off, not CLA. Your contribution stays yours, the project stays open, and nobody can relicense the commons out from under you.
Two licenses is a deliberate design, not indecision.Read the full reasoning