Atlas AVD and Atlas Reach vs Tactical RMM: Which Belongs in an Azure-First Practice?

By David, 2026-09-05

Tactical RMM has earned its following. It's source-available, it's free to self-host, and it packs a remarkable amount into one install: remote desktop through MeshCentral, remote shells, a file browser, scripting in several languages, checks and alerting, and Windows patch management. For a lot of small MSPs it was the first RMM they could afford to run properly, and plenty still run it every day.

So this isn't a hit piece. It's a specific look at how Tactical RMM and Atlas Reach, the remote support capability built into Atlas AVD, approach the same jobs, and at why a practice that already runs on Azure and Azure Virtual Desktop might not want a separate RMM at all.

The short version: Tactical RMM is a general-purpose RMM: one more server you install, patch, back up and secure (or a hosted plan you pay for), with its own agent, its own console and its own logins. Atlas Reach is remote view and control, a background terminal, installed-software inventory and fleet scripting built into Atlas AVD, the platform you already use to run your clients' Azure environments. It deploys in your own Azure tenant, rides the same agent and the same sign-in, and never bills a unit for an AVD session host in a host pool Atlas has synced. If your practice is Azure-first and you're tired of running a second remote-support stack beside it, Atlas Reach is built for you.

At a glance

The full feature-by-feature comparison is further down, in "The side-by-side".

Where it runs, and who keeps it running

This is the difference everything else follows from.

Tactical RMM is a server you operate. The standard install is a Linux VPS or VM (or Docker) running the Django API, the web front end, the database, a message broker and MeshCentral, with public DNS names and certificates for each. It works well, and the community around it is excellent, but it is one more system that needs OS patches, RMM upgrades, backups, monitoring and a restore plan. If you'd rather not run it, AmidaWare also sells hosted plans, which moves the operations burden and also moves your data onto their infrastructure.

Atlas Reach isn't a separate system at all. Atlas AVD deploys as a single-tenant instance into your own Azure subscription, and Reach is simply a section of it: its own entry in the sidebar, with a Devices page listing every enrolled machine. There's no second server, no second database, no second set of certificates and no second console. Your technicians sign in with the same Microsoft Entra ID account they already use for Atlas, and the same roles and permissions apply.

For an MSP, that changes the maintenance conversation. "We run our own RMM server" is a perfectly good answer until the week it needs a major upgrade. "Remote support is part of the platform we already run, in our own tenant" is a shorter one.

Remote control: built in, and gated to entitled operators

Both products give a technician a live view of the device and control of its mouse and keyboard. The difference is in how that access is built and gated.

Tactical RMM delegates remote desktop to MeshCentral. It's a capable, proven tool, and Tactical integrates it neatly: a "Take Control" button opens a MeshCentral session, and a remote background view gives you a terminal, file browser, services and event log. The trade-off is that MeshCentral is a second product with its own server component, its own agent and its own security surface to keep current.

Atlas Reach is native to the Atlas agent. Click connect on any row of the Devices page and choose view-only or full control. Sessions support multiple monitors (one display or the combined all-displays view), clipboard sync, file transfer, and a policy-controlled consent prompt for devices with a user present. On Windows this is generally available; macOS and Linux are supported too.

And it's built the way remote control should be built:

• Entitled operators only. A session only runs for an authorized, entitled operator, and an admin can switch remote control off for the whole deployment. There is no side door.
• Every session audited. Every view, control and terminal session is written to the Atlas audit trail, so you can always answer "who reached which device, and when?"
• No inbound port. The agent holds an outbound connection on the same authenticated channel it reports telemetry on. Nothing connects inbound to the device.
• Revoke a device, cut it off. The control channel uses the device's own credential, so a revoked device can no longer be reached.
• Or leave it out entirely. A fleet that doesn't want remote control can install the agent telemetry-only, and that install-time choice is one the server can never override.

The background terminal

This is where Tactical RMM is at its strongest: a real-time remote shell without interrupting the user is the tool technicians reach for most.

Atlas Reach has the same capability: open a PowerShell session on the device without disturbing the signed-in user. The difference is the guard rails. The background terminal sits behind its own "Allow Remote Shell" policy, off by default, set per scope, and it can be left out of a device entirely at install time. And the full transcript of every terminal session lands in the audit trail, not just the fact that one was opened. When a client asks exactly what your technician ran on their finance workstation last Tuesday, you can show them.

Scripting and automation

Tactical RMM has a deep scripting story: a community script library, scripts in PowerShell, batch, Python and more, scheduled tasks, and automation policies that apply checks and tasks to groups of agents.

Atlas AVD's Scripts cover the core of that for an Azure estate, on every paid plan from Starter up:

• A script library for saving and reusing PowerShell scripts, with parameters and input variables.
• Run scripts against session hosts immediately, on one host or a whole host pool, via Azure Run Command, with no agent required.
• Push scripts across your fleet on Atlas Reach agents, on demand or on a recurring schedule.
• Real-time output, a per-host run log and execution history.
• Role-based controls on who can run what.

