←back to thread

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

(github.com)
354 points geoctl | 2 comments | 29 Jun 25 11:24 UTC | HN request time: 0.44s | 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
1. baobun ◴[29 Jun 25 23:03 UTC] No.44417415[source]▶
Looked into Octelium recently and it looks like it depends on or at least assumes a kubernetes kluster for setup. Is this true? If so it makes it a bit of a non-starter for many - we want our nodes on the overlay network, not the other way around. It's a complex dependency for something low-level where we want mininal or no dependencies on other infrastructure or internal services. (Of course there are valid use-cases for SDN on top of the cluster and I guess that's what you're targeting initially but curious if that's also the end of it)

Or put another way, I hope that Kubernetes integration is an option, not a prerequisite and the only supported deployment.

In case there's already material on Octelium sans k8s that I missed, pointers would be appreciated!

replies(1): >>44417511 #
2. geoctl ◴[29 Jun 25 23:16 UTC] No.44417511[source]▶
As as I mentioned in some other reply, Octelium is built as a distributed system on that can operate on top of 1 or more nodes. While Octelium currently must work on top of Kubernetes, Octelium itself is not really that intertwined with k8s, it can actually easily be ported to other orchstrators such as Nomad for example. However, the rationale behind operating as a platform on top of k8s that uses a k8s cluster as an infrastrcuture for itself is to relieve the system administrators from all the manual work that comes with managing zero trust architectures such as manually deploying/scaling/cleaning up the identity-aware proxies. Octelium simply provides both the control plane and data plane where you can just `octeliumctl apply` and all the Octelium Services are deployed/managed/scaled up or down and eventually cleaned up without having to manually run them, open firewall ports, etc... It's very similar to what Kubernetes itself does with containers where a single `kubectl apply` deploys/scales/cleans up all the container changes without having to manually deal with every container in every single node like you would do with docker or containerd. You don't even need to know how many nodes you have or deal with CRI/networking details on every node since a single Cluster spans over all the nodes and does all the work for you whenever you want to apply a new change in the Cluster. This architecture is meant to make the Cluster seamlessly scalable by adding more nodes whenever you want and at the same time can be manageable at any scale decoratively via octeliumctl or programmatically like you would have with a normal k8s cluster. I believe you can understand more by reading how Octelium works in detail in the docs https://octelium.com/docs/octelium/latest/overview/how-octel...

It's also noteworthy to understand that managing an Octelium Cluster doesn't really require any understanding of Kubernetes or how it works, unless for very specific tasks, such as scaling up/down the k8s cluster itself and setting the Cluster TLS cert fed via a specific k8s cert. Apart from that, you're just dealing with Octelium.