IT Tools calendar_today 2026-03-15 schedule 11 min read

How to Self-Host Your Own RMM in 2026: A Practical Guide

Cloud-based RMM platforms are convenient. They are also expensive, opaque, and entirely outside your control. Every endpoint you manage, every script you push, every remote session you open — it all flows through someone else’s infrastructure. For a lot of IT pros, that trade-off stopped making sense a while ago.

A self-hosted RMM puts you back in the driver’s seat. You own the data. You control the access. You decide when updates happen and what telemetry leaves your network. And in 2026, the open-source options have matured enough that self-hosting is no longer a compromise — it is a legitimate operational choice.

This guide walks you through deploying your own RMM from scratch. We will cover two battle-tested platforms — TacticalRMM and NetLock RMM — along with reverse proxy configuration, security hardening, and agent rollout. By the end, you will have a production-ready RMM running on your own server.

What You Need Before Starting

Before you touch a terminal, sort out your infrastructure. Both TacticalRMM and NetLock RMM are lightweight by server standards, but undersizing will bite you once you start onboarding endpoints.

Server Requirements

For managing up to 200 endpoints, here is what works:

Resource Minimum Recommended
CPU 2 vCPUs 4 vCPUs
RAM 4 GB 8 GB
Storage 40 GB SSD 80 GB SSD
OS Ubuntu 22.04/24.04 LTS Ubuntu 24.04 LTS
Network Static IP, ports 443/4222 open Dedicated subnet

A $20-30/month VPS from Hetzner, Contabo, or OVH handles this comfortably. If you want to spend nothing, Oracle Cloud’s free tier gives you an ARM instance with 24 GB of RAM — more than enough to run either platform.

DNS and Domain Setup

You will need a domain (or subdomain) pointed at your server. Both platforms require valid DNS records for TLS certificates. Plan your subdomains ahead of time:

  • rmm.yourdomain.com — main web interface
  • api.yourdomain.com — API endpoint (TacticalRMM)
  • mesh.yourdomain.com — MeshCentral remote desktop (TacticalRMM)

For NetLock RMM, a single subdomain is sufficient since everything runs behind one entry point.

Prerequisites Checklist

  • A fresh Ubuntu 22.04 or 24.04 LTS server (clean install, no other services)
  • A domain with DNS A records pointing to your server IP
  • SSH access with a non-root sudo user
  • Docker and Docker Compose installed (required for NetLock; optional for TacticalRMM)
  • A valid email address for Let’s Encrypt certificates

Get all of this squared away first. Debugging DNS propagation while halfway through an install is not how you want to spend your evening.

Option 1: Deploying TacticalRMM

TacticalRMM is the most established open-source RMM available today. Built on Django (backend) and Vue.js (frontend), it uses MeshCentral for remote desktop and terminal access. The project has been around since 2020 and has a large, active community. If you want the closest thing to a commercial RMM without paying for one, this is it.

We covered TacticalRMM in depth in our full review. Here, we focus purely on getting it deployed.

Script-Based Installation

TacticalRMM provides an official install script that handles everything: Nginx, PostgreSQL, Redis, NATS, MeshCentral, Certbot, and the application itself. It is opinionated about the stack, which is actually a good thing — fewer variables means fewer things to break.

Start by preparing your server:

sudo apt update && sudo apt upgrade -y
sudo apt install -y curl wget

Download and run the install script:

wget https://raw.githubusercontent.com/amidaware/tacticalrmm/master/install.sh
chmod +x install.sh
sudo ./install.sh

The script will prompt you for:

  • Your three subdomains (rmm, api, mesh)
  • An email address for Let’s Encrypt
  • A username and password for the admin account

The full installation takes 10-15 minutes depending on your server speed. Once complete, you will get a URL for the web interface and credentials to log in.

Post-Install Verification

After the script finishes:

# Check all services are running
sudo systemctl status nats nats-api rmm celery celerybeat meshcentral nginx

Every service should show active (running). If anything failed, check the logs:

