Running them yourself
All six projects are built to be installed on your own server. Where to start, and an honest account of what you take on by doing it.
Start with one
Pick the tool for the problem you most want solved, read its first-deployment notes, then follow its install guide on a test server. Each one installs on its own.
| Project | What it solves | Runs on | Start here |
|---|---|---|---|
| clientst0r | Client documentation, assets, credentials and tickets in one database. | Ubuntu, Debian, Docker | First-deployment notes Install guide |
| OPNMGR | Watch firewall health, configuration drift, backups and staged updates across customers. | Ubuntu (manager), OPNsense (agent) | First-deployment notes Install guide |
| Depl0y | See Proxmox clusters and the Dell or HPE hardware under them in one place. | Ubuntu, Debian | First-deployment notes Install guide |
| St0r | Endpoint status, file recovery and offsite replication for UrBackup, in one interface. | Ubuntu, Debian | First-deployment notes Install guide |
| rem0te | Customer-separated remote access and an audit trail around your own RustDesk server. | Ubuntu, Debian | First-deployment notes Install guide |
| m0nitor | See where your firewall's traffic goes, what it blocked, and which findings deserve a look — with the evidence. | Ubuntu 24.04 (Docker) | First-deployment notes Install guide |
The notes list each project’s requirements and the things to know before running its installer. Installation commands live in the repositories, where they are kept current.
Not sure which to start with? Read which tool to deploy first, then the operations checklist before anything goes into production.
Five independent projects
Each project installs independently, with its own repository, database and login. There is no single sign-on between them and no management layer over the top.
That is what lets you adopt one without adopting the others, and why a project you stop using takes nothing with it when it goes.
Self-hosting and SaaS
Running software yourself gives you control over where it is deployed, the infrastructure under it, where the data lives, how it is backed up, when it is updated, and how far you customise it or integrate it with the rest of your systems.
SaaS gives you something else: infrastructure somebody else runs, support, updates that arrive without you scheduling them, integrations that are already built, and less operational work on your plate. For a lot of tools that is the right choice, and nothing here argues otherwise. Self-hosting is another option with different trade-offs.
The path
- Choose a project Start with a problem you want to solve rather than trying to replace your whole stack. The table below is arranged that way, and the tool directory has the full description of each project.
- Review the requirements Each project page has a First deployment section: who should start with it, the operating system, the resources the project documents, what it needs to reach, a link to the right install guide, and the limitations to know before running the installer. St0r needs UrBackup Server on the same host, and installs it for you if you have none; rem0te needs a public IP and a domain; Depl0y wants a VM of its own rather than a slot on a Proxmox node. Read that list before provisioning anything.
- Follow the project's installation documentation Install instructions live in the repository and are maintained there. They are not duplicated on this site, because a copy on a marketing page goes stale within a release and then quietly wastes an evening.
- Try one real task Each First deployment section suggests one — enrolling a test firewall, connecting one Proxmox cluster, recovering one file. It tells you quickly whether the tool fits before you roll it out.
- Configure it and keep it running Change the first account’s password, turn on two-factor authentication, restrict what is exposed, and decide how it gets backed up and updated. Then the ordinary work of owning a server starts.
Find the tool for the job
Find the capability you need in the first column and see whether one of these projects covers it.
| Need | Project | What it handles |
|---|---|---|
| Somewhere to keep client documentation, assets and credentials | clientst0r | Organizations, assets, locations, racks, IPAM and a knowledge base, with an AES-GCM credential vault whose reveals are audited. |
| A ticket queue with SLAs, time entries and invoicing | clientst0r | Queues, SLA timers with pause logic, dispatch scheduling, quotes, invoices, contracts and projects — on your database, off by default until you enable it. |
| To know a customer's VPN tunnel or gateway is down before they ring | OPNMGR | Agent health telemetry — gateways, tunnels, CARP, services, certificate expiry — raised as incidents that close when the condition actually clears. |
| To see what changed on a firewall, and roll updates out safely | OPNMGR | Scheduled config backups diffed against an approved baseline, and update campaigns through canary, pilot and production rings. |
| One view over several Proxmox clusters | Depl0y | Each cluster or standalone host registered as its own endpoint, with totals, node health and guest inventory for all of them on one page. |
| iDRAC and iLO health, power and firmware next to the VMs | Depl0y | Dell iDRAC and HPE iLO read over Redfish, plus power on, off and reset through the management controller, which works even when the server is fully off. |
| To answer "did that endpoint back up last night?" in one look | St0r | Every UrBackup endpoint in one table — online state, last file and image backup, quota usage and what needs attention. |
| To get one deleted file back without a restore project | St0r | Pick the day off a calendar of days that have a backup, browse into it and download the file or the folder. |
| To copy the backup store offsite and prove it ran | St0r | Push replication over SSH/rsync with run history, bytes transferred, lag and alerting on failure. Not a substitute for a test restore. |
| Remote support across many customers without per-seat licensing | rem0te | A portal over the open-source RustDesk server: computers grouped by business, credentials released on authorisation, and an audit trail. |
| To let a customer's own staff connect to only their machines | rem0te | Platform Admin, Business Owner and Business User levels, with the business boundary enforced server-side. |
| To see where firewall traffic goes, what was blocked and what looks wrong | m0nitor | NetFlow and syslog from OPNsense turned into per-server bandwidth, a world map, blocked traffic by country and security findings that show their evidence. |
What you are taking on
None of this is unusual, and none of it is a reason not to self-host — you already do all of it for customers. It is just worth costing honestly rather than discovering later.
- Infrastructure. A VM or a host for each project you run, sized to what it asks for, with somewhere sensible for its data to live.
- Exposure and TLS. Some projects terminate TLS themselves, some explicitly do not — St0r's installer serves plain HTTP on port 80 and says so. Decide what is reachable from where, and put a certificate in front of anything that leaves your network.
-
Backups. Each project stores its own state, and
several hold encryption keys without which the stored data is
unreadable. Depl0y's
config.envis the clearest example: back it up with the database, not instead of it. - Updates. Actively developed software moves. Read the changelog, take a backup, then upgrade — in that order.
- Monitoring. Something has to notice when the thing that notices things has stopped.
For a longer treatment of that costing, MSP Reboot has two guides: what to self-host and what it really costs to run, and auditing an MSP software stack before cutting anything.
Every project is MIT licensed. No licence key, no activation, no per-seat or per-device fee for the project itself, and no feature held back for a paid tier. Some of them depend on software under other licences — UrBackup, RustDesk and Proxmox VE are each AGPL-3.0 and are installed and run by you, not redistributed by these projects. Each project page links its own licence file.
Where to ask for help
Bugs and questions go to the project's own GitHub Issues, in the open, whether or not you are a customer of anybody. Each project page links its issue tracker directly.