←back to thread

Show HN: Octelium – FOSS Alternative to Teleport, Cloudflare, Tailscale, Ngrok

(github.com)
354 points geoctl | 4 comments | 29 Jun 25 11:24 UTC | HN request time: 0.001s | 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
mzhaase ◴[29 Jun 25 13:29 UTC] No.44412985[source]▶
I have an immediate complete distrust to anything that throws around so many buzzwords. This is the github page and I still don't understand what it even does, specifically.
replies(2): >>44413008 #>>44422505 #
geoctl ◴[29 Jun 25 13:32 UTC] No.44413008[source]▶
I'd appreciate if you could provide me a list of those buzzwords so that I can improve the readme.
replies(2): >>44413082 #>>44419094 #
drexlspivey ◴[29 Jun 25 13:41 UTC] No.44413082[source]▶
“A next-gen FOSS self-hosted unified zero trust secure access platform that can operate as a remote access VPN, a ZTNA/BeyondCorp architecture, API/AI gateway, a PaaS, an infrastructure for MCP & A2A architectures or even as an ngrok-alternative and a homelab infrastructure.”

Literally every single word of it

replies(3): >>44413175 #>>44413672 #>>44414104 #
geoctl ◴[29 Jun 25 13:53 UTC] No.44413175[source]▶
I admit that the "next-gen" word might sound cheesy. As I said in the other reply, the more correct definition for Octelium is: a unified zero trust secure access platform. However, as I said this is a term that nobody would relate to. It's a ZTNA/BeyondCorp platform but not in the rigid sense. It's also a WireGuard/QUIC-based remote access VPN but it operates at layer-7 to provide L7 aware access control, secretless access, dynamic configuration and routing as well as OpenTelemtry-native visibility and auditing via identity-aware proxies and policy-decision-points instead of just controlling access at layer-3. As I said, it's designed to be more like a generic Kubernetes-like architecture for secure remote access that can be used for many different use cases.
replies(4): >>44413290 #>>44413299 #>>44413349 #>>44420916 #
maxmcd ◴[29 Jun 25 14:09 UTC] No.44413299[source]▶
I think "no buzzwords" would be further in the direction of:

"This software let's you set up peer to peer networking between your devices, expose them to the internet, run applications on them, view useful runtime information, and integrate easily with cloud providers and infrastructure you're familiar with."

replies(1): >>44413500 #
geoctl ◴[29 Jun 25 14:35 UTC] No.44413500[source]▶
Thank you. Octelium, however, does not operate as p2p and does not directly connect devices since that by itself contradicts the whole point of zero trust. It provides remote access to resources, or even sub-resources via L7 access control (e.g. allow access to some HTTP paths to some users based on identity/context/request content, etc...), not completely to "devices" or to complete subnets.
replies(1): >>44414382 #
dudeinjapan ◴[29 Jun 25 16:38 UTC] No.44414382[source]▶
How about: “Octelium is a secure, policy-based access gateway to your HTTP services, with both VPN tunnel-based and OAuth/zero-trust modes available. (And it can do a lot more!)”
replies(1): >>44414596 #
geoctl ◴[29 Jun 25 17:03 UTC] No.44414596[source]▶
Thank you. I think your description is great but I, as a user myself, might see it as an identity-aware proxy (i.e. something like Pomerium and Ory Oathkeeper IaPs which are great projects) as opposed to a complete Kubernetes-tier platform that does the entire process of remote access, access control, visibility and auditing, user and identtiy management, centralized policy management, etc... from a data-plane and control-plane perspective for an arbitrary number of resources that need to be protected.
replies(2): >>44414880 #>>44415470 #
1. bdesimone ◴[29 Jun 25 19:05 UTC] No.44415470[source]▶
Quick note since it was mentioned. Pomerium does support Kubernetes at pretty much every level you mentioned (although I'm not entirely sure what a "a complete Kubernetes-tier platform" means) including:

- "remote access" : https://www.pomerium.com/docs/capabilities/kubernetes-access

- "access control" https://www.pomerium.com/docs/capabilities/authorization

- "visibility and auditing" : https://www.pomerium.com/docs/capabilities/audit-logs

- "user and identtiy management" https://www.pomerium.com/docs/capabilities/authentication to which I'd add device identity as well.

- "centralized policy management": https://www.pomerium.com/docs/capabilities/authorization & https://www.pomerium.com/docs/internals/ppl

- deployments using Ingress Controller or GatewayAPI https://www.pomerium.com/docs/deploy/k8s/ingress, https://www.pomerium.com/docs/deploy/k8s/gateway-api

- "for an arbitrary number of resources" not sure what to link to but there's no limit here

Congrats on the release. I saw your thread on MCP and completely agree with the approach. Happy to trade notes :)