sudo journalctl -u rmm --no-pager -n 50
sudo journalctl -u meshcentral --no-pager -n 50

Open your browser and navigate to https://rmm.yourdomain.com. You should see the TacticalRMM login page. Log in with the credentials you set during installation.

Key Configuration Steps

Once logged in, handle these immediately:

  1. Enable 2FA — Go to Settings and enable TOTP-based two-factor authentication for your admin account.
  2. Set up email alerts — Configure SMTP under Global Settings so you get notified on agent check-in failures.
  3. Create your first site and client — TacticalRMM organizes endpoints by Client > Site. Set this up before deploying agents.
  4. Review default policies — Check the automation policies and patch management defaults. Adjust the patch window to match your maintenance schedule.

Option 2: Deploying NetLock RMM with Docker

NetLock RMM is the newer contender in the open-source RMM space. Built on C# with a Blazor frontend, it takes a modern, container-first approach. Everything runs in Docker, which makes deployment cleaner and updates trivial. If you are already comfortable with Docker Compose, NetLock will feel natural.

We reviewed NetLock RMM in detail here. The project also provides an interactive deployment guide at netlockrmm.com/docs that generates a customized Docker Compose file based on your answers — definitely worth using.

Docker Compose Deployment

Make sure Docker and Docker Compose are installed:

sudo apt update && sudo apt install -y docker.io docker-compose-v2
sudo systemctl enable --now docker
sudo usermod -aG docker $USER

Log out and back in for the group change to take effect. Then create your project directory:

mkdir -p /opt/netlockrmm && cd /opt/netlockrmm

Create your docker-compose.yml. Below is a baseline configuration — adjust passwords and domains to match your environment:

version: "3.8"

services:
  netlockrmm:
    image: netlockrmm/server:latest
    container_name: netlockrmm
    restart: unless-stopped
    ports:
      - "443:443"
      - "9100:9100"
    environment:
      - DOMAIN=rmm.yourdomain.com
      - DB_CONNECTION_STRING=Host=db;Database=netlockrmm;Username=netlockrmm;Password=YourStrongDBPassword
      - JWT_SECRET=generate-a-long-random-string-here
    volumes:
      - netlockrmm_data:/app/data
    depends_on:
      - db

  db:
    image: postgres:16-alpine
    container_name: netlockrmm-db
    restart: unless-stopped
    environment:
      - POSTGRES_DB=netlockrmm
      - POSTGRES_USER=netlockrmm
      - POSTGRES_PASSWORD=YourStrongDBPassword
    volumes:
      - netlockrmm_db:/var/lib/postgresql/data

volumes:
  netlockrmm_data:
  netlockrmm_db:

Generate a proper JWT secret:

openssl rand -base64 48

Paste the output into the JWT_SECRET variable. Then bring it up:

docker compose up -d

Check that both containers are running:

docker compose ps
docker compose logs -f netlockrmm

The web interface should be available at https://rmm.yourdomain.com within a minute or two. The first-run wizard will walk you through creating your admin account.

Why Docker Makes Life Easier

The container approach has real operational advantages. Updates are a two-line operation:

docker compose pull
docker compose up -d

Backups are straightforward — dump the Postgres database and tar the data volume. Rolling back means pulling the previous image tag. No dependency conflicts, no scattered config files. For a self-hosted RMM that you need to keep running reliably, this matters.

Setting Up a Reverse Proxy

If you are already running other services on the same server (or plan to), you will want a reverse proxy in front of your RMM. This gives you centralized TLS termination, cleaner routing, and the ability to run multiple services on ports 80/443.

Option A: Traefik (Recommended for Docker)

If you went with NetLock RMM’s Docker setup, Traefik is the natural choice. Add it to your docker-compose.yml:

  traefik:
    image: traefik:v3.3
    container_name: traefik
    restart: unless-stopped
    command:
      - "--providers.docker=true"
      - "--entrypoints.websecure.address=:443"
      - "--certificatesresolvers.letsencrypt.acme.tlschallenge=true"
      - "--certificatesresolvers.letsencrypt.acme.email=you@yourdomain.com"
      - "--certificatesresolvers.letsencrypt.acme.storage=/letsencrypt/acme.json"
    ports:
      - "443:443"
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
      - traefik_certs:/letsencrypt

