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!
- 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 freenom.com
- example.local is NOT a real domain. No, you don't have to expose your server to the internet
- A TOTP based authenticator app. Some popular ones are Google Authenticator, Authy, and Microsoft Authenticator.
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
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
Step 3 - Setup the firewall (optional but highly recommended)¶
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
example.com as our domain for this example.
The RMM uses 3 different sites. The Vue frontend e.g.
rmm.example.com which is where you'll be accessing your RMM from the browser, the REST backend e.g.
api.example.com and MeshCentral e.g.
- Get the public IP of your server with
- Open the DNS manager of wherever the domain you purchased is hosted.
- Create 3 A records:
meshand point them to the public IP of your server:
Step 5 - Run the install script¶
Switch to the
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:
wget https://raw.githubusercontent.com/amidaware/tacticalrmm/master/install.sh chmod +x install.sh ./install.sh
Answer the initial questions when prompted. Replace
example.com 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 _acme-challenge.example.com
or test using: https://viewdns.info/dnsrecord/ 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¶
https://rmm.example.com 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.
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:
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:
Login to your router / NAT device.
- Set your TRMM server as a static IP (Using a DHCP reservation is usually safer).
- Port forward
TCP 443to your TRMM servers private IP address.
https://portforward.com/ can help with Port Forwarding setup
Option 3: Installs by Network Wizards¶
Use the scripts above.
- TLD domain name which is internet resolvable (this is for a LetsEncrypt DNS wildcard request during the install script validated by DNS txt record).
- Agents need to be able to connect to your server via DNS lookup (hosts file, local DNS, smoke signals etc.).
- Test from agent:
ping rmm.example.com. Should result in the IP of your Tactical RMM server.
- Test from agent:
ping api.example.com. Should result in the IP of your Tactical RMM server.
- Test from agent:
ping mesh.example.com. Should result in the IP of your Tactical RMM server.
- Test from agent:
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.
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
updates.sh 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.