I built this because I was tired of juggling VPN configs, SSH tunnels, and random IPs just to access things like a staging database or a dev API.
Private Connect lets you access private services by name from anywhere, without setting up a VPN, opening firewall rules, or running SSH tunnels.
You expose a single service, get a short-lived connect link, and access exactly that service, nothing else on the network.
This isn’t meant to replace VPNs or zero-trust platforms. It’s for the everyday “can you quickly check this?” and debugging cases where full network access is overkill.
Built this for myself first and decided to share it. Curious where this feels unnecessary, risky, or where you’d prefer existing tools.
It crept up slowly, through small frustrations, awkward workarounds, and moments where I caught myself thinking this feels wrong, but it’s the only way.
Over time, a pattern became hard to ignore:
We’ve gotten incredibly good at designing APIs, but we’ve barely designed access at all.
And now access is starting to behave exactly like an API, whether we intended it to or not.
I’m writing this because I kept running into access decisions that felt small in the moment, but kept shaping systems in ways I didn’t expect, and I didn’t have a good mental model for why.
I'm building Echos(https://github.com/treadiehq/echos), a platform that gives you pre-built AI agents so you can stop rebuilding orchestrators, database agents, and retry logic every time.
Sort of built this because every time I build a multi-agent system, I spend 2-3 weeks creating the same infrastructure: orchestrators that route tasks, database agents with SQL guardrails, retry logic, loop limiting, and cost tracking. Then another week of debugging when things break. I wanted to ship features, not plumbing.
Most frameworks are bulky and complex. You just want pre-built components you can compose like AWS services.
I’ve been experimenting with AI agents lately, and one problem kept coming up: they either get a raw API key with full access or nothing at all. That’s risky, especially if you’re testing agents that can make arbitrary calls.
So I hacked this together.
It lets you wrap agent actions with scoped, short-lived tokens instead of handing over your real API keys.
Right now it:
- Generates scoped, expiring tokens (default 10s)
- Logs every action to kage-keys.log
- Works as a drop-in wrapper for async functions
It’s just an MVP (tokens are fake UUIDs), but I want to see if developers find this helpful before building the production version with real crypto + proxy enforcement.
Thank you. Instead of giving the agent your real API key, it gets a scoped, short-lived capability (e.g. “can post 1 message to Slack channel X in the next 30s”).
The short-lived nature means that if the token is leaked or the agent goes rogue, the blast radius is tiny, you can instantly revoke/deny new mints, and you get full audit and policy control. It turns “here’s my permanent master key” into “here’s a disposable permit slip for just this action.”
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.
I've been building enterprise tools for some time now, and it was shocking to see that nothing properly helps you license self-hosted tools. So you have to build something, maybe internally, to help you with this, but this quickly gets complicated with the volume of things, and you then need to have a team manage this fully.
I've had to build a version of this before for an on-prem version of our software at some companies I've worked with.
There's a bunch of bullshit you have to go through with each company's procurement/security team. Setting allow lists for IP addresses, ports, update frequencies, whether or not they want automatic updates, and the allowed telemetry.
I don't know, and maybe it's just me who's a bit frustrated by this. So, how do you license your on-prem, open-source, or self-hosted version of your software to enterprise teams or teams in general? Are there any tools you use? What are your best practices?
Due to my personal frustration, I decided to attempt building something seamless that fits what I need. Paywall - License - Deploy. THE END
I called it Kage (https://kagehq.com). I would love your thoughts and feedback. I genuinely want to learn what people are doing or using.
Private Connect lets you access private services by name from anywhere, without setting up a VPN, opening firewall rules, or running SSH tunnels.
You expose a single service, get a short-lived connect link, and access exactly that service, nothing else on the network.
This isn’t meant to replace VPNs or zero-trust platforms. It’s for the everyday “can you quickly check this?” and debugging cases where full network access is overkill.
Built this for myself first and decided to share it. Curious where this feels unnecessary, risky, or where you’d prefer existing tools.
Try it out at https://privateconnect.co. Also open source https://github.com/treadiehq/private-connect