replies(1): >>44415668 #
2. geoctl ◴[29 Jun 25 19:31 UTC] No.44415668[source]▶
I apologize if my reply was seen as critical in any way. I only wanted to make a difference between Octelium as a complete platform compared to Pomerium (I meant the open source project not the entire Enterprise offering which is obviously a complete BeyondCorp solution) and Ory Oathkeeper as identity-aware proxies. A more technical description for Octelium is that it is for IaPs similar to what Kubernetes is for containers. It simply provides a complete control plane to manage and deploy IaPs on top of Kubernetes itself. In fact, I am a fan of Pomerium and their work (I still remember your great work related to Golang's Webauthn and its attestation-related stuff ~3 years ago) if you're part of the team. Funnily enough, Octelium started as a sidecar ext_authz svc for Envoy instances to operate as an IaP but I ended up creating my own Golang-based IaP, Vigil, from scratch because Envoy was just nothing but pain outside HTTP-based resources.
replies(1): >>44415788 #
3. bdesimone ◴[29 Jun 25 19:46 UTC] No.44415788[source]▶
Genuinely, didn't take it that way at all! I don't expect you to be an expert on Pomerium.

> Funnily enough, Octelium started as a sidecar ext_authz svc for Envoy instances to operate as an IaP but I ended up creating my own Golang-based IaP, Vigil, from scratch because Envoy was just nothing but pain outside HTTP-based resources.

That's really funny... we went the opposite direction as the original versions were based on a custom Go proxy. Of course there are tradeoffs either way. Envoy is blazing fast, and does great with HTTP naturally, but has a giant configuration surface area (both pro and con), but we are now having to write some pretty low level filters /protocol capabilities in envoy for the other protocols we support (SSH, MCP, and so on) in C++ which does not spark joy. So I totally feel what you are saying.

Thanks for the kind words, though I am one of the contributors my colleague did the heavy lifting on the WebAuthN side.

Genuinely happy to see the release and where you are headed on the AI/MCP side. If you (or others) are interested, I am trying to bring more light to this model in the spec if you (or others) would like to weigh in: https://github.com/modelcontextprotocol/modelcontextprotocol...

replies(1): >>44416074 #
4. geoctl ◴[29 Jun 25 20:18 UTC] No.44416074{3}[source]▶
Thank you. Honestly if I had the right to give you my opinion, I'd just advise you to go back to full custom Go-based proxies regardless of how overwhelming that might sound. Octelium itself still does use Envoy as an ingress for the BeyondCorp mode to route to the intended Service based on the FQDN, however, Envoy as great as it is for ingress and HTTP-based service mesh purposes especially when it comes to memory/CPU usage under huge load conditions, it really shows weakness when it comes to building generic multi L7-protocol aware (e.g. HTTP, SSH, Postgres, MySQL, RDP, etc...) IaPs where you need to understand L7 for each of these protocols to provide access control, modifications to the protocol specific messages and providing L7 aware visibility. The amount of work you need to do in ext_proc, ext_authz, proxy-wasm, etc... is just ridiculous and error prone due to the extra round trips yet it is equivalent to what you could have done if you owned the entire data plane yourself.