Then add labels to your RMM container instead of exposing ports directly. Traefik handles routing and certificates automatically.

Option B: Nginx

TacticalRMM already installs and configures Nginx. If you are deploying NetLock and prefer Nginx, a basic config looks like this:

server {
    listen 443 ssl http2;
    server_name rmm.yourdomain.com;

    ssl_certificate /etc/letsencrypt/live/rmm.yourdomain.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/rmm.yourdomain.com/privkey.pem;

    location / {
        proxy_pass https://127.0.0.1:9100;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }
}

WebSocket support (the Upgrade headers) is critical. Both RMMs use WebSockets for real-time agent communication. Without those headers, your agents will connect but commands will silently fail.

Option C: Cloudflare Tunnel

If you do not want to expose any ports on your server, a Cloudflare Tunnel is an excellent alternative. It creates an outbound-only connection from your server to Cloudflare’s edge, so there is no inbound firewall rule needed at all.

cloudflared tunnel create rmm-tunnel
cloudflared tunnel route dns rmm-tunnel rmm.yourdomain.com

Configure ~/.cloudflared/config.yml:

tunnel: rmm-tunnel
credentials-file: /root/.cloudflared/<tunnel-id>.json

ingress:
  - hostname: rmm.yourdomain.com
    service: https://localhost:9100
    originRequest:
      noTLSVerify: true
  - service: http_status:404

Start the tunnel:

cloudflared tunnel run rmm-tunnel

This works particularly well if your server sits behind a NAT or a residential ISP that blocks inbound ports. Just be aware that Cloudflare’s free tier has some WebSocket limitations that may affect real-time features at scale.

Security Hardening Checklist

Running your own RMM means security is entirely your responsibility. An RMM is a high-value target — it has privileged access to every managed endpoint. Treat it accordingly.

Mandatory Steps

  • TLS everywhere. No exceptions. Both platforms support Let’s Encrypt out of the box. If your certificates are not auto-renewing, fix that before doing anything else.
  • Firewall rules. Only expose the ports you need. For TacticalRMM: 443 (web/API), 4222 (NATS agent communication). For NetLock: 443 and 9100. Block everything else with ufw:
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow ssh
sudo ufw allow 443/tcp
sudo ufw allow 4222/tcp  # TacticalRMM only
sudo ufw enable
  • Two-factor authentication. Enable it on every admin account. Both TacticalRMM and NetLock support TOTP (Google Authenticator, Authy, etc.). This is non-negotiable.
  • SSH hardening. Disable password authentication. Use key-based auth only. Change the default SSH port if you want to reduce noise in your logs:
# /etc/ssh/sshd_config
PasswordAuthentication no
PermitRootLogin no
Port 2222
  • Automatic security updates. Enable unattended-upgrades for the OS:
sudo apt install -y unattended-upgrades
sudo dpkg-reconfigure -plow unattended-upgrades

Recommended Steps

  • Fail2ban. Install it and configure jails for SSH and your web interface to block brute-force attempts.
  • Agent certificate pinning. TacticalRMM uses a unique agent token per deployment. NetLock verifies agents against the server’s signing key. Do not disable these mechanisms.
  • Network segmentation. If possible, put your RMM server in a management VLAN, separate from production workloads.
  • Audit logging. Both platforms log admin actions. Review these logs regularly. Ship them to a SIEM if you have one.
  • Backup encryption. Encrypt your database backups before storing them off-server. A leaked RMM backup is a goldmine for attackers.

Deploying Agents to Your Endpoints

With the server running and secured, it is time to roll out agents.

TacticalRMM Agent Deployment

In the TacticalRMM web interface, navigate to Agents > Install Agent. Select the client and site, choose the operating system, and the platform generates a one-liner install command.

For Windows (PowerShell, run as admin):

Invoke-WebRequest -Uri "https://api.yourdomain.com/agents/installer" -OutFile installer.exe
.\installer.exe /VERYSILENT /SUPPRESSMSGBOXES

For Linux:

wget https://api.yourdomain.com/agents/linux -O install.sh
chmod +x install.sh
sudo ./install.sh

TacticalRMM also supports deploying agents via Group Policy, PDQ Deploy, or any other software distribution tool you already use. Export the MSI installer from the web UI and push it through your existing pipeline.

NetLock RMM Agent Deployment

NetLock provides agent packages downloadable from the web interface under Settings > Agent Downloads. The agent is available for Windows, Linux, and macOS.

The general workflow:

  1. Download the agent installer for your target OS.
  2. Copy the server connection string from the NetLock dashboard.
  3. Run the installer with the connection string as a parameter.

For Windows:

.\NetLockAgent.exe install --server "https://rmm.yourdomain.com" --tenant-id "your-tenant-id"

For Linux:

sudo ./netlockagent install --server "https://rmm.yourdomain.com" --tenant-id "your-tenant-id"

Deployment Tips

  • Start small. Deploy to 5-10 machines first. Verify check-ins, remote commands, and remote desktop all work before going wide.
  • Test across network segments. An agent that works on the same LAN as your server might fail from a remote site if a firewall blocks outbound NATS (port 4222) or WebSocket traffic.
  • Automate enrollment. Once validated, bake the agent install into your provisioning scripts, Ansible playbooks, or OS images. Manual agent installs do not scale.
  • Monitor check-in rates. After a mass deployment, watch the dashboard for agents that fail to check in. Common culprits: DNS resolution failures, proxy interference, and antivirus quarantining the agent binary.

Self-Hosted vs Cloud RMM: How to Decide

Self-hosting is not always the right call. Here is an honest breakdown.

Choose Self-Hosted When:

  • Data sovereignty matters. You operate in a regulated industry (healthcare, finance, government) or serve clients who require it. Keeping RMM data on infrastructure you control simplifies compliance.
  • You manage 50+ endpoints. The cost savings become meaningful at this scale. Commercial RMMs charge $2-5 per endpoint per month. At 200 endpoints, that is $400-1,000/month versus $25/month for a VPS.
  • You have the skills. Self-hosting requires Linux administration, networking, and troubleshooting ability. If your team cannot debug a failed certificate renewal at 2 AM, cloud is the safer choice.
  • You want full customization. Self-hosted RMMs let you write custom scripts, build integrations, and modify the platform itself (since both are open source).

Choose Cloud When:

  • You are a small team managing fewer than 50 endpoints. The operational overhead of self-hosting is not worth the savings at this scale.
  • You need guaranteed uptime SLAs. Cloud providers handle redundancy, failover, and disaster recovery. Self-hosting means you are the SLA.
  • You need vendor support. When something breaks in a self-hosted deployment, you are reading GitHub issues and Discord threads. Cloud RMMs have support teams.
  • Speed to deploy matters more than control. A cloud RMM is functional in 15 minutes. A self-hosted deployment is a half-day project minimum.

The middle ground exists too. Some teams self-host their primary RMM but keep a cloud-based backup tool for break-glass scenarios. Others start with cloud and migrate to self-hosted once they outgrow the pricing.

For a broader look at what is available in both camps, check our roundup of the best free RMM tools.

Verdict

Self-hosting your RMM in 2026 is more practical than it has ever been. TacticalRMM gives you a feature-rich, mature platform with a script-based install that handles the entire stack. NetLock RMM offers a modern, Docker-native alternative that is easier to maintain and update. Both are production-grade.

The real question is not whether self-hosted RMM tools are ready — they are. The question is whether you are ready to own the infrastructure. If you have solid Linux skills, a clear backup strategy, and the discipline to keep things patched, self-hosting will save you money and give you control that no cloud vendor can match.

Pick one. Deploy it. Start with a handful of endpoints. Expand from there. The worst that happens is you learn something — and the best is you never pay per-endpoint pricing again.

Related Articles