←back to thread

354 points geoctl | 2 comments | | HN request time: 0.66s | source

I have been working on Octelium for quite a few years now but it was open sourced only by late May 2025. Octelium, as described more in detail in the repo's README, is simply an open source, self-hosted, unified platform for zero trust resource access that is primarily meant to be a modern alternative to corporate VPNs and remote access tools. It can operate as a remote access/corporate VPN (i.e. alternative to Twingate, Tailscale, OpenVPN Access Server, etc...), a ZTNA/BeyondCorp platform (i.e. alterntive to Cloudflare Access, Teleport, Google BeyondCorp, etc...), and it can also operate as an API/AI gateway, an infrastructure for MCP and A2A architectures and meshes, an ngrok alternative, a homelab infrastructure or even as a more advanced Kubernetes ingress. It's basically designed to operate like a unified Kubernetes-like scalable architecture for zero trust secure/remote access that's suitable for different human-to-workload and workload-to-workload environments. You can read more in detail the full set of main features and links about how it works in the repo's README or directly in the docs https://octelium.com/docs
Show context
wkat4242 ◴[] No.44415156[source]
There are so so many of these already...

- Tinc (the OG of P2P VPN)

- Hamachi (not open though)

- ZeroTier

- Nebula (from Slack)

- Tailscale

- Netbird

I wonder why people keep building more. I know each has its own quirks and things they're better at, but the difference is really quite minimal.

One of the things I really would like is zero-trust 'lighthouses'. With current Zerotier and Tailscale, you really have to trust them because they can add nodes on your account whenever they want. I don't want that, I want fully self-hosted and for the lighthouses to just coordinate but not to be part of the network. I have to do some research to see what would be best.

replies(5): >>44415207 #>>44415277 #>>44415706 #>>44416114 #>>44422509 #
metmac ◴[] No.44415706[source]
Reading through the docs. I feel like a lot of people are missing the value here. This could be a diamond in the rough if it actually delivers on its docs.

What enterprises want is to move away from perimeter based security models towards the promise that Google überProxy/BeyondCorp popularized many years ago. Which has been lost in the buzzword soup. It’s very simple.

1. A clean separation between Prod, Corp, and the public internet. And the UX to hop between them as an employee is as transparent as possible. (Often times network segmentation comes with additional painful friction for engineerings.)

2. One pipe to observe, and clearly attenuate permissions as traffic/messages flows between these boundaries.

3. Strong proofing of identity for every client, as an inherit requirement.

The problem is everyone outside Google has incredibly diverse protocol ecosystems. It makes those three promises incredibly difficult to deliver on as a vendor. (I’ve evaluated many)

To build a proxy that is protocol aware, only solves half the problem. It gets you some coarse grain decision making and a good logging story.

To build a proxy that is also able to perform type-inference at the request layer, allows for a much richer authZ story. One where businesses can build an authorization layer at the proxy better than their in-house apps could even do natively. (As it turns out, having all the predicates of the request available to a policy engine is super useful).

The docs are a little verbose, the marketing maybe isn’t amazing. But this is inherently a complex problem. No one has fully solved.

Teleport was first to the market to OSS and commercialize a lot of these ideas. StrongDM also is doing really interesting work in this space. I wish Hashicorp had invested more in this space.

Disclaimer: my opinions are my own.

replies(2): >>44416388 #>>44417565 #
geoctl ◴[] No.44416388[source]
Thank you really for your comment. I was actually hoping myself to get more questions that are related to the internals and architecture of Octelium, especially from those who are familiar with commercial ZTAs such as Cloudflare Access, Teleport, StrongDM, Google BeyondCorp, Pomerium and many other ZTNA/BeyondCorp based solutions.
replies(1): >>44418083 #
1. metmac ◴[] No.44418083[source]
Will DM after I’ve had a chance to dig.
replies(1): >>44418128 #
2. geoctl ◴[] No.44418128[source]
Happy to answer any questions regarding Octelium internals/architecture or regarding the project overall whenever you need to. You can find the project's Slack/Discord channels and contact emails in the repo's README or on the website.