←back to thread

354 points geoctl | 5 comments | | HN request time: 2.372s | 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 ◴[] 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 ◴[] 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 ◴[] 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 ◴[] 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 ◴[] 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 ◴[] 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 ◴[] 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 ◴[] 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 #
dudeinjapan ◴[] No.44414880[source]
Much of this writing is about finding the right level of detail to communicate the core ideas.

“Octelium is a full-featured access control platform, which provides API gateways and/or VPN tunnels to your HTTP services, paired with an intuitive user, policy, and auditing backplane and policy-as-code.”

Something like the above would be much more enticing to potential users including myself. I can get a rough idea of what I can actually use it for and how it can be integrated into my existing stack—and if there are more features I’ll be pleasantly surprised when I read the docs!

replies(1): >>44415184 #
geoctl ◴[] No.44415184[source]
I completely agree with you. And tbqh since almost everybody in the thread is complaining about the README then I must be really doing something wrong explaining Octelium and what it does. I will certainly put more effort to make the README and especially the main description section more useful and easier to understand without transforming it into more of a marketing pitch. As I mentioned in other replies, it's actually really hard to concisely describe fairly complex projects (e.g. Kubernetes, Istio, etc...), especially to newcomers. But I will definitely do my best to improve the docs and README. Thank you really for your insightful comments.
replies(1): >>44415607 #
1. dudeinjapan ◴[] No.44415607[source]
One more pointer would be to be very explicit on the homepage about the problems the product solves.

For example, many organizations use a mix of gated HTTP over public internet AND VPN, each one will have its own vendor auth product(s), user whitelisting, it's difficult to control or regularly audit. Octelium centralizes this management and gives admins the flexibility to control how services are exposed and to whom, presumably via simple policy change git commits. SOC2, etc. then becomes a breeze to export the state of the world, onboard/offboard employees, etc.

Defining the product in terms of use cases/problems/solutions rather that competing alternatives (Tailscale, Okta, ORY Hydra, etc.) will go a long way to increase clarity.

replies(1): >>44417039 #
2. geoctl ◴[] No.44417039[source]
Thank you, I will definitely add more kind of less-technical information on the homepage to make it easier to understand for business people. As for comparisons, I have been actually reluctant to do it because I don't think I can ever do a truly neutral comparison myself and I believe it should come from neutral parties such as blogs as well as users trying to discover the best solution that works for their own use case. But since I have been asked multiple times already I will probably add some comparisons soon.
replies(1): >>44417403 #
3. noname120 ◴[] No.44417403[source]
I'm not entirely sure if you realize that people here are highly technical yet don't get the point.

The problem isn't that you need to “make it easier to understand for business people” (which many here would take as an offense), the problem is that you're name dropping technologies and concepts without articulating exactly what problem your product solves, and what your exact value proposition is.

Something that does everything usually does nothing well, or at least doesn't provide a coherent dev experience with a sane mental model.

replies(1): >>44417907 #
4. geoctl ◴[] No.44417907{3}[source]
Believe me I am the one who's actually still struggling to find where the jargon/buzzwords/naming dropping exactly is in my own README. Is it terms such as ZTNA/BeyondCorp, MCP, A2A, AI/API gateway? Is it secretless access, zero trust? I will do my best to simplify the README and docs. It's not like I am happy that even technical people are struggling to quickly understand the README. I admit that there must be something wrong with the README/docs and I am going to improve it. All those people hinting the same thing cannot just be wrong.
replies(1): >>44420241 #
5. dudeinjapan ◴[] No.44420241{4}[source]
Zero-Trust, secretless, ZTNA, BeyondCorp, A2A, AI gateway, next gen --> buzzwords

API gateway, MCP, Oauth, VPN --> not buzzwords

The defining characteristics of buzzword are that is very broad, promises "pie-in-the-sky", and almost universally under-delivered by every vendor while incurring very steep costs. In other words, the reason "zero-trust" scares people is because they have probably been burned N times but Oracle, Okta, etc. etc. incurring large costs to achieve underwhelming/non-functioning results, often times paying $$$ to solve imagined infinity-scale problems that don't even apply to the current org size, or even 10x the size.

API gateways, MCP, VPNs are tangible things that fill fairly mundane roles, it is not hard to envision how they can be used to solve real-world properties. I can easily envision dropping an "API gateway" in front of "MCP" in my stack. ZTNA however I cannot just sprinkle on my stack as if it were magic pixie dust...

It doesn't mean that ZTNA should be outright banned everywhere, but when you do use it, you need very careful to define an exact meaning expressed in terms of non-buzzword components.