Fleet operations
AutoRMM
Self-hosted monitoring and remote access for mixed Windows and Linux fleets.
A lightweight RMM built as three dependency-free Go binaries: an always-on hub, outbound agents, and a client for monitoring and short-lived remote sessions.
Simplified public architecture view.
The problem
Why it exists
The machines behind self-hosted products still need patch-day visibility, health data, inventory, and occasional hands-on access.
Full enterprise RMM suites carry assumptions and operational weight that do not fit every private fleet.
- Remote desktop favors normal administrative work, not full-motion video.
- Wayland and multi-display support remain explicit limitations.
Architecture
Operating model
Capabilities
What it does
Security
Trust model
- Agents dial out over one authenticated WebSocket; managed hosts need no inbound port.
- Media sockets use short-lived, session-bound HMAC tickets.
- The server is designed for a private network boundary and treats remote-control tokens as root-equivalent.
Tradeoffs
Key decisions
Three binaries, no runtime stack
Server, agent, and client are static Go binaries so the operational footprint stays understandable.
Remote desktop without a second server
Changed screen tiles flow through the existing agent and relay rather than requiring VNC or RDP on every host.
Current state
Current state
- Linux and Windows telemetry agents
- Browser-based remote desktop relay
- Signed, short-lived session tickets
- CLI and dashboard workflows
- Broader automation primitives
- More capture backends and display support
- Deeper service and inventory views
Lessons
What the work clarified
- Operator confidence comes from transparent sessions and failure states.
- Outbound connectivity removes a surprising amount of deployment friction.
- Honest limitations are part of a trustworthy remote-access tool.