Skip to content


General Information

Option 1: Easy Install on a VPS

Option 2: Install behind NAT Router

Option 3: Installs by Network Wizards

Update Regularly

General Information

Minimum Requirements

A fresh linux VM running either Debian 11 or Ubuntu 20.04 LTS with 4GB RAM on x64 architecture.


The provided install script assumes a fresh server with no software installed on it. Attempting to run it on an existing server with other services will break things and the install will fail.


The install script sets up a production ready reverse proxy using Nginx which does TLS termination and handles routing all requests to the correct backends, so using another proxy in front of your instance is not necessary (and may break things).

If you want to use another reverse proxy for whatever reason, such as HAProxy, Traefik or Nginx Proxy Manager, then you will likely need to edit the install script and disable all the steps relating to installing and configuring nginx and configure reverse proxying yourself. You may refer to the Nginx configs in the install script for hints on how to proxy various services to the correct backends. Note that choosing to not use the built in proxy will make your instance officially "unsupported", because the developers do not have the bandwidth to support an infinite amount of setups and need to focus on the actual software. This is not meant to scare you away from doing your own reverse proxy...just something to be aware of. Check unsupported proxies to see if you need to edit your install script to suit your selected reverse proxy, or if a method that works without doing so has been posted BEFORE you install. Read more in the unsupported guidelines.


The install script has been tested on the following public cloud providers: DigitalOcean, Linode, Vultr, BuyVM (highly recommended), Hetzner, AWS, Google Cloud and Azure, as well as behind NAT on Hyper-V, ESXi and Proxmox (CT's on Proxmox are unsupported, only use VMs).


CPU: 1 core is fine for < 200 agents with limited checks/tasks.

Disk space and speed are dependent on your use case. Of course faster is better SSD/NVMe. Space is dependent on how long you're keeping historical data, and how many checks/script runs and their output size. 50GB should be fine for < 12months of history on < 200 agents with < 30 checks/tasks run at reasonable time intervals.


Enable logging in putty in case you need it later. A good windows SSH client is MobaXTerm. It'll automatically log everything so if you need it later (like install logs because you have a 50x error trying to login after) they'll be easy to grab and share with support. Has integrated SCP client too!

Network Requirements

  • A real (internet resolvable) domain is needed to generate a Let's Encrypt wildcard cert. If you cannot afford to purchase a domain ($12 a year) then you can get one for free at
  • A TOTP based authenticator app. Some popular ones are Google Authenticator, Authy, and Microsoft Authenticator.

Update Recommendations


We highly recommend staying current with updates (do not lag behind more than 1 major version) while Tactical RMM is still working towards its 1.0 release.

Until we reach production release, there may be architectural changes that may be made to Tactical RMM and only a regular patching schedule is supported by developers.

Option 1: Easy Install on a VPS

Install on a VPS: DigitalOcean, Linode, Vultr, BuyVM (highly recommended), Hetzner, AWS, Google Cloud and Azure to name a few.

Use something that meets minimum specs

Step 1 - Run Updates on OS

SSH into the server as root.

Install the pre-reqs and apply the latest updates:

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

If a new kernel is installed, reboot the server with the reboot command.

Step 2 - Create a Linux user

Create a linux user named tactical to run the rmm and add it to the sudoers group.

useradd -m -G sudo -s /bin/bash tactical
passwd tactical


Skip this step if your VM is not publicly exposed to the world e.g. running behind NAT. You should setup the firewall rules in your router instead (ports 22 and 443 TCP).

ufw default deny incoming
ufw default allow outgoing
ufw allow https


SSH (port 22 tcp) is only required for you to remotely login and do basic linux server administration for your rmm. It is not needed for any agent communication.

SSH Firewall Rule

Allow ssh from only allowed IP's (highly recommended)

ufw allow proto tcp from X.X.X.X to any port 22
ufw allow proto tcp from X.X.X.X to any port 22

Allow ssh from everywhere (not recommended)

ufw allow ssh

Enable and activate the firewall:

ufw enable && ufw reload


You will never login to the server again as root again unless something has gone horribly wrong, and you're working with the developers.

Step 4 - Create the A records


All 3 domain names have to be at the same subdomain level because you only get one LetsEncrypt wildcard cert, and it'll only apply to that level of DNS name.

We'll be using as our domain for this example.


The RMM uses 3 different sites. The Vue frontend e.g. which is where you'll be accessing your RMM from the browser, the REST backend e.g. and MeshCentral e.g.

  1. Get the public IP of your server with curl
  2. Open the DNS manager of wherever the domain you purchased is hosted.
  3. Create 3 A records: rmm, api and mesh and point them to the public IP of your server:


Step 5 - Run the install script

Switch to the tactical user:

su - tactical


If you can snapshot do that now so you can quickly restore to this point again and re-run the install in case something goes wrong with the install script.

Download and run the install script:

chmod +x

Answer the initial questions when prompted. Replace with your domain.


Step 6 - Deploy the TXT record in your DNS manager for Let's Encrypt wildcard certs


TXT records can take anywhere from 1 minute to a few hours to propagate depending on your DNS provider.
You should verify the TXT record has been deployed first before pressing Enter.
A quick way to check is with the following command:
dig -t txt
or test using: Enter:



Create a login for the RMM web UI:


A bunch of URLS / usernames / passwords will be printed out at the end of the install script. Save these somewhere safe. Recover them if you didn't

Step 7 - Login

Navigate to and login with the username/password you created during install.

Once logged in, you will be redirected to the initial setup page.

Create your first client/site and choose the default timezone.

You're Done

Update Regularly

Option 2: Install Behind NAT Router

Install in your local network using: Dedicated hardware, Hyper-V, Proxmox or ESXi. All been tested and work fine.

Do everything from Option 1: Easy Install

If You Only Have Agents on the Private Network / Subnet

Make sure your local DNS server (or agents hosts file) have your Tactical RMM server IP addresses for the 3 domain names: rmm, api and mesh

Agents Exist Outside the Private Network / Subnet - Setup Port Forwarding

If you have agents outside your local network: Make sure the public DNS servers have A records for the 3 Tactical RMM server domain names: rmm, api and mesh

Login to your router / NAT device.

  1. Set your TRMM server as a static IP (Using a DHCP reservation is usually safer).
  2. Port forward TCP 443 to your TRMM servers private IP address.

Note can help with Port Forwarding setup

You're Done

Update Regularly

Option 3: Installs by Network Wizards

Use the scripts above.


  1. TLD domain name which is internet resolvable (this is for a LetsEncrypt DNS wildcard request during the install script validated by DNS txt record).
  2. Agents need to be able to connect to your server via DNS lookup (hosts file, local DNS, smoke signals etc.).
    • Test from agent: ping Should result in the IP of your Tactical RMM server.
    • Test from agent: ping Should result in the IP of your Tactical RMM server.
    • Test from agent: ping Should result in the IP of your Tactical RMM server.


Did you notice #2 doesn't need to be something publicly available?

That's it. You're a wizard, you know how to satisfy these 2 items.

You'll probably enjoy browsing thru the Unsupported section of the docs.

Update Regularly

We've said it before, we'll say it again.

  • We recommend regular updates.

    • Every 2-3 months.

      • Do it when you update your SSL certs.

Especially don't get behind 2 major rev's. Lots of agent connectivity changes occurring. If you don't keep up, you'll be needing to do manual updates by adjusting the and specifying older branches...then doing update, wait for all agents to get updated...then do the next major branch, then wait for agent updates...until you're current. Can we say #Painful.

AWS Install Video Walkthrus