The Hacker News discussion about Octelium reveals several recurring themes regarding the project's presentation, functionality, and positioning within the market.
Lack of Clarity and Overuse of Buzzwords
A significant portion of the feedback revolves around the difficulty in understanding what Octelium actually does. Many users expressed frustration with the README and overall description, finding it dense, redundant, and filled with technical jargon.
- "It looks very interesting, but I’m getting lost in the pages of features and different use cases. It would have been nice to have a succinct list of features/capabilities (technical, not buzzword) and why this solution solves better than alternatives," kosolam noted.
- alienbaby echoed this sentiment: "I scanned the github, and your reply above, and I still don't really get it. I imagine I would understand it better if I was more fluent in the vocabulary you use and understood what some of the platforms and interesting names did from the get go. So yea, my 2p - break it down into some use cases from simple - intermediate - advanced, use more straight forward language and less platform / product names. Technical terms are fine, but try not to string a zillion of them together all in one go... it reads a bit too much like a sales pitch trying to cram in as many acronyms and cool sounding things as possible."
- mzhaase stated, "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."
- drexlspivey provided a direct quote of the perceived buzzword-laden description: "“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."
- noname120 criticized, "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."
- mdavid626 observed, "I’ve read “zero trust” more times today, than ever before in my life. Still don’t know what this project does."
- rollcat commented on the perceived SEO attempt: "I understand adding the "AI" keyword is just SEO, like adding "Reddit" to article headlines... It still leaves a bad taste, even if the main course is excellent."
- sneak offered advice: "As the other commenters have pointed out, your README is offputting."
- thealistra questioned the target audience and value proposition: "Is this a replacement for a huge corpo botnet like access control? If I am a huge corpo, don’t I want to have another huge corpo provide me the software with a support package to have some assurance and not go with the open source option? Not sure if your project solves any issue of a singular dev."
The project maintainer, geoctl, acknowledged these criticisms: "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." and "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." Later, geoctl also stated, "However, as I said this is a term that nobody would relate to." and "I am sorry that you find whatever I say as nothing but 'jargon'."
Request for Clearer Explanations and Use Cases
A recurring suggestion was to explain Octelium through concrete use cases and more accessible language, rather than a broad list of capabilities.
- alienbaby advised, "Perhaps it would be easier to go through a few typical use cases and implementations, and describe how they work with less brand naming and technical fancywords."
- homarp requested, "define all the terms. explain simple use cases. explain why you built it, how you use it. explain the 'size' of it (it requires k8s so might not be for my small homelab) compare to 'similar' offerings."
- reachableceo suggested, "I recommend using an LLM to rewrite it far more succinctly."
- catlifeonmars offered, "Gentle feedback: if it’s hard to concisely define what Octelium is, it will be hard to convince people to use it."
- dudeinjapan proposed, "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."
- ar-nelson found a particular page clearer: "For everyone who's having a hard time parsing what Octelium does, I found this page to be the clearest explanation: https://octelium.com/docs/octelium/latest/overview/how-octel... It's clearer because, instead of starting with a massive list of everything you could do with Octelium (which is indeed confusing), it starts by explaining the core primitives Octelium is built on, and builds up from there."
- metmac felt many were missing the value: "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)"
geoctl responded to these requests by stating, "I will definitely 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." and "I will definitely add more kind of less-technical information on the homepage to make it easier to understand for business people."
Functionality and Comparison to Alternatives
Users attempted to categorize Octelium by comparing it to existing tools like WireGuard, Tailscale, ngrok, Cloudflare Access, and Teleport, with varying degrees of success in understanding its unique positioning.
- geoctl described Octelium's broad capabilities: "It's more a generic Kubernetes-like architecture/infrastructure for zero trust secure access that can fit many different use cases (i.e. human to workload and workload to workload environments). Well, it can be used as a typical WireGuard/QUIC-based remote access/corporate VPN. It can be used as a ZTNA/BeyondCorp platform with identity-based, L7 aware, context-aware ABAC via policy-as-code with CEL and OPA where you can control access at layer-7 (e.g. HTTP request headers, serialized JSON body content, etc...). It can also be used as an ngrok alternative (both secure access via OIDC/SAML/GitHub IdP as well as anonymously which can fit for hosting, testing APIs, etc...). It can also deploy your containerized resources and automatically provide client-based/clientless secure access to them (kinda like a PaaS) and it does provide dynamic configuration and routing to upstreams via policy-as-code (e.g. route to different API versions, use different SSH credentials, different API keys, different postgres user/password based on identity/context, etc....). It can also fit as an API/AI gateway and a scalable infrastructure for MCP architectures/meshes. Therefore, it's not really a ZTNA/VPN in the rigid sense, it's a more generic platform where what it does to secure/remote access is similar to what Kuberentes does for containers."
- yjftsjthsd-h inquired about p2p connectivity: "The big thing to me about Tailscale is easy p2p connectivity. I _think_ it looks like this doesn't do that and uses centralized router(s)?"
- geoctl clarified Octelium's architecture: "Octelium is a zero trust architecture not a p2p VPN even though it can seamlessy operate as a WireGuard/QUIC-based remote access VPN among other things. Its architecture is closer to Cloudflare Access, Teleport, etc... as it provides dynamic L7-aware access control, secret-less access (i.e. injecting API keys and access tokens, database passwords, SSH private keys, mTLS private keys etc... without distributing them to Users), dynamic configuration and routing to upstreams, etc... via identity-aware proxies as opposed to just merely operating as a VPN at layer-3 as well as to providing OpenTelemetry-native visibility and auditing in real-time. True zero trust architectures such as ZTNA/BeyondCorp, apart from service meshes (e.g. Kubernetes service meshes), are problematic to be implemented as p2p VPNs to say the least. You simply need L7-aware identity-proxies to do the process of access control and visibility at the application-layer on a per-request basis."
- geoctl later compared it to Pomerium and Ory Oathkeeper: "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."
- bdesimone noted similarities to Pomerium's capabilities.
- geoctl further elaborated on the comparison with Pomerium: "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." He also reflected on the development process, mentioning that 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."
- bdesimone responded, "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."
- sureglymop contrasted with Tailscale's tagline: "By contrast, here is Tailscales tagline: 'Fast, seamless device connectivity — no hardware, no firewall rules, no wasted time.' That kind of tells even a non-technical user what it is for even if it dumbs down all it can do."
- geoctl defended Octelium's scope: "As as I mentioned in the other replies. Octelium is designed to be much more than just a VPN. It is not even tied to provide remote access to 'devices' or resources behind NAT. It's zero trust architecture that's equally designed to provide access to internal resources and publicly protected resources such as SaaS APIs, databases, Kubernetes APIservers, SSH, etc... It provides both client-based (i.e. VPN-like) access as well as clientless access for both humans and workloads."
- wkat4242 listed several alternatives: "Tinc (the OG of P2P VPN), Hamachi (not open though), ZeroTier, Nebula (from Slack), Tailscale, Netbird" and wondered, "I know each has its own quirks and things they're better at, but the difference is really quite minimal."
Concerns about Kubernetes Dependency
The project's reliance on or assumption of a Kubernetes cluster for setup raised concerns for some users who preferred a more direct, less infrastructural dependency.
- baobun expressed, "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 minimal or no dependencies on other infrastructure or internal services."
- geoctl clarified: "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." He added, "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..."
- guigg stated, "I don't understanding why you're embedding a full k3s cluster install in your app, it would be much clearer to everybody if this was something that you could add to existing infrastructure, with simpler CRDs to expose services."
- geoctl countered, "Simply an Octelium Cluster is a distributed system that operates on top of k8s. It can work on top of a single-node k8s cluster/k3s which can fit in a small VM/VPS and it can also operate on top of a multi-node 'production' k8s cluster. Octelium isn't just some simple abstraction over k8s, Octelium is a complete platform on its own that uses k8s as an infrastructure for itself."
Interest in Open Source and Self-Hosting
There was a clear interest in open-source alternatives to commercial offerings, particularly in the context of controlling one's own infrastructure and avoiding future "enshittification."
- reachableceo expressed their preference: "We use Cloudron as our core PAAS and have been looking for a FLO zero trust / identity aware proxy for DB/RDP/SSH . Happy to be your flagship customer."
- wkat4242 commented on the inevitability of commercial services "enshittifying" and the desire for self-hosting.
- candrewlee agreed with the "enshittification" point, linking it to investor incentives.
- cchance mentioned, "I'd like to see an effort for an opensource tailscale client so we could use headscale without the closed source client."
- maxboone and zxexz engaged in a brief discussion about Tailscale's open-source status of its clients.
- homarp pointed to Headscale as an open-source alternative to Tailscale's control server.
- uneekname clarified Headscale's role: "Headscale is great (I use it) but it is an alternative to the Tailscale control server, not the client applications."
- PoachedEggs mentioned Netbird as another self-hostable option.
- wkat4242 listed ZeroTier and Nebula as other similar self-hostable solutions.
- geoctl countered the idea that there are "so so many of these already," differentiating Octelium's focus on zero trust architectures beyond just VPNs or remote access tools. He emphasized, "Every product claims to be 'zero trust' these days, even VPNs and simple tunneling applications, however, actual zero trust architectures as defined by NIST (i.e. architectures built upon L7-aware identity-aware proxies, policy-decision-points, L7-aware and context-aware per-request access control via policy-as-code and ABAC, centralized identity and policy management, integrating context information from external tools such as SIEM, SSO and threat intelligence tools into per-request access control decisions, etc...) and there are many commercial products that are 'true' ZTAs (e.g. Cloudflare Access, Teleport, Google BeyondCorp, StrongDM, Zscaler, etc...)."
Trust and Legitimacy Concerns
A smaller but notable theme was skepticism regarding the project's origins and perceived legitimacy, particularly given the solo developer aspect and verbose README.
- therealpygon voiced, "Just some feedback to share some problems I personally think you’re going to have and why I suspect you’ll face a healthy amount of skepticism. There is a lack of history of development that ends with a major initial commit of unknown origin, a lack of any public information, a company that does not appear (publicly) to exist, and a product that is going to solve every need that can be imagined by packing it with buzzwords and little to no evidence of security."
- cyanydeez suggested, "I think the primary concern was you look like a State actor using a AI to generate a project you hope private companies will use and your intentions don't appear clear, and the verbose replies & github suggest a lot of effort into a facade without anything else. One might posit that you're repackaging a fOSS project from somewhere with no clear ethos."
- geoctl addressed these concerns by stating the project has been in development since 2020 and is 100% open source, acknowledging that even this might not be sufficient proof for some.
- csomar offered a defense: "Give open source devs a break. We don't know the OP background or his motivations. He might have been working on this for fun. He doesn't need to justify any of this. This is open source and Free software. Take it as it is."