The honest summary: if your automation lives in Python and bash across a mixed fleet, Tactical's language breadth is a real advantage. If your automation is PowerShell against Windows session hosts and endpoints, which is what most Azure practices write, Atlas covers it without a second tool.

Software, patching and monitoring

Tactical RMM handles Windows Update patch management with approval policies, installs software through Chocolatey, and runs checks (disk, CPU, memory, services, event logs, scripts) that raise alerts by email, SMS or webhook.

Atlas AVD approaches the same needs from the Azure side:

• Installed-software inventory. Every enrolled device reports its installed software on enrollment, on boot and daily. Refresh a device on demand, see what was installed, removed or updated over time, and search the whole fleet for a package by name.
• Winget, not Chocolatey. Winget Deployment and the Application Catalog install and version-pin software across session hosts using Windows Package Manager, and give each host pool a baseline so new and reimaged hosts get it automatically. Winget History shows exactly which apps Winget-AutoUpdate patched on every host, from which version to which, and which failed.
• Live health on the Devices page. Enrolled devices report health side by side on one fleet view: session hosts and physical endpoints together.
• Alerting built for AVD. Rule-based alerts across capacity, performance and health, routed to Microsoft Teams, Slack, a webhook or SMS, with severities, suppression windows during maintenance and acknowledgement tracking.

What Tactical RMM can't see

Here's the part a general-purpose RMM can't match. Tactical RMM sees each machine as an agent. It has no idea that a VM is a session host in a host pool, that it's draining for maintenance, that it's running up Azure compute while nobody's logged in, or that its FSLogix profile share is nearly full.

Atlas AVD knows all of that, because it's the platform that runs the environment. The device you just connected to with Atlas Reach is the same session host whose host pool, sessions, autoscale schedule, cost and health score sit one click away. You don't correlate two consoles by hostname; there's one.

Pricing

Tactical RMM is free to self-host with community support. Code-signed Windows agents, the macOS and Linux agents, single sign-on and reporting require a paid sponsorship, priced in bands by endpoint count, and AmidaWare's hosted plans are priced the same way. On top of that, a self-hosted install costs you the server and, more expensively, the time to keep it healthy.

Atlas Reach is metered by device, and the devices an AVD practice has most of are free:

• AVD session hosts never bill a Reach unit. Only an AVD session host is free: any session host in a host pool Atlas has synced, however much Reach is used on it. A session host not yet in your synced inventory is billed like any other managed device until it is. Managing your AVD estate is what your Atlas AVD plan's flat price already buys.
• Every other enrolled device (physical Windows, Mac and Linux endpoints, Azure VMs that are not session hosts such as a jump box or file server, and VMs outside Azure) is one unit per calendar month, and a unit is always $1.
• Units draw first on the pooled monthly unit allowance every plan includes (50 units per tenant on Atlas AVD, at $199 per tenant a month), and you can add more prepaid units whenever you need them. There is no overage bill.

There's no server to buy, no sponsorship to keep current, and unlimited technician seats on every plan. See pricing for the full allowances.

The side-by-side

Already running Tactical RMM? You don't have to rip it out

If Tactical RMM already covers a fleet you're happy with, Atlas can sit alongside it. Atlas AVD's Connections catalog includes a Tactical RMM connector on Enterprise and above, that brings your Tactical agents, alerts, clients and sites into Atlas next to your AVD infrastructure. Many practices start there: Atlas for the Azure estate, Tactical for the rest, then move endpoints onto Atlas Reach as they go.

Still choosing an RMM? Best RMM software for Azure-first MSPs puts Tactical RMM, Atlas Reach, NinjaOne, Datto RMM, ConnectWise Automate, N-able and Kaseya VSA side by side.

How to think about the decision

Ask three questions:

1. How much of your practice runs on Azure and AVD? The more it does, the more you gain from remote support that lives in the same platform as your host pools, and the more you save when every session host in a synced host pool is free.
2. Who's going to keep the RMM server healthy? Tactical's self-hosted model is great value if someone on your team enjoys running it. If nobody does, that's a cost that never shows up on an invoice.
3. What does your security review ask about remote access? Entitled operators only, a deployment-wide off switch, every session and terminal transcript audited, outbound-only agents and one-click revocation are the answers Atlas Reach is designed to give.

The verdict: if you run a mixed fleet with lots of Linux and Mac, script in half a dozen languages, and enjoy operating your own tools, Tactical RMM remains a strong, affordable choice. If your practice is Azure-first and you want remote control, a background terminal, software inventory and fleet scripting inside the platform you already run, in your own tenant, with session hosts free and no second server to maintain, that's exactly what Atlas Reach is.

Feature and pricing details for Tactical RMM are drawn from Tactical RMM's and AmidaWare's public documentation and pricing pages as of September 2026 and summarised in good faith. Confirm current features, sponsorship tiers and hosted options with AmidaWare directly.