lexokoh

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.

Try it out at https://privateconnect.co. Also open source https://github.com/treadiehq/private-connect

I didn’t arrive at this idea all at once.

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.

Check out my thoughts.

https://dantelex.com/blog/access-is-the-new-api

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'd love your feedback.

Lol, i'd love to share thoughts on it.

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.

I finally added support for windows and linux

If you open an issue or feature request, could look at it.

Yes, but that's when they fork your repo. But if they are basically are cloning or using it, you mostly don't know who is.

i made an update to specify ports like these. You can check.

A lot of ReadMe's are generated with AI. Doesn't really mean anything.

Nice. I have this too. I wanted something more visual and expansive.

It's just a tool I built for myself. There's no business case. It just helps me

Not sure I can add images here, but if you check the repo, I'll be adding one shortly.

Thank you. Yes, it's one of the things I'm already looking into. So will work well with any Secrets manager, not compete with them.

Curious if you'd want to use it?

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.”

Let me know if that makes sense.

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.

So if i am using a term like "random" in my product i can trademark that? Or maybe my product is called "Random" or "Numbers"

Still, these are random words. For example, "Dev Mode" by Figma is a dev word, and you relate that to development, not Figma.

That isn't very clear. There's also the MySQL one, which is a trademarked technical term.

Fair point. I think Lawyers will say trademark what you can. My question is around the ethics of trademarking random words and restricting others from using it.

We made it OSS so anyone can look through it, as we don't hold the keys anywhere, and it's all local to your project.

I wonder what kind of assurance might be helpful here

I understand this feeling. I think you are a bit lost and need to find a common ground. It's a situation to lead and have straightforward and hard conversations with the cofounder before deciding anything.

I think using a secret manager like https://onboardbase.com solves this easily. .envs are never in the codebase.

We pushed this update recently. You can check it out here.

https://github.com/Onboardbase/kage#cicd-integration

We have this in the doc for local dev already.

So just press enter and continue with that question. You don't have to do anything else.

Please open an issue you might have on the project. Thank you for the feedback.

Done. You can check it out now. Happy contributing

https://github.com/Onboardbase/kage

Awesome. I will look into adding this. There's a community link on the page. So it is easier to give feedback.

This is great. I am happy to collaborate. If you fill out the contact form on the site, I'll contact you to try it out. Or open an issue.

We are working on this for the next release happy to get your feedback on it if it's possible