Tactical RMM: a self-hosted RMM for Windows, Linux and Mac agents

What Tactical RMM solves, and for whom

The project describes itself as a remote monitoring and management tool built with Django and Vue. The problem it addresses is the one an internal IT team hits when it has more machines than patience: keeping an eye on CPU, disk and memory, running scripts on a schedule, applying Windows patches, and reaching a machine's shell or registry without walking to it. The README lists those as features rather than aspirations, and the repository layout backs that up with an api/ directory for the Django side, a natsapi/ directory, and a Go entry point at main.go. The intended user is an administrator who is willing to run the control plane themselves. That is the dividing line. A hosted RMM sells you an account and an agent; Tactical RMM sells you nothing and hands you install.sh, update.sh, backup.sh and restore.sh, which means the server, its database and its certificates are your responsibility. The README points to docs.tacticalrmm.com for installation, backup, restore and usage, and that documentation is where the operational detail actually lives.

How the Django server, the Go agent and MeshCentral fit together

Three components are visible from the repository. The server is Django and Vue, with a REST API under api/ and a separate natsapi/ directory. The agent is a Go program maintained in a different repository, amidaware/rmmagent, and the README states it integrates with MeshCentral for remote desktop control. The go.mod file shows what the server-side Go code depends on: nats.go for messaging, lib/pq for PostgreSQL, sqlx for queries, and ugorji/go/codec. NATS is the interesting one. It implies the agent does not poll a REST endpoint for every instruction; instead the server publishes commands over a message bus and the agent subscribes. That design is what makes a real-time remote shell and a live file browser plausible, because the round trip does not wait on a scheduled check-in interval. MeshCentral sits alongside that for the TeamViewer-like desktop session, which the project does not reimplement. The practical consequence is that a Tactical RMM deployment is not one process. It is a Django application, a PostgreSQL database, a NATS server and a MeshCentral instance, and the documentation is the only place that spells out how they are wired together.

Installing Tactical RMM and running a first script

The README does not reproduce install steps. It says to refer to the documentation, and the repository ships install.sh at the top level, which is the entry point the documentation describes for a server install. Because the README gives no flags, none are shown here.

./install.sh

Run that on the Linux host that will act as the server, following the prerequisites in the documentation rather than guessing them. After the server is up, agents are enrolled from the web interface, and the agent installer comes from the rmmagent repository rather than from this one.

Once an agent checks in, the workflow the README describes is script execution. Scripts are uploaded through the interface and then run either on demand or on a schedule through the automated task runner. The supported languages listed are batch, PowerShell, Python, nushell and deno, so a script is not limited to shell one-liners. The same interface exposes remote command execution, a file browser, a registry editor, an event log viewer and services management for the machines in the fleet.

Keeping the server current is a separate script, not a package manager upgrade.

./update.sh

The repository also ships backup.sh, restore.sh and troubleshoot_server.sh, which tells you the maintainers expect self-hosted operators to handle their own database backups and recovery.

Where Tactical RMM is the wrong tool

The most concrete limitation is licensing by platform. Mac and Linux agents, code-signed Windows agents, the reporting module and single sign-on are listed under Sponsorship Features, not under the general feature list. A team that assumes it can enrol a mixed fleet for free will discover the boundary after deployment, not before. The README is explicit about the split, and it is the first thing to check against your environment.

The second limitation is operational weight. Nothing here is a single binary you drop on a VPS and forget. The stack includes Django, PostgreSQL, NATS and MeshCentral, and the presence of troubleshoot_server.sh in the repository root is a fair signal that server-side problems are expected to happen and are expected to be diagnosed by the operator. If you do not have someone who can read logs on a Linux server, the free licence is not the saving you think it is.

The third is scope. This is an RMM, not a general observability platform. The automated checks cover CPU, disk, memory, services, scripts and event logs with email, SMS or webhook alerting. There is no mention of distributed tracing, log aggregation pipelines or metric retention policies, so using it as a replacement for a monitoring system with long-term time-series storage would be a category error.

Tactical RMM compared with MeshCentral and Zabbix

The comparison people reach for first is MeshCentral, and it is an odd one because Tactical RMM integrates with MeshCentral rather than replacing it. MeshCentral is a remote management and desktop control server; Tactical RMM wraps that capability inside a larger RMM product with scripting, patch management, inventory and alerting. If all you need is remote desktop and file transfer, MeshCentral alone is a smaller thing to operate. If you need scheduled PowerShell against a fleet and a patch workflow, Tactical RMM is the layer that adds it, and you end up running MeshCentral underneath anyway.

Zabbix is the other comparison, and the difference is in what is being measured. Zabbix is built around metrics, items, triggers and long retention of numeric history. Tactical RMM is built around the machine as an administrative object: run this script, install this package via chocolatey, open this registry key, apply this patch. Zabbix will tell you a disk is filling over six months. Tactical RMM will tell you a service stopped and then let you restart it from the same console. Teams that need both usually run both, and the integration cost is real because they do not share a data model.

Maintenance, releases and what the licence leaves open

The repository is not archived, and the last push was on 2026-09-17. Releases are frequent enough to plan around: v1.5.0 and v1.5.1 landed on 2026-06-15 and 2026-06-16, and v1.5.2 on 2026-08-11. The default branch is develop, not main, which is worth noting if you build from source or track a branch: the stable artefacts are the tagged releases, and the develop branch is where work lands first. Upgrades are performed with update.sh rather than a package manager, so the cost of staying current is a maintenance window and a working backup, not an unattended auto-update.

The licence field on the repository is NOASSERTION, which means GitHub could not classify it automatically. The repository does contain LICENSE.md, and that file, not this article, is what governs your use. Read it directly, particularly if you plan to resell access to the server or embed the agent in a product. The README's separation of sponsorship features is a product decision rather than a licence term, so the two documents answer different questions and you need both.

Editorial conclusion

Adopt Tactical RMM if you want remote shell, script execution, patch management and inventory on infrastructure you own, and you accept that Mac and Linux agents along with code-signed Windows agents come through sponsorship. Do not adopt it if you need a vendor-hosted service with an SLA, or if you cannot run a persistent Linux server. Before deploying, verify the install.sh prerequisites in the documentation, confirm which agent platforms your licence tier covers, and read the update.sh and restore.sh scripts so recovery is not improvised during an incident.

Frequently asked questions

Official sources

1. amidaware/tacticalrmm on GitHub
2. Issues
3. Project website
4. README
5. Releases