Self-hosting moves the work, it does not remove it. A vendor used to do the certificates, the backups, the updates and the access reviews; now you do. None of it is hard, but every item below is something I have seen skipped — usually until the day it mattered.
TLS
- Every web interface is served over HTTPS with a certificate that renews on its own, and you know where the renewal runs.
- Plain HTTP is either redirected or not reachable from outside the network.
- Secure-cookie and allowed-host settings are switched on once HTTPS works (St0r’s
COOKIE_SECURE, clientst0r’sALLOWED_HOSTSandDEBUG=False). - Something tells you before a certificate expires, rather than a technician the morning after.
Backups you have restored
- The database is backed up on a schedule, off the machine.
- The encryption key or configuration file is backed up with it. Without it, an encrypted database restores into something you cannot read.
- You have restored the backup to a spare VM at least once and signed in.
- The backup itself is protected: an attacker who owns the server should not be able to delete it.
Updates
- Somebody owns updates for each tool, and the operating system under it.
- You watch the project’s releases (GitHub’s “Watch → Custom → Releases” does it) and read the changelog before upgrading.
- You take a backup immediately before updating, and know how to go back.
- Internet-facing tools are updated first and fastest.
Access control
- The first-run or default administrator password has been changed, and any file that printed it has been deleted.
- Two-factor authentication is on for every administrator.
- Each technician has their own account; nobody shares the admin login.
- Leavers are removed on their last day, and you review accounts each quarter.
- API tokens (Proxmox tokens for Depl0y, for example) are recorded, scoped as tightly as the tool allows, and revoked when unused.
Exposure
- Only what must be reachable from the internet is. Admin interfaces sit behind a VPN or an allow-list where the tool allows it.
- You know which ports each server opens, and you checked them from outside your own network.
- Logs are kept long enough to answer “who signed in, from where” after an incident.
Checking exposure across many customers is its own job. I also build Exploit Hound, a commercial exposure-management product for MSPs; it is separate from MSP Zero, paid, and not needed by any of these tools.
What each tool needs from you
From each project’s own documentation. Commands live in the repositories, where they are kept current.
| Tool | TLS | Back up | First sign-in |
|---|---|---|---|
| clientst0r | Yours: it serves plain HTTP on 8000. Docker has an optional Nginx profile using your certificate. | The MariaDB database and APP_MASTER_KEY. |
A default admin password from the native installer; 2FA is required by default. |
| OPNMGR | Yours: you write the web server configuration; firewalls need HTTPS to the manager. | The database, .env with the master key, and the configuration-backup store. |
No default login: you create the first admin with scripts/create_admin.php. |
| Depl0y | Yours: the panel serves plain HTTP on port 80. | The SQLite database and /etc/depl0y/config.env. |
admin / admin. Change it and enable TOTP straight away. |
| St0r | A certbot step in its installation guide. | Its MariaDB database and .env, and your own backup of /var/urbackup, which it writes to. |
A generated password, printed and saved to a file you should delete. |
| rem0te | Automatic through Caddy and Let’s Encrypt when you install with a domain; a bare IP is plain HTTP. | No backup procedure is documented. I would keep the PostgreSQL database, /etc/reboot-remote/api.env and the RustDesk key pair in /var/lib/rustdesk-server — clients reject a server presenting a different key. |
Printed once by the installer and kept in api.env, readable by root. |
| m0nitor | A Caddy front end in the repository, for the name you set as NETMON_SITE. |
Its encrypted daily backup (host/netmon-backup) covers the SQLite database, configuration and secrets; copy the key and archives off the VM yourself. ClickHouse flow data is not included. |
Users are defined in app/config.yaml during installation. |
How each one updates is on its page, under “Keeping it updated”. rem0te is the one to read first: it is internet-facing, its in-app updater is off by default, and rem0te, the RustDesk server and the RustDesk clients each update separately.