The MSP Zero tools install independently, so there is no right order — only a first one that is more or less likely to stick. I would pick it with two questions: which problem costs you time this week, and how much does the tool reach into if it goes wrong or you change your mind?
1. Start from the problem, not the product
Write down the one job you would most like to stop doing by hand. Then match it to the tool that does that job:
- Client documentation, credentials or tickets scattered across tools → clientst0r
- Finding out an OPNsense tunnel or gateway is down because a customer rang → OPNMGR
- Several Proxmox clusters, with iDRAC or iLO checked separately → Depl0y
- Not being able to answer “did that endpoint back up last night?” in UrBackup → St0r
- Remote support across customers on a server you control → rem0te
- Not knowing where your firewall’s traffic goes or what it blocked → m0nitor (pre-release)
If none of those is a real problem for you, none of these tools is your first one, and that is a fine answer.
2. Compare what each one reaches into
A first deployment should be easy to reverse. These columns are the ones I would weigh: what the tool touches, and what happens if you stop it.
| Tool | What it touches | If you stop it |
|---|---|---|
| St0r | The UrBackup host: it adds Node.js, MariaDB and Nginx, takes over Nginx’s default site, and writes to UrBackup’s databases. | UrBackup carries on backing up exactly as before; the project says so explicitly. |
| Depl0y | Its own VM, plus a Proxmox API token per cluster. The token’s privilege separation is disabled, so it carries its owner’s full rights. | Proxmox is unaffected; Depl0y is an additional console. Revoke the tokens you created for it. |
| OPNMGR | A PHP application you install by hand, and an agent run as root on every firewall you enrol. | The firewalls keep their configuration; you lose the monitoring, scheduled backups and update campaigns. |
| rem0te | An internet-facing server that hands remote-access credentials to technicians, plus enrolment on each computer. | Connect, enrolment and the audit trail stop; technicians fall back to whatever they used before. |
| clientst0r | Becomes the system of record for client documentation and credentials, and tickets if you enable the service desk. | Everything you put in it is in its database. Leaving later is a migration of your own. |
| m0nitor | Its own Docker VM. The firewall only sends it NetFlow and syslog; an API user is optional, needed for blocking and the live GeoIP policy. | Traffic is unaffected: it is never in the forwarding path. Remove the NetFlow destination and syslog target from the firewall. |
3. If you are unsure, start small
If you already run UrBackup, St0r is the smallest first commitment: it sits on top of a backup engine that keeps working without it, so trying it costs an afternoon and is undone by stopping a service. One thing to know first, on its page: do not install it on a machine that already serves web content, because its installer takes over Nginx’s default site.
clientst0r is the opposite case. It is the tool with the most to gain and the most to move — read the documentation migration checklist before putting real client data in it.
4. Run it like production from day one
Whichever you choose, free software still needs a server, a certificate, backups you have restored at least once, and somebody who applies updates. The operations checklist covers that for each tool, and each tool page lists its own requirements and “know before you deploy” notes.
What none of them does
MSP Zero covers six jobs. It is not an RMM, it does no patching, it does not filter email, and it does not watch your customers’ external attack surface. If you need those, you need other products — open source or commercial.
Two commercial products I also build cover two of those gaps: MailThreatZero (commercial email security for MSPs) and Exploit Hound (commercial exposure management). They are separate paid products, not part of MSP Zero, and no MSP Zero tool needs either of them.