Get the top HN stories in your inbox every day.
ar-nelson
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.
And it actually looks pretty cool and useful! From what I can tell, the core funtionality is:
- A VPN-like gateway that understands higher-level protocols, like HTTP or PostgreSQL, and can make fine-grained security decisions using the content of those protocols
- A cluster configuration layer on top of Kubernetes
And these two things combine to make, basically, a personal cloud. So, like any of the big cloud platforms, it does a million things and it's hard to figure out which ones you need at first. But it seems like the kind of system that could be used for a homelab, a small company that wants to keep cloud costs down, or a custom PaaS selling cloud functionality. Neat!
ttul
TailScale is wonderful but they do need competition. I imagine an IPO is on the horizon, and as soon as they enter that phase, nasty price increases are sure to follow unless someone else is nipping hard at their heels.
seabrookmx
Hopefully their tolerance to self-hosters (Headscale) doesn't change.
udev4096
The individual working on headscale also works for tailscale. And being quite stable and prod ready, even if they pull the plug, a community fork would still keep it alive, given majority of essential features are already there
wkat4242
The problem is, commercial services will always enshittify. It's inevitable. Even when they conquer the whole market (see Netflix) they will want to see a rising line in profits so then they will turn the thumbscrews on the customers.
wiesbadener
They seem to be fine with it: "You could alternatively host your own trusted control server with Headscale."[1]
braginini
There is https://netbird.io
wkat4242
But there are so so many competing products already?
Not all are commercial (but why would you want that anyway). But ZeroTier is another one like that. Basically the same thing.
nativeit
Yeah, I chose ZeroTier over Tailscale early on. Zero regrets, it’s nearly perfect for my use-case (remote monitoring and management of highly diverse systems and environments).
dahrkael
there is also the chinese EasyTier https://easytier.cn/en/
dangoodmanUT
See Nebula by slack
snapplebobapple
Netbird is nipping at their heels
PoachedEggs
I’ve been meaning to explore Netbird. Fewer features at the moment, but can be fully self hosted.
FloatArtifact
Their mobile android app is awful.
cchance
I mean the fact headscale exists and is still in decent development, means i doubt it really is an issue, what i'd like to see is an effort for an opensource tailscale client so we could use headscale without the closed source client.
maxboone
Isn't the client entirely OSS? - https://github.com/tailscale/tailscale
toomuchtodo
Programmable network tunnel fabric.
therealpygon
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. When faced with those things, my next step would be to consider how much is original versus built on underlying technologies I know and trust; information that is lacking.
If you’re launching a business, I would suggest making sure the business looks legitimate; if it’s a pet project, trying to make yourself sound like a big business and then not having the footprint gives off “fake”/scam/caution vibes. If you’re a solo dev, drop all the fake business stuff and get rid of the buzz words and “it can do everything” marketing and focus on what it excels at as an open source project.
People are going to be skeptical (rightfully) that a solo dev/no name company is going to suddenly drop a product that rivals those of massive companies. Either massive shortcuts were taken, or there is a high chance that it will be insecure, which is not something you want from a VPN or any of the other things it claims to do. If you’ve built on existing secure technologies, you should emphasizing them because known names that have a security history are going to build a lot more trust than a no-name product.
If a software is hard to explain the purpose of to an average person in a single sentence, you have an uphill battle. Listing more features isn’t usually going to be the answer, regardless of how accurate you’re attempting to be. “It’s a VPN! and a PaaS! and a ZTNA! And an API Gateway! and AI!” It screams “please download me” rather than “I’m here to solve a problem“, which is why I wouldn’t even bother to try it; the opposite of what any project is going for.
My intention isn’t to just be critical, but rather to point out things that are likely harming your efforts.
geoctl
Thank you for your insightful feedback. I completely understand the criticism because Octelium is conciously designed to be many things at the same time. As mentioned in the other replies, Octelium is a unified/generic zero trust access platform that can fit in many human-to-workload and workload-to-workload use cases (the docs contain various examples in detail) that's why it might be confusing for newcomers. The initial commit came out of nowhere because I've been working on this project since early 2020 actually and decided to start with a clean public repo when I publicly released the code a month ago, after nearly 9000 manual commits over the past 5 years. I simply could not verify that I could have potentially leaked private info esepcially in early commits and the project itself almost entirely changed over the past 5 years from a simple remote access WireGuard VPN to what it is today in terms of architecture, features and complexity.
cyanydeez
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
I have been developing the project solo on a private GitHub repo since 2020. I am not VC-backed or whatever else, Octelium has been a solo effort so far basically. The project itself is now 100% open source as you can see. However, even if I open sourced the initial private repo, what would make you believe that I am who I really am? maybe even all those git commits from 2020 weren't really from 2020 and their timestamps have been spoofed to make you believe so. If 100% of the codebase of the project being open source is still not enough, I guess nothing can be enough.
csomar
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.
> If a software is hard to explain the purpose of to an average person in a single sentence, you have an uphill battle.
It does. If you use tailscale/cloudflare access and ngrok, the product is pretty well described. If you don't, then probably you don't need this product.
noname120
I use those but I still don't understand what Octelium does or doesn't
canada_dry
> solo dev/no name company is going to suddenly drop a product
A developer/company with an opaque background that you're to trust to give access to backend systems using passwordless embedded SSH (no keys needed!).
That's a big NOPE.
(Also, even the answers OP has provided really give an AI bot vibe)
geoctl
Octelium's author here. You don't give me access to anything. The project is 100% open source and designed specifically for self-hosting. I don't even know whether you're using the project or not since there isn't usage telemetry to begin with. As for the SSH part of your weird comment, I wonder whether you even understand what embedded passwordless SSH means in the first place.
cedws
Definitely interested in an open source alternative to Tailscale.
The README is way too verbose though. It should explain the project at a glance and have links to docs for the details.
homarp
headscale is an open source alternative to tailscale:
uneekname
Headscale is great (I use it) but it is an alternative to the Tailscale control server, not the client applications. Some of those are closed source, and their compatibility with Headscale is not guaranteed.
CharlesW
Tailscale's client is already open source.
https://tailscale.com/opensource: "The core client code for the Tailscale daemon used across all platforms is open source, and the full client code is open source for platforms that are also open source."
rollcat
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.
Even the diagrams for API vs AI gateways are almost identical.
geoctl
There are lots of common functionalities between API and AI gateways. It would be much easier for you to check out the examples in the docs: For the AI gateway: https://octelium.com/docs/octelium/latest/management/guide/s... As for the API gateway: https://octelium.com/docs/octelium/latest/management/guide/s...
I am also working on extending the process of modifying HTTP requests/body content beside what's been provided (see more https://octelium.com/docs/octelium/latest/management/core/se...). For now, Envoy's ext_proc support is coming, and I might also work on support for proxy-wasm if there is interest in it.
kosolam
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.
geoctl
Thank you. I understand it's hard to concisely define what Octelium is because it is designed as a unified/generic secure/zero trust access platform, a term that almost nobody would relate to. It's more of 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.
alienbaby
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.
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.
reachableceo
I do agree with that. As a potential customer , reading over the page, it was incredibly redundant / dense.
I recommend using an LLM to rewrite it far more succinctly.
geoctl
I honestly don't understand where the "sales pitch" part is. This project has been so far a solo effort and I am the one who basically wrote all the code. It's not like this is some VC-backed product where I am a marketing guy replying to you. I would appreciate it if you could provide me direct questions about what you don't understand so that I can answer you.
reachableceo
Please update your HN profile with contact information.
This product? Framework? Solution? seems to be exactly what I’ve been looking for / attempting to put together for my company. We are entirely self hosted and use only FLO software.
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.
We have a brand new k8s (self hosted) cluster deployed . We use wazuh as our SEIM, librenms for monitoring / alerting.
Currently we use tailscale (with magicdns disabled and we hand out our internal pi hole IP as our recursive DNS server ) (and we have an authoritative DNS for our internal corporate domain).
Charles@turnsys.com reaches me pretty quickly most days. Would love to deploy this immediately and write a testimonial etc
geoctl
Thank you so much. I will definitely contact you very soon.
catlifeonmars
Gentle feedback: if it’s hard to concisely define what Octelium is, it will be hard to convince people to use it.
To me this sounds like an L7 identity & access management layer for wireguard, but again I had trouble parsing the readme.
geoctl
Thank you. I completely understand your point of view. I did put a lot of effort actually trying to come up with a simple concise description that can fit in an HN 80-char wide title but I simply could not do it. If you think about it, other fairly complex projects such as Kubernetes or Istio are also very hard to concisely describe for newcomers. There is always some assumption that potential users of the project are already acquainted with the terms used in modern zero trust architectures and familiar with similar commercial products such as Cloudflare Access, Teleport, StrongDM and many other related products.
marifjeren
Here is some unsolicited advice on clarity.
Pick one or two descriptive phrases per subject. If you need more sentences, that's okay.
For example:
> 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.
->
"At its core, Octelium is a modern alternative to VPNs. Unlike traditional VPNs, it assumes a zero trust security model. Octelium is open source and built to be self-hosted. The README describes many other use cases and features."
yjftsjthsd-h
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
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.
ethan_smith
Looking at the docs, Octelium uses a hub-and-spoke model with Gateways acting as central routing points, unlike Tailscale's direct peer-to-peer mesh - this architectural difference impacts performance, privacy, and deployment complexity.
geoctl
No, Octelium does not use a hub-and-spoke model. It's a distributed system that's a horizontally salable architecture on top of Kubernetes. This design is meant to provide seamless horizontal scalability and availability, among other things.
gen6acd60af
>easy p2p connectivity
>centralized router(s)
When using Tailscale, your packets may be sent through centralized routers, FYI.
baobun
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!
geoctl
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.
sneak
As the other commenters have pointed out, your README is offputting.
Last year I wrote an article about how to write a good README:
geoctl
Thank you. I will definitely work on making the README more concise and hopefully more useful and easy to understand.
sevg
Your readme isn’t great, but I wouldn’t pay much attention to this guide that this person keeps posting.
It’s way too long and excessively prescriptive, and the author goes too far with inserting their opinions (ie, don’t use github, don’t use discord etc.). I couldn’t possibly recommend this howto.
sneak
Oh, look, we both have opinions that we each believe are important. Imagine that. :)
I think this is the part where I’m supposed to tell third parties to disregard yours, but I’m not going to.
guigg
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. The pitch for the project looks awesome (opensource Cloudflare access / Teleport), but most of the features are customizations on top of k8s anyway, I'd be more interested in testing this if it was focused on the access part.
geoctl
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. It uses its nodes as gateways and hosts for Octelium Services, each Service, represented by an identity-aware proxy that's deployed as a k8s service on the underlying k8s cluster, has a stable private dual-stack IP address(es) depending on the scaling and is basically acting as the endpoint of the other side of the WireGuard/QUIC tunnel. You can now see that Octelium does with identity-aware proxies similarly to what Kubernetes itself does with containers, building a control plane around a scalable data-plane to automatically manage and deploy identity-aware proxies instead of just offloading the work manually to the Cluster administrators which is, I believe the case, in many ZTAs (e.g. Teleport, Pomerium, etc...) which makes the entire system very hard to manage since there is a lot of manual work to do by the administrators of the system. With Octelium, you can simply create and delete Services declaratively via `octeliumctl apply` or directly via the gRPC APIs and forget about managing, deploying and cleaning them up yourself. Actually Octelium resources started as CRDs many years ago, but the amount of resources in the Cluster (e.g. Users, Sessions, Services, Namespaces which are not related to k8s namespaces, Policies, Devices, Credentials, etc...) made it impossible to rely on a the etcd backend, it was simply unreliable for frequently updated resources and resources with large info. So a separate Postgres backend was introduced later.
geoctl
One more thing regarding the CRDs. Octelium resources and k8s resources look similar from a YAML perspective. However, Octelium actually use protobuf, all the resources are defined in proto3 and compiled to Go, then the Golang resources are serialized to JSON and stored as JSONB in the Postgres data store of the Cluster. I guess that's another reason you thought that Octelium resources might be CRDs but they actually are not.
Tokumei-no-hito
this is incredible OP. nearly every criticism I've read could be resolved by reading the docs for 10-15 mins starting from the "how it works".
i did feel uncertain from the README but once i got into the docs i was blown away. this is incredibly well abstracted and organized both in terms of the implementation and docs. to hear that you built this yourself is absolutely legendary. thank you for releasing this.
geoctl
Thank you really for your kind comment. Most of the links regarding how Octelium works, the quick management and installation guides, the examples (e.g. API/AI/MCP gateways, etc...) were actually included in the README itself. However, most of the criticism was supposedly coming from the terms used in the README. I was already assuming that the users are somewhat familiar with zero trust and zero trust architectures. Maybe that was the problem.
fariszr
This looks very impressive, but the Readme has way to many details, I think i got the idea but I'm not sure, and that's a problem.
geoctl
Thank you. I'd advise you to read how it works https://octelium.com/docs/octelium/latest/overview/how-octel... and the quick management guide https://octelium.com/docs/octelium/latest/overview/managemen... to get a clearer idea about how it works and how it's managed. The docs are full of examples for specific use cases too such as https://octelium.com/docs/octelium/latest/management/guide/s... https://octelium.com/docs/octelium/latest/management/guide/s...
Get the top HN stories in your inbox every day.
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