Ask HN: How do you handle licensing and revenue leaks for self-hosted software?
I’ve been exploring the hidden costs of self-hosted software, specifically, the silent revenue leaks that come from unauthorized deployments, lingering trials, and unmonitored usage.
Most devs I spoke to shared stories of enterprise clients spinning up “temporary” instances that ran for months, or trials that never actually ended. If you’re selling self-hosted, how are you tackling this?
I wrote up my findings and what can be done about it here:
https://kagehq.com/blog/hidden-revenue-leak-self-hosted-software
Would love to hear how the HN community is handling this.
By making the software FOSS and charging for support instead of usage. Definitely not with DRM that could leave you legally liable for disrupting a company's entire operations when an inevitable false positive happens.
Thank you for the thoughtful pushback. This is exactly the kind of discussion I was hoping for.
I totally agree that FOSS + support can be a great model in the right context. We’re definitely not trying to reinvent DRM or lock users out of their own systems without recourse.
Here’s how we think about it:
Many developers building self-hosted tools try to monetize in good faith, especially when selling to large enterprises. But they often lose control over renewals, never-ending trials, and multiple unlicensed deployments. The current model: Send a zip or Docker file and hope, just doesn’t scale.
Kage isn’t about locking software down. It’s about helping developers protect and grow the value of what they’ve built, without needing to write custom scripts or chase invoices. Think of it more like Stripe or Terraform Cloud for licensing and compliance, not DRM or spyware.
That said, false positives are a real risk, and we’ve designed Kage to be graceful by default:
- Licenses include grace periods, pre-expiration alerts, and non-blocking modes.
- You can configure what happens when a license expires from “notify only” to “disable premium features” or “shut down in sandbox environments.”
- It’s all transparent and developer-controllable.
We’re also open-sourcing key parts of the platform (CLI tools, SDKs, deployment templates) to make it auditable and community-driven. Our goal is to give developers more tools, not take control away from users.
Would love to hear more about what a fair and developer-friendly enforcement system looks like to you (or others here). We’re building this for developers first, and that means getting it right.