GUIDE
Open-source MSP software: what to self-host, and what it really costs to run
Open-source tools can take a real line out of an MSP's software bill. They also move work from the vendor to you. This is how to decide which parts of your stack are worth it, and how to count the work honestly before you commit.
Published · MSP Reboot
Check the license before the feature list
“Open source” gets used loosely. For an MSP the license matters more than for most users, because you are not just using the software: you may be running it for clients, and sometimes charging for that.
- OSI-approved licenses (MIT, Apache 2.0, GPL and similar) let you run the software for any purpose, including for paying clients. Copyleft licenses such as the GPL and AGPL add obligations if you modify and distribute or serve the software, so read those clauses if you plan to change the code.
- Source-available licenses publish the code but restrict use. A common restriction is offering the software as a hosted or managed service. Tactical RMM is an example worth knowing: its own license states that it is not an open-source license and that its functionality may not be offered as part of a commercial SaaS service without the licensor’s prior permission.
- “Free tier” products are neither. They can change terms at the next renewal.
None of that makes a source-available tool a bad choice. It means the question “can I host this for clients and bill for it?” has a specific answer in a specific file, and you should read it before the decision rather than after.
Where open source covers an MSP stack
Some categories now have mature open-source options. Others still depend on things a project cannot easily give away, such as a commercial threat-intelligence feed. A realistic map, as of this writing:
| Area | Open-source option | Notes |
|---|---|---|
| Documentation and passwords | ClientSt0r | Multi-tenant documentation, encrypted vault, assets and service desk. Replaces per-technician-seat documentation platforms. |
| Firewalls | OPNsense, managed as a fleet with OPNMGR | OPNsense itself is mature. The gap for MSPs was managing twenty of them, which is what OPNMGR addresses. |
| Virtualization | Proxmox VE, with Depl0y across hosts | Proxmox handles the hypervisor; Depl0y adds multi-cluster views, hardware health over Redfish and templated deployment. |
| Backup | UrBackup, with St0r as the interface | Restores are the test that matters. Budget time to rehearse them, whatever the tool. |
| Remote support | RustDesk, with Rem0te for multi-tenant control | Self-hosting keeps session data on your infrastructure and removes per-technician licensing. |
| PSA / ticketing | ITFlow | An open-source PSA from a separate project. ClientSt0r also covers service-desk ticketing for teams that want one system. |
| RMM | Tactical RMM (source-available) | See the license note above before offering it to clients as a hosted service. |
ClientSt0r, OPNMGR, Depl0y, St0r and Rem0te are MIT-licensed projects written by the developer behind MSP Reboot and documented on MSP Zero. They are listed because they fill the gaps described, not because they are the only options; evaluate them the same way you would anything else.
Where I would still expect to pay
Endpoint detection and response, and any category where a vendor’s detection research is the actual product. You can self-host the plumbing around security, but the signal usually comes from somebody’s paid research team. Email security and vulnerability or exposure management sit in between: open-source engines exist, but running them across many client tenants with reporting is a product in itself.
What self-hosting actually costs
The license fee goes to zero. The work does not. Before comparing against a vendor invoice, write down every recurring task the vendor was doing for you, and put a time on each:
- The server or VM it runs on, and the backups of that server. A documentation platform that is not backed up is a single point of failure holding every client password you have.
- Operating system patching, and application upgrades, including the occasional upgrade that needs a database migration and a maintenance window.
- TLS certificates, DNS, and the reverse proxy in front of it.
- Monitoring the tool itself. If your RMM is down, nothing tells you that your RMM is down.
- Access control: SSO or enforced 2FA, offboarding technicians, audit logs.
- Who gets called when it breaks on a Saturday, and whether that person is you.
Multiply the monthly hours by your loaded technician cost and add hosting. That is the number to compare with the vendor’s price, not zero. For a small team with Linux experience the total is often still far lower than per-seat pricing. For a team without it, the hours can quietly exceed the licence fee they replaced.
Self-hosted or managed
There is a middle option between buying commercial software and running everything yourself: open-source software that someone else hosts and maintains.
| Run it yourself when | Have it managed when |
|---|---|
| Someone on the team is comfortable on Linux, and has the hours. | Nobody on the team wants to own a Linux server. |
| You want to modify the code or integrate it deeply. | You want the cost saving without taking on the operational work. |
| You already run a hardened hosting environment for clients. | An outage of the tool would land on the owner by default. |
If you are not sure whether anyone on the team really has those skills, assess it before you commit rather than finding out during the first failed upgrade. gr0wpath, built by the same developer as this site, assesses technicians against the tools an MSP actually runs, Proxmox VE among them, and trains the gaps it finds.
Managed hosting keeps the main advantages, which are no per-seat billing and data you can take with you, while moving patching, backups and upgrades to someone whose job that is. MSP Reboot provides that for its own open-source tools and for ITFlow; MSP Zero explains what setup and hosting involves, and the products directory lists the hosted options.
Moving over without a cliff edge
- Start from the renewal calendar. Note each contract’s end date and notice period; the migration has to finish before the auto-renewal, not after.
- Export first. Confirm you can get your data out of the current tool in a usable format before you build anything new.
- Run one internal client, usually your own company, on the new tool for a full month, including a restore or an upgrade.
- Move clients in small batches, starting with the simplest. Keep the old system read-only until the last one is across.
- Write down who owns the new system: patching, backups, and the on-call number. If that line is blank, that is your answer to self-hosted versus managed.
Disclosure
MSP Reboot sells consulting and hosting and its developer wrote several of the tools named here. Nothing on this page depends on you using any of them.
Want a second pair of eyes on your own stack?
The first hour is free. Bring your vendor list and renewal dates; we will go through it line by line. Recommending a tool I did not write is a normal outcome.