Why I build self-hosted software
12 Jun 2026
Nexus could have been a SaaS — a signup form, a hosted dashboard, a monthly bill. It ships as Docker images you run yourself instead, and that was a deliberate choice, not a shortcut.
The data argument
A support wallboard sees everything: queue names, ticket subjects, agent names, caller numbers. My day job is securing exactly this kind of data, and the easiest data to secure is the data that never leaves the customer's network. Self-hosted means the Zendesk tokens, the live call state, all of it stays inside their perimeter. There's nothing of theirs for me to breach.
The trust argument
IT teams are the buyers, and IT teams are (rightly) suspicious. "It runs on your box, audit the container" is a much shorter security-review conversation than a vendor questionnaire about my hosting. It also means the product keeps working when I'm on holiday, when my host has an outage, or — worst case — if I stop maintaining it.
What it costs
Self-hosting isn't free for the developer. You inherit problems SaaS never has:
- Licensing without a licence server — licences are signed and verified offline, and renew themselves without phoning home on every check.
- Upgrades you don't control — every migration has to be forward-safe, because you can't fix a customer's database from your side.
- Support at a distance — diagnostics have to be built in, because you can't SSH into the problem.
Each of those made the product better. Constraints that force you to build for someone else's machine force a kind of rigour that "we'll just fix it in prod" never does.