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!
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.
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
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.
It’s especially when they conquer the whole market. It’s why investors favor growth and adoption, even at a loss, until it’s won the market and can turn up the monetization dial.
All the streaming services are enshittifying, even the smaller ones. And other smaller webshops are enshittifying the same way that Amazon does. Like Cory Doctorow described, there's a few big webshops in the Netherlands like bol.com and coolblue.com and they are now also allowing third party sellers, often even from China. The webshops are absolved of all responsibility but they do cash out on every transaction.
Sorry no. A stable organization with a good profit margin is enough to take care of employees and pay their salaries. Boundless growth which is what enshittification is associated with, is driven by money-hungry stakeholders and “investors” that demand an ever growing return on investment - they don’t settle for speed, they need constant acceleration.
A lot of employees at successful startups & FAANG make most of their money from the stock, no? And they need to buy houses and send their kids to fancy schools too, no? So sure, we can reduce it to stock holders, but I’d bet dollars to donuts the 90% of employees who aren’t posting on hn are at least passively ok with “improving metrics”, and some ambitious ones are driving the enshittification initiatives hard.
IMO the reason devs started being paid in stock in the first place is VC-style grow at all costs mentality. The fundraising economy didn’t work without fabricating compensation and only paying out on hits.
No other industry operates with such a blurred distinction between employees and owners. Well, save for the gig economy, itself a tumor on American-style big tech.
Personally I'd be much happier with a stable income with not much upward mobility but also not much risk of falling downwards. Which is what Europe is geared more towards. I don't constantly want to be in a race. Just to live my life.
If they employees want it, fine but don't be surprised if we customers start finding alternatives. And/or pirating their content (e.g. when it comes to streaming services).
But yeah American companies aren't there to support the employees. The only one they answer to are the owners or large shareholders (whichevery applies), and their only goal is to make those richer. Customers and employees alike are nothing but consumables, a raw resource you only treat right if you can't avoid it.
They're fine with it now. They won't be, when the next potential revenue source on their list is to crack down on it.
Remember, revenue must always increase, and must always increase faster than the year before (and this is more important than keeping the company alive), so companies always try increasingly desperate measures. Right now they are nowhere near the point of that particular measure. But they will be in the future.
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).
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.
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.
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.
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.
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.
If they don’t trust you, it’s their right, but then they should just not use the software, instead of writing this type of caustic comments. Poor form in my view.
If anything I am actually thankful to HN for the opportunity letting me show my work here. Negative comments are not really that big of an issue for me. I just wish they were generally clearer and more specific so that I can easily fix whatever needs to be fixed. Most of the complaints were simply related to the README while I was expecting and honestly hoping for critique for the architecture and internals of Octelium itself.
That is sort of the point of what you are considering “negative” comments. For clarity, my comment was advice on how you can improve the public persona of your project.
You seem to have pointed out but equally not registered that you identified exactly the issue: if your readme is filled with red flags, no one is going to invest their time (which is what you are asking for) looking at your code or trying it.
I completely understand as a developer how the “marketing” (readme) of a project may not seem that important or that it should be super accurate, and that it can be easy to fall into the pattern (as can be seen) of looking at every comment that brings voice to criticisms as being “negative”. You’re simply too close to the problem and are therefore only seeing the trees for the forest, while everyone is trying to tell you that you should probably remove the giant fence in front of the trees.
Thank you again. I meant by "negative" that they are critical as opposed to insulting. As I mentioned before in this thread, I usually don't find negative/critical comments offensive at all. Believe me, the last thing that I would want for an open source project that I have been working on for years now is to show it to people, especially technical people, with poor wording or hard-to-understand terms. That was never intentional by me. In fact, the reason that README is too long is that I wanted to explain all the features and use cases in detail while add additional links to the docs for those who want to understand more which probably made it even more overwhelming for those unfamiliar with zero trust architectures. I will definitely do my best to improve the README and docs with time as I get more honest feedback like in this thread. Thank you.
If these comments are “caustic” I’d recommend steering well clear of…the rest of the internet. These comments, from my perspective, represent a very pragmatic position from people who encounter scam bait daily in these same forums.
Should a user call people posting their software here state actors and the such? I really don’t think it helps anyone.
Rather, they should lay out thier points, suggest how the author could change their mind. Alternatively direct their warning to others if they feel their conviction that this is malware is unshakable.
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.
> 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)
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.
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.
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.
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.
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.
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.
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.
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
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.
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.
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."
So if you are running a closed source OS, Tailscale doesn’t have an open source client? Wouldn’t closed source OS users of Tailscale benefit the most from having an open source Tailscale client available?
> So if you are running a closed source OS, Tailscale doesn’t have an open source client?
As the content at the link makes crystal clear, the client is open source. Additionally, Tailscale's GUI for that client is open source on open source platforms.
99.999% of users of closed source OSs aren't going to care that the GUI isn't open source. The remaining 0.001% just use the open source client without the GUI.
> 99.999% of users of closed source OSs aren't going to care that the GUI isn't open source.
They may or may not care, but just so we’re all on the same page, there isn’t an open source version of the end user application software for closed source operating systems that I can find on that page or any other Tailscale page. If one exists, I am happy to be corrected by you, and I am giving you the opportunity to do so now.
In the spirit of inclusiveness to non-technical folks who are flummoxed by CLIs but also have a religious objection to running closed software on their closed source OS, I'd recommend that they ask a more technically-inclined friend to set up the open source Tailscale client software with Cattail if they're on Windows, or an Automation that drives the CLI if they're on macOS.
> If (1) you personally need a GUI and (2) have a religious objection to running closed software on your closed source OS, ask a more technical friend to set up Cattail if you're on Windows, or an Automation that drives the CLI if you're on macOS.
I’m just asking if Tailscale has an open source application. Users who know what a GUI is and why it’s also important that it is open source will care that the GUI isn’t open source. The ones who don’t, won’t. Who benefits from obscurantist-posting like you are doing? Probably not the folks who don’t know that Tailscale doesn’t have an open source app, because the GUI is part and parcel to what the app even is conceptually to the sorts of users who don’t know what GUIs are.
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."
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.
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.
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.
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!
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.
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.
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.
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.
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.
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.
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.
I’ll be keeping an eye on this, but I’ve gotta say, first glance it just seems like it does way too much, and all by a solo dev in private? Impressive but also perturbing.
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 asssurance and not go with the open source option?
Not sure if your project solves any issue of a singular dev.
Octelium itself is designed to be a generic secure access platform that can operate in many environments (from a simple ngrok-tier remote access tool, remote access/corporate VPN up to a full-fledged scalable ZTNA/BeyondCorp platform among many other specific use cases such as API/AI/MCP gateways) at many levels (i.e. dev, startup, enterprise). Think of Kubernetes, you can use it to host a single website running on a single container, you can use it as an API gateway for a few microservices and you can use it as a fully-featured service mesh of hundreds if not thousands of microservices running on tens if not hundreds of nodes with enterprise-level tools such as SPIFFE, Istio, etc...
Well I haven't used Pangolin myself, but Octelium can basically operate as a similar self-hosted remote access tool. It is designed however, to provide much more than just remote access. It provides L7-aware, context-aware ABAC-based access control, it provides L7-aware secretless access without distributing L7 credentials to users, it provides dynamic routing/configuration to upstreams and upstreams credentials based on identity/context, it provides OpenTemeltry-read L7 aware visibility and auditing. Therefore, it's more closer to Cloudflare Access, Teleport Enterprise, StrongDM, etc... than to Pangolin. However, it's also not just a ZTNA in the rigid sense, for example, your applications written in any programming language can just generate fine-grained bearer authentication access tokens via OAuth2 client credentials flow to access protect Services without having to use clients or special SDKs or being aware of Octelium at all. Octelium also operate on top of Kubernetes which makes it seamless for you to provide horizontal scalability and availability as your Cluster's Services, Users, Sessions and simply traffic grow.
Interesting. One way to do that in Octelium is via a SOCKS5 proxy served as an Octelium Service. In fact the Octelium Cluster nodes itself can operate as exit nodes directly and you can use that as a form of consumer VPN. You can even deploy and scale TOR containers over Octelium and have load balanced TOR.
Can I ask you what an ideal setup for your use case would look like? Octelium isn't really concerned with connecting complete remote subnets to each other directly. You can simply use a SOCKS5 proxy as an Octelium Service and do all the access control, dynamic routing and load balancing to that Service representing a specific "VPN".
I think a lot of other commentors here are more taking issue with the concept of ZTNs in general and may not have used them at scale, or at all. The intro is buzzword heavy, however I don't think that's an issue with your documentation, just the terminology of the space Octelium operates in which came from big business and was conceived as buzzwords to start with so there's not a lot of flexibility to use alternate terms that make sense.
Your documentation is extremely detailed and generally excellent. It does seem to be targeted at people who have already deployed Octelium or are very familiar with ZTN-style deployments. It's quite fractally dense (you stumble over one new term, need to go to another docs page, which is as long, that has more terms you need to read about, etc.) so as you've mentioned the issue really isn't your product but likely conveying what it does in a clear manner.
If you want to get general devs and homelabbers on board with the concept or testing this out, which I imagine is a very different target to your initial versions, maybe you could prefix your GitHub readme with something like:
"Octelium is a free and open source zero trust network platform. It integrates and manages your Kubernetes (and other container orchestration) applications to provide single point of authentication for all services. Your users log in once to one authentication provider such as a managed provider like Okta or any other OAuth OpenID compatible service and then your users are automatically granted their correct access levels to all your web services, databases, SSH, VPNs and more. Log in once, access everything, self-hosted."
When reading your documentation I immediately had a number of questions that were not clearly answered. That doesn't mean to say the answer isn't in your documentation, it's just that after 15-20 minutes of reading I still didn't have a clear answer. I'm reading this from the perspective of someone very familiar with operating Kubernetes clusters at scale and dabbled quite a bit with some of the commercial ZTN offerings. Apologies if the questions below are answered in your docs, I didn't find them in the time I had.
1) Your initial setup guides go from how to install Octelium to immediately scheduling services via YAML as a direct replacement for, I assume, something like deployments on k8s. Does Octelium actually run workloads? Is it 1:1 compatible with k8s API spec? Does it just talk to k8s over the API and effectively rewrite deployment YAML and spam it to k8s? Immediately this has concerns, why do I want this? Do I trust Octelium to manage deployments for me? Replacing a vast part of the k8s stack with Octelium tooling is a big ask for even small companies to trial. There's also just straight upstream connections, why would I want to let Octelium manage workloads over just using an internal k8s service hostname so I don't have to effectively rebuild the entire application around Octelium? Does letting Octelium manage workloads impact anything else (monitoring, logging, any other deployment tools that interact with k8s - if some CI/CD pipeline updates a container image does Octelium "know" or is it out of date?). What about RBAC stuff? Namespaces? Are these 1:1 k8s compatible?
2) If I work for BigCorp I'm going to have things like compliance issues coming out of my ears, your Services store credentials in plain text which is going to be flagged immediately. No-one is going to offload SSH authentication if root SSH keys are stored in plain text in secrets somewhere. I did note there's the option to effectively write your own gRPC interfaces to handle secure secrets storage but this seems like a pretty big hurdle. You then basically say "if you're enterprise we can help here" at the bottom, but I wouldn't even test this myself on a homelab without some sort of more sane basic secret management.
3) How, specifically, does Octelium handle HTTP upstream service issues? For example, if I'm proxying my companies connections to saas.com via saas.myintranet.example.com I assume I lose the ability to apply 2fa to user accounts? It's unclear from the documentation, can I specify unique credentials per user? How would I manage those? Is the only option OAuth and scopes? What if the upstream doesn't support OAuth? It's fine if upstream services need to support OAuth to support the most seamless and secure ZTN-style experience, it's just not that clear how these things work in practice.
4) You re-use a lot of terms from k8s (cluster, service etc.) which are subtly different k8s, this could cause confusion with a lot of k8s trained admins. For example, I believe an Octelium cluster is a k8s cluster running multiple Octelium instances and a custom data plane, this different enough to what a k8s cluster is to potentially be confusing as it's a different logic level. I appreciate there are limited generic descriptive terms in the dictionary to describe these things.
5) How, technically, does some of this stuff work? I know I can browse the repo or read the extensive documentation, but it would be helpful to have some clear "k8s admin"-targeted terms like, we install X proxy that does Y, using Z certificates, services managed by Octelium get a sidecar that intercepts connections to proxy them back into the ZTN, or whatever magic it does in clear, k8s, terms. If I'm looking after something like this I would need to know it inside-out, what if some certificate stops working? If I don't know exactly where everything is how can I debug it? If I deployed this it would be absolutely mission-critical, if it breaks the entire company immediately breaks. If that happens for a couple of days, realistically it can be business-terminating.
What would be really helpful to see would be some documentation with step by step guides on going from a starting point to what an Octelium-powered endgame would look like. For example, if I'm the CTO of a business that has some remote managed k8s clusters running our public SaaS along with some tooling/control panels/etc, and then a big server in my office running some non-critical but important apps via Podman, and 15 remote users that currently connect over a Tailscale VPN into the office, and 20+ upstream external web services that provide support ticketing, email, etc. then what does this look like after I "switch" to Octelium? Before and after comprehensive diagrams, and maybe even a little before-video of someone logging in via a VPN then logging into 15 control panels vs an after-video with someone logging into an intranet and just everything magically appearing would be nice. You need to sell something of this scale to CTOs, not engineers.
Generally, however, my personal biggest flag with this would be that it requires effectively a total rebuild of all infrastructure, learning entirely new tooling, management and oversight. It's a lot to ask and it doesn't seem like it can be that gradually rolled out. I suppose you could set up a second k8s cluster, deploy Octelium on it and then slowly migrate services over, but that's going to be expensive.
Some suggestions:
1) You have built a very impressive toolkit, why not operate this as a SaaS using your toolkit (with on-prem open source extensions)? You don't seem to have an actual product, you have a swiss army knife of ZTN tools which is way more work so hats off to you there. It seems you're partitioning this with "the toolkit is public, write your own glue for free, to get a working platform, come pay us" which is perfectly fine, the issue there is your "enterprise" offerings seem to be even more toolkit options rather than an actual offering. Bundle in some actual enterprise tools (fancy log tool with a web UI that also does user management and connection monitoring as a single dashboard?) and it would be a lot more appealing.
2) You require replacing industry standard technologies like directly managing k8s with kubectl with your own platform and tools - replacing "the way that everyone does X" with "new tool from relatively unknown ZTN provider" is going to be tough to sell. Can you make your octeliumctl tool a kubectl plugin? Could Octelium be less control-everything and just sit on top k8s rather than seemingly replace a lot of it?
Edit: 3) Have a homelabber edition, if that's a market you want to target, that's way easier to install and works in a single docker container or something (sacrificing some of the redundancy) but offers a basic complete suite of services (dashboard, HTTP upstream proxying, VPN) with a single "docker run...".
Good luck with Octelium, it's certainly interesting and I'll keep an eye on it as it evolves.
Thank you really for your detailed comment. I will try to answer your questions and please don't hesitate to ask in the Slack/Discord channels or contact emails later if the answers here weren't clear enough to you.
1. Octelium Services and Namespaces are not really related or tied to Kubernetes services and namespaces. Octelium resources in general are defined in protobuf3 and compiled to Golang types, and they are stored as serialized JSON in the Postgres main data store simply as JSONB. That said, Octelium Services in specific are actually deployed on the underlying k8s cluster as k8s services/deployments. Octelium resources visually look like k8s resouces (i.e. they both have the same metadata, spec, status structure), however Octelium resources are completely independent of the underlying k8s cluster; they aren't some k8s CRDs as you might initially guess. Also Octelium has its own API server which do some kind of REST-y gRPC-based operations for the different Octelium resources to the Postgres via an intermediate component called the rscServer. As I said, Octelium and k8s resources are completely separate regardless of the visual YAML resemblance. As for managed containers, you don't really have to use it, it's an optional feature, you can deploy your own k8s services via kubectl/helm and use their hostnames as upstreams for Octelium Services to be protected like any other upstream. Managed containers are meant to automate the entire process of spinning up containers/scaling up and down and eventually cleaning up the underlying k8s pods and deployments once you're done with the owner Octelium Service.
2. Secret management in Octelium is by default stored in plaintext. That's a conscious and deliberate decision as declared in the docs because there isn't any one standard way to encrypt Secrets at rest. Mainline Kubernetes itself does exactly the same and provides a gRPC interface for interceptors to implement their own secret management (e.g. HashiCorp Vault, AWS KMS/GCP/Azure offerings, directly to software/hardware-based HSMs, some vault/secret management vendor that I've never heard of, etc...). There is simply no one way to do that, every company has its own regulatory rules, vendors and standards when it comes to secret management at rest. I provided a similar gRPC interface for everybody to intercept such REST operations and implement their own secret management according to their own needs and requirements.
3. Octelium has Session resources https://octelium.com/docs/octelium/latest/management/core/se... Every User can have one or more Sessions, where every Session is represented by an opaque JWT-like access token, which are used internally by the octelium/octeliumctl clients after a successful login, they are also set as a HTTPOnly cookies for BeyondCorp browser-based Sessions and they are used directly as bearer tokens by WORKLOAD Users for client-less access to HTTP-based resources. You can actually set different permissions to different Users and also set different permissions for different Sessions for the exact same User via the owner Credentials or even via your Policies. OAuth2 client credential flow is only intended for WORKLOAD Users. Human Users don't really use OAuth2 client credentials at all. They just login via OIDC/SAML via the web Portal or manually via issued authentication token which is not generally recommended for HUMAN Users. OAuth2 is meant for WORKLOAD Users to securely access HTTP-based Services without using any clients or SDKs. OAuth2 scopes are not really related to zero trust at all as mentioned in the docs. OAuth2 scopes are just an additional way for applications to further restrict their own permissions, not add new ones which are already set by your own Policies.
4. An Octelium Cluster runs on top of a k8s cluster. In a typical multi-node production k8s cluster, you should use at least one node for the control plane and another separate node for the data-plane and scale up if your needs grow. A knowledge with Kubernetes isn't really required to manage an Octelium Cluster. As I mentioned above, Octelium resources and k8s resources are completely separate. One exception when it comes to directly having to deal with the underlying k8s cluster, is setting/updating the Cluster TLS certificate, such cert needs to be fed to the Octelium Cluster via a specific k8s secret as mentioned in the docs. Apart from that, you don't really need to understand anything about the underlying k8s cluster.
5. To explain Octelium more technically from a control plane/data plane perspective: Octelium does with identity-aware proxies similarly to what Kubernetes itself does with containers. It simply builds a whole control plane around the identity-aware proxies which themselves represent and implement the Octelium Services, and automatically deploys them whenever you create an Octelium Service via `octeliumtl apply` commands, scales them up and down whenever you change the Octelium Service replicas and eventually cleans the up whenever you delete the Octelium Service. As I said it's similar to what k8s itself does with containers where your interactions with the k8s API server whether via kubectl or programmatically is enough for the k8s cluster to spin up the containers, do all the CRI/CNI work for you automatically without even having to know or care which node actually runs a specific container.
As for the suggestions:
1. I am not really interested in SaaS offerings myself and you can clearly see that the architecture is meant for self-hosting as opposed to having a separate cloud-based control plane or whatever. I do, however, offer both free and professional support for companies that need to self-host Octelium on their own infrastructure according to their own needs.
2. I am not sure I understand this one. But if I understood you correctly, then as I said above, Octelium resources are completely different and separate from k8s resources regardless of the visual YAML resources. Octelium has its own API server, rscServer, data store, and it does not use CRDs or mess with k8s data store whether it be etcd or something else.
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.
“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.”
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.
I think the issue here is that while these terms may be very familiar to you (and to me personally also), they are not at all familiar to most people who will encounter your project.
Thus, those people coming across your project may quickly overlook it instead of giving it a chance which is disappointing.
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. That user then doesn't need to know any technical jargon or how it works under the hood or even what wireguard is at all. The tagline is what prompts them to install and try it out and from there the UX is the deciding factor in whether they keep using it or not.
Thank you. I completely understand your point. But as 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. For example, Humans can just use their browsers to access internal resources behind NAT like a typical protected SaaS resource. Workloads written in any programming language can access protected HTTP/gRPC APIs, Kubernetes, etc... via standard OAuth2 and bearer authentication without using any clients or special SDKs even such protected resources are protected by different API keys/access tokens.
But that's what I'm getting at. Even if it is much more, is all of that immediately relevant to a curious/potential new user?
I understand it may not be easy to narrow down the explanation, especially if you invested a lot of time and don't want to do a disservice to yourself by underselling it. Looking at the Tailscale tagline I quoted, it is small and ambiguous enough that it works marketing wise, regardless of all the features and solutions they offer. But it was just an example, I should maybe have used a totally different example of a product that is not in the same realm as yours.
The explanation you gave to me here is good but only because I vaguely know what all this jargon means. Try to think of a short simple sentence that a non-expert could understand.
I am sorry that you find whatever I say as nothing but "jargon". I assume that those interested in Octelium are already interested in zero trust architectures as defined by NIST, simply products such as Cloudlfare Access, Teleport, StrongDM, Google BeyondCorp, Zscaler ZTNA, etc... I will do my best to simplify the README soon.
I am the potential target audience and I assure you it's understandable and clear.
I share some (very little) from some of the criticism regarding the clarity, but I disagree you need a tagine like Tailscale while your solution does several times more things.
Great product, im chewing through the docs already :)
Thank you. You're welcome to ask any questions regarding the internals of Octelium via the emails or Slack/Discord channels. You can find all the contact links in the repo's README or on the website.
I wouldn't take this line of thinking too much to heart. At some point, a piece of technology is too complex for a person to parse what it means without sufficient background in this space. The "buzzwords" simply aren't buzzwords; you are using real words that accurately describe the project. People look at them, and either don't have sufficient knowledge to parse them in context, or are used to seeing them co-opted for use in low-effort marketing. I have some experience in this space (not a whole lot), and I was able to understand.
I like where you are going with the graphics in the readme; I'd spend some effort on creating "intended usecase" scenarios, scenarios that highlight situations where the project is the perfect fit. Using a few of these to highlight very different applications give people a good mental map of where this project would fit well for them.
"John is looking for a way to provide access to an internal tool to work-from-home colleagues. This isn't simple to do because [...]. Octelium is a good fit because [...]. Here is how John would set it up: [...]"
What you took away from that was that “next-gen” was the problem?
Buzzwords can still be technically accurate and you seem to be ignoring that when it keeps being confronted. “But it is” doesn’t matter when it comes to “but it sounds like”.
Let me give you an example; if I was walk into a store, do you think I want to talk to the person who talks about the “bidirectional optoelectromechanical document transcription and reproduction apparatus implementing discrete photonic acquisition and microdeposition techniques for bidimensional substrate encoding”, or do I want to talk to the person who will sell me a “photocopier”?
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."
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.
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!)”
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.
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!
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.
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.
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.
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.
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.
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.
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:
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.
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...
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.
You’re getting a lot of negative feedback but I think it’s mostly just people who don’t speak (or actively hate) enterprise jargon. Hacker News is not super enterprisey. Just don’t respond. I work for a company called StrongDM and we basically do exactly what Octelium does. I was able to determine that pretty quickly from your website which is not common. Enterprise security is just inherently a buzzwordy, vague cloud of companies all competing to own the magic quadrant.
That said, you are also including some buzzwords on your homepage that appeal to Hacker News folks, like “self-hosted”. That will get a blank stare from enterprise folks.
So I think you should pick one audience or the other. Tailscale took the strategy of appealing to Hacker News types and then shifting up market from there. My company appeals directly to the biggest enterprises we can find and the difference is stark.
I think you’ll get less negative feedback if you choose one of these target audiences and focus on them exclusively.
edit: by the way, Octelium looks awesome, well done!
Thank you really for your kind comment. I am not really against negative comments because they might actually lead to improvements. And btw I am personally a fan of what StrongDM has been doing lately especially when it comes with ABAC and Cedar. This is what I've been trying to achieve in Octelium with CEL and OPA.
I wonder why people keep building more. I know each has its own quirks and things they're better at, but the difference is really quite minimal.
One of the things I really would like is zero-trust 'lighthouses'. With current Zerotier and Tailscale, you really have to trust them because they can add nodes on your account whenever they want. I don't want that, I want fully self-hosted and for the lighthouses to just coordinate but not to be part of the network. I have to do some research to see what would be best.
Reading through the docs. 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)
To build a proxy that is protocol aware, only solves half the problem. It gets you some coarse grain decision making and a good logging story.
To build a proxy that is also able to perform type-inference at the request layer, allows for a much richer authZ story. One where businesses can build an authorization layer at the proxy better than their in-house apps could even do natively. (As it turns out, having all the predicates of the request available to a policy engine is super useful).
The docs are a little verbose, the marketing maybe isn’t amazing. But this is inherently a complex problem. No one has fully solved.
Teleport was first to the market to OSS and commercialize a lot of these ideas.
StrongDM also is doing really interesting work in this space.
I wish Hashicorp had invested more in this space.
Thank you really for your comment. I was actually hoping myself to get more questions that are related to the internals and architecture of Octelium, especially from those who are familiar with commercial ZTAs such as Cloudflare Access, Teleport, StrongDM, Google BeyondCorp, Pomerium and many other ZTNA/BeyondCorp based solutions.
Happy to answer any questions regarding Octelium internals/architecture or regarding the project overall whenever you need to. You can find the project's Slack/Discord channels and contact emails in the repo's README or on the website.
I work for an enterprise and they don't want this. They still rely on traditional centralised VPNs. How they deal with this is enforcing then everywhere, even in the office. Though there they usually are only on in name.
I think the reason is that they want to inspect the traffic in central locations, if each endpoint is doing its own you need to log there which means you can't always access it immediately.
I do use Mesh VPNs privately and love them. I love the way I have this overlay, a personal network that works everywhere. My devices all keep the same address no matter where they are.
Depends on the industry. But many large enterprises in the Fortune 500 are actively trying to move away from your traditional VPN. (F5, Pulse, Cisco, etc).
Even with VPNs the question should be, what are we gating behind that VPN anyway. Does it actually give us the granularity of controls we want or is this all security theater. (Also what about hybrid infra, between the datacenter and cloud)
FWIW, my ideal architecture is Wireguard into Corp. (Ala CloudFlare Warp, Tailscale, etc) Corp doesn’t hold a ton of sensitive assets. Or put another way, it’s a lower trust tier.
And then using something like Teleport, Octelium, etc to reach production assets.
Admittedly no vendor product I’ve come across yet has bridged this gap nicely. The überProxy tend to focus on the application protocols they support. While the wireguard clients cares more about session control of the tunnel.
Really thoughtful take. That exact gap: bridging identity-aware tunneling (like WireGuard) with protocol-aware proxy decisions is exactly what we set out to solve with Border0.
We pair WireGuard-style tunnels with real-time identity (sso, device, group context) and protocol aware proxies for SSH, RDP, HTTP, psql, Mysql, mssql, ES, and Kubernetes. Our policy engine lets you write rules like “only the DBA group can run DELETEs in Prod” or “Support can exec into this pod,” and we log every query, command, or request, all tied back to the user and device.
Think of it as combining the modern VPN experience of Tailscale with the deep authZ and observability of Teleport. I call it VPN plus PAM. Would love your thoughts if you give it a look.
Oh yes I agree it's all theater. But we are a very big enterprise (though not big tech) but we're a very traditional company unfortunately.
We're also still working to go "on cloud" as our CIO wants. Because they want to be hip too.
Which in our case means lifting up an image of every server in our datacenter and moving it to a compute box on AWS that runs 24/7. This is not "cloud". It's just paying much more for someone else's server. There is no dynamic scaling or consumption-based billing. It's just setting money on fire so we can tick a box.
Of course we're also "on modern management" yet rely extremely heavily on SCCM policies. Always the same story here.
With all respect, regardless of the fact that Octelium can replace the products you just mentioned, its context of interest is much larger and focused towards zero trust rather than just merely a yet another VPN/a remote access tool to access internal resources. I'd really appreciate it if you could read the docs first so that you can understand the features and architecture of Octelium and what it is meant to be. 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...). The term is being however abused by the companies, some of which are extremely well funded, to distort reality and the fact that their products were not even built for zero trust. What these fake "zero trust" vendors are trying to achieve is something like: "either we all are zero trust, or zero trust doesn't really exist or mean anything at all and it's merely a buzzword, it's your choice".
Look into sanctum [1] it's cathedral mode. You can self-host those entirely and they're only discovery nodes. Once the tunnel is up the cathedral isn't involved unless for black key distribution or if your peers are behind restrictive NAT.
There's reliquary [2] which I host and run for me and my hacker friends based on sanctum.
what if this wasnt something you add after infra but the checkpoint you start with. right now you spin up a vm or db then wrap vpn or firewall around it. but imagine writing access rules first in way : 'team ml can hit service x' or 'web app can hit this backend' and the system wires infra from that.. infra becomes a side effect of access intent. access isnt something you cant guard always( as things move fast, breaks fast), it's may become seed where you can design with.
If I did understand your point then Octelium actually tries to do what you want to see, at least to a certain extent via managed containers. For example, Octelium can deploy, scale and manage your containerized applications (e.g. web apps, APIs, databases or even PiHole DNS servers) and automatically serve and protect them as Octelium Services. Once you're done with the Service with whatever reason, all the underlying managed container infrastructe is automatically cleaned up. You can see some examples from the docs here:
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!
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.
Hopefully their tolerance to self-hosters (Headscale) doesn't change.
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
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.
It’s especially when they conquer the whole market. It’s why investors favor growth and adoption, even at a loss, until it’s won the market and can turn up the monetization dial.
Well, they do it anyway.
All the streaming services are enshittifying, even the smaller ones. And other smaller webshops are enshittifying the same way that Amazon does. Like Cory Doctorow described, there's a few big webshops in the Netherlands like bol.com and coolblue.com and they are now also allowing third party sellers, often even from China. The webshops are absolved of all responsibility but they do cash out on every transaction.
The term 'enshittification' sounds negative for what an organization needs to do to take care of employees.
Sorry no. A stable organization with a good profit margin is enough to take care of employees and pay their salaries. Boundless growth which is what enshittification is associated with, is driven by money-hungry stakeholders and “investors” that demand an ever growing return on investment - they don’t settle for speed, they need constant acceleration.
Isn’t it more of an “all of the above”?
A lot of employees at successful startups & FAANG make most of their money from the stock, no? And they need to buy houses and send their kids to fancy schools too, no? So sure, we can reduce it to stock holders, but I’d bet dollars to donuts the 90% of employees who aren’t posting on hn are at least passively ok with “improving metrics”, and some ambitious ones are driving the enshittification initiatives hard.
IMO the reason devs started being paid in stock in the first place is VC-style grow at all costs mentality. The fundraising economy didn’t work without fabricating compensation and only paying out on hits.
No other industry operates with such a blurred distinction between employees and owners. Well, save for the gig economy, itself a tumor on American-style big tech.
It's the American mentality. More, more, more.
Personally I'd be much happier with a stable income with not much upward mobility but also not much risk of falling downwards. Which is what Europe is geared more towards. I don't constantly want to be in a race. Just to live my life.
If they employees want it, fine but don't be surprised if we customers start finding alternatives. And/or pirating their content (e.g. when it comes to streaming services).
But yeah American companies aren't there to support the employees. The only one they answer to are the owners or large shareholders (whichevery applies), and their only goal is to make those richer. Customers and employees alike are nothing but consumables, a raw resource you only treat right if you can't avoid it.
They seem to be fine with it: "You could alternatively host your own trusted control server with Headscale."[1]
[1] https://tailscale.com/blog/tailnet-lock-ga#self-hosting
They're fine with it now. They won't be, when the next potential revenue source on their list is to crack down on it.
Remember, revenue must always increase, and must always increase faster than the year before (and this is more important than keeping the company alive), so companies always try increasingly desperate measures. Right now they are nowhere near the point of that particular measure. But they will be in the future.
There is https://netbird.io
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.
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).
there is also the chinese EasyTier https://easytier.cn/en/
See Nebula by slack
Netbird is nipping at their heels
I’ve been meaning to explore Netbird. Fewer features at the moment, but can be fully self hosted.
Their mobile android app is awful.
We have just published our android app rework for testing. Mind trying it out? Appreciate the feedback
https://www.reddit.com/r/netbird/s/lRjyehCQFi
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.
Isn't the client entirely OSS? - https://github.com/tailscale/tailscale
IIRC it’s just the macOS GUI client that’s closed source? I are the CLI client (CLIent?) compiled from source.
EDIT: yep, referenced in your link! They have a very clear page[0] describing what is and isn’t open source.
[0] https://tailscale.com/opensource
Programmable network tunnel fabric.
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.
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.
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.
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.
Don’t let these comments get to you.
If they don’t trust you, it’s their right, but then they should just not use the software, instead of writing this type of caustic comments. Poor form in my view.
Keep up, it looks amazing!!
If anything I am actually thankful to HN for the opportunity letting me show my work here. Negative comments are not really that big of an issue for me. I just wish they were generally clearer and more specific so that I can easily fix whatever needs to be fixed. Most of the complaints were simply related to the README while I was expecting and honestly hoping for critique for the architecture and internals of Octelium itself.
That is sort of the point of what you are considering “negative” comments. For clarity, my comment was advice on how you can improve the public persona of your project.
You seem to have pointed out but equally not registered that you identified exactly the issue: if your readme is filled with red flags, no one is going to invest their time (which is what you are asking for) looking at your code or trying it.
I completely understand as a developer how the “marketing” (readme) of a project may not seem that important or that it should be super accurate, and that it can be easy to fall into the pattern (as can be seen) of looking at every comment that brings voice to criticisms as being “negative”. You’re simply too close to the problem and are therefore only seeing the trees for the forest, while everyone is trying to tell you that you should probably remove the giant fence in front of the trees.
Thank you again. I meant by "negative" that they are critical as opposed to insulting. As I mentioned before in this thread, I usually don't find negative/critical comments offensive at all. Believe me, the last thing that I would want for an open source project that I have been working on for years now is to show it to people, especially technical people, with poor wording or hard-to-understand terms. That was never intentional by me. In fact, the reason that README is too long is that I wanted to explain all the features and use cases in detail while add additional links to the docs for those who want to understand more which probably made it even more overwhelming for those unfamiliar with zero trust architectures. I will definitely do my best to improve the README and docs with time as I get more honest feedback like in this thread. Thank you.
If these comments are “caustic” I’d recommend steering well clear of…the rest of the internet. These comments, from my perspective, represent a very pragmatic position from people who encounter scam bait daily in these same forums.
Should you be paranoid nowadays? yes you should.
Should a user call people posting their software here state actors and the such? I really don’t think it helps anyone.
Rather, they should lay out thier points, suggest how the author could change their mind. Alternatively direct their warning to others if they feel their conviction that this is malware is unshakable.
Given the nature of the proposed software, and reading through their other replies, its a legitimate concern.
[dead]
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.
I use those but I still don't understand what Octelium does or doesn't
> 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)
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.
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.
<https://tailscale.com/blog/ai-normal>
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.
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.
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.
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.
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.
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.
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.
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
Thank you so much. I will definitely contact you very soon.
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.
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.
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.
headscale is an open source alternative to tailscale:
https://github.com/juanfont/headscale
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.
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."
So if you are running a closed source OS, Tailscale doesn’t have an open source client? Wouldn’t closed source OS users of Tailscale benefit the most from having an open source Tailscale client available?
> So if you are running a closed source OS, Tailscale doesn’t have an open source client?
As the content at the link makes crystal clear, the client is open source. Additionally, Tailscale's GUI for that client is open source on open source platforms.
99.999% of users of closed source OSs aren't going to care that the GUI isn't open source. The remaining 0.001% just use the open source client without the GUI.
> 99.999% of users of closed source OSs aren't going to care that the GUI isn't open source.
They may or may not care, but just so we’re all on the same page, there isn’t an open source version of the end user application software for closed source operating systems that I can find on that page or any other Tailscale page. If one exists, I am happy to be corrected by you, and I am giving you the opportunity to do so now.
In the spirit of inclusiveness to non-technical folks who are flummoxed by CLIs but also have a religious objection to running closed software on their closed source OS, I'd recommend that they ask a more technically-inclined friend to set up the open source Tailscale client software with Cattail if they're on Windows, or an Automation that drives the CLI if they're on macOS.
> This is HN, ain't nobody here afraid of a CLI.
Gatekeeping much?
> If (1) you personally need a GUI and (2) have a religious objection to running closed software on your closed source OS, ask a more technical friend to set up Cattail if you're on Windows, or an Automation that drives the CLI if you're on macOS.
I’m just asking if Tailscale has an open source application. Users who know what a GUI is and why it’s also important that it is open source will care that the GUI isn’t open source. The ones who don’t, won’t. Who benefits from obscurantist-posting like you are doing? Probably not the folks who don’t know that Tailscale doesn’t have an open source app, because the GUI is part and parcel to what the app even is conceptually to the sorts of users who don’t know what GUIs are.
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."
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)?
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.
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.
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.
>easy p2p connectivity
>centralized router(s)
When using Tailscale, your packets may be sent through centralized routers, FYI.
https://tailscale.com/kb/1257/connection-types
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!
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.
As the other commenters have pointed out, your README is offputting.
Last year I wrote an article about how to write a good README:
https://sneak.berlin/20241224/readme-howto/
Thank you. I will definitely work on making the README more concise and hopefully more useful and easy to understand.
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.
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.
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.
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.
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.
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.
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.
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.
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...
I’ll be keeping an eye on this, but I’ve gotta say, first glance it just seems like it does way too much, and all by a solo dev in private? Impressive but also perturbing.
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 asssurance and not go with the open source option?
Not sure if your project solves any issue of a singular dev.
Octelium itself is designed to be a generic secure access platform that can operate in many environments (from a simple ngrok-tier remote access tool, remote access/corporate VPN up to a full-fledged scalable ZTNA/BeyondCorp platform among many other specific use cases such as API/AI/MCP gateways) at many levels (i.e. dev, startup, enterprise). Think of Kubernetes, you can use it to host a single website running on a single container, you can use it as an API gateway for a few microservices and you can use it as a fully-featured service mesh of hundreds if not thousands of microservices running on tens if not hundreds of nodes with enterprise-level tools such as SPIFFE, Istio, etc...
I just use some tools to automate configuration of a wireguard mesh overlay network. It doesn't seem like it should need to be harder than that.
OP this looks insane, very broad set of functionality.
Im going to run this on my k8s, congratz for now.
One takeaway is that this can replace ZLayer, and it does offer much more functionality than that. Is that correct?
How does it compare to Pangolin?
Well I haven't used Pangolin myself, but Octelium can basically operate as a similar self-hosted remote access tool. It is designed however, to provide much more than just remote access. It provides L7-aware, context-aware ABAC-based access control, it provides L7-aware secretless access without distributing L7 credentials to users, it provides dynamic routing/configuration to upstreams and upstreams credentials based on identity/context, it provides OpenTemeltry-read L7 aware visibility and auditing. Therefore, it's more closer to Cloudflare Access, Teleport Enterprise, StrongDM, etc... than to Pangolin. However, it's also not just a ZTNA in the rigid sense, for example, your applications written in any programming language can just generate fine-grained bearer authentication access tokens via OAuth2 client credentials flow to access protect Services without having to use clients or special SDKs or being aware of Octelium at all. Octelium also operate on top of Kubernetes which makes it seamless for you to provide horizontal scalability and availability as your Cluster's Services, Users, Sessions and simply traffic grow.
since I had to ggole it https://github.com/fosrl/pangolin
Tunneled Reverse Proxy Server with Access Control - your own self-hosted zero trust tunnel. AGPL3
Can you use VPNs outside of your infra (e.g. protonvpn, mullvad) as an exit node?
Interesting. One way to do that in Octelium is via a SOCKS5 proxy served as an Octelium Service. In fact the Octelium Cluster nodes itself can operate as exit nodes directly and you can use that as a form of consumer VPN. You can even deploy and scale TOR containers over Octelium and have load balanced TOR.
This is similar to the current set up I have with tailscale, but it's not ideal, hence why i asked.
Can I ask you what an ideal setup for your use case would look like? Octelium isn't really concerned with connecting complete remote subnets to each other directly. You can simply use a SOCKS5 proxy as an Octelium Service and do all the access control, dynamic routing and load balancing to that Service representing a specific "VPN".
So this is something like pinggy.io - self hosted?
Yes, it can operate as a self-hosted ngrok, pinggy, Cloudflare Tunnel with Github/OpenID Connect/SAML SSO and it can also provide anonymous public access, which can be useful for public website/API hosting, among many other use cases. You can see the examples https://octelium.com/docs/octelium/latest/management/guide/s... and https://octelium.com/docs/octelium/latest/management/guide/s...
I’m impressed with how helpful HN commenters are being despite the unilateral opinion about the pitch and readme.
For what it’s worth, the title of the post is a pretty good pitch. Leaving it at “FOSS Alternative to …” would be a step in the right direction.
Ah yes, use a no-name do-all program for securing my network instead of headscale, a proven and battle tested wireguard mesh
I think a lot of other commentors here are more taking issue with the concept of ZTNs in general and may not have used them at scale, or at all. The intro is buzzword heavy, however I don't think that's an issue with your documentation, just the terminology of the space Octelium operates in which came from big business and was conceived as buzzwords to start with so there's not a lot of flexibility to use alternate terms that make sense.
Your documentation is extremely detailed and generally excellent. It does seem to be targeted at people who have already deployed Octelium or are very familiar with ZTN-style deployments. It's quite fractally dense (you stumble over one new term, need to go to another docs page, which is as long, that has more terms you need to read about, etc.) so as you've mentioned the issue really isn't your product but likely conveying what it does in a clear manner.
If you want to get general devs and homelabbers on board with the concept or testing this out, which I imagine is a very different target to your initial versions, maybe you could prefix your GitHub readme with something like:
"Octelium is a free and open source zero trust network platform. It integrates and manages your Kubernetes (and other container orchestration) applications to provide single point of authentication for all services. Your users log in once to one authentication provider such as a managed provider like Okta or any other OAuth OpenID compatible service and then your users are automatically granted their correct access levels to all your web services, databases, SSH, VPNs and more. Log in once, access everything, self-hosted."
When reading your documentation I immediately had a number of questions that were not clearly answered. That doesn't mean to say the answer isn't in your documentation, it's just that after 15-20 minutes of reading I still didn't have a clear answer. I'm reading this from the perspective of someone very familiar with operating Kubernetes clusters at scale and dabbled quite a bit with some of the commercial ZTN offerings. Apologies if the questions below are answered in your docs, I didn't find them in the time I had.
1) Your initial setup guides go from how to install Octelium to immediately scheduling services via YAML as a direct replacement for, I assume, something like deployments on k8s. Does Octelium actually run workloads? Is it 1:1 compatible with k8s API spec? Does it just talk to k8s over the API and effectively rewrite deployment YAML and spam it to k8s? Immediately this has concerns, why do I want this? Do I trust Octelium to manage deployments for me? Replacing a vast part of the k8s stack with Octelium tooling is a big ask for even small companies to trial. There's also just straight upstream connections, why would I want to let Octelium manage workloads over just using an internal k8s service hostname so I don't have to effectively rebuild the entire application around Octelium? Does letting Octelium manage workloads impact anything else (monitoring, logging, any other deployment tools that interact with k8s - if some CI/CD pipeline updates a container image does Octelium "know" or is it out of date?). What about RBAC stuff? Namespaces? Are these 1:1 k8s compatible?
2) If I work for BigCorp I'm going to have things like compliance issues coming out of my ears, your Services store credentials in plain text which is going to be flagged immediately. No-one is going to offload SSH authentication if root SSH keys are stored in plain text in secrets somewhere. I did note there's the option to effectively write your own gRPC interfaces to handle secure secrets storage but this seems like a pretty big hurdle. You then basically say "if you're enterprise we can help here" at the bottom, but I wouldn't even test this myself on a homelab without some sort of more sane basic secret management.
3) How, specifically, does Octelium handle HTTP upstream service issues? For example, if I'm proxying my companies connections to saas.com via saas.myintranet.example.com I assume I lose the ability to apply 2fa to user accounts? It's unclear from the documentation, can I specify unique credentials per user? How would I manage those? Is the only option OAuth and scopes? What if the upstream doesn't support OAuth? It's fine if upstream services need to support OAuth to support the most seamless and secure ZTN-style experience, it's just not that clear how these things work in practice.
4) You re-use a lot of terms from k8s (cluster, service etc.) which are subtly different k8s, this could cause confusion with a lot of k8s trained admins. For example, I believe an Octelium cluster is a k8s cluster running multiple Octelium instances and a custom data plane, this different enough to what a k8s cluster is to potentially be confusing as it's a different logic level. I appreciate there are limited generic descriptive terms in the dictionary to describe these things.
5) How, technically, does some of this stuff work? I know I can browse the repo or read the extensive documentation, but it would be helpful to have some clear "k8s admin"-targeted terms like, we install X proxy that does Y, using Z certificates, services managed by Octelium get a sidecar that intercepts connections to proxy them back into the ZTN, or whatever magic it does in clear, k8s, terms. If I'm looking after something like this I would need to know it inside-out, what if some certificate stops working? If I don't know exactly where everything is how can I debug it? If I deployed this it would be absolutely mission-critical, if it breaks the entire company immediately breaks. If that happens for a couple of days, realistically it can be business-terminating.
What would be really helpful to see would be some documentation with step by step guides on going from a starting point to what an Octelium-powered endgame would look like. For example, if I'm the CTO of a business that has some remote managed k8s clusters running our public SaaS along with some tooling/control panels/etc, and then a big server in my office running some non-critical but important apps via Podman, and 15 remote users that currently connect over a Tailscale VPN into the office, and 20+ upstream external web services that provide support ticketing, email, etc. then what does this look like after I "switch" to Octelium? Before and after comprehensive diagrams, and maybe even a little before-video of someone logging in via a VPN then logging into 15 control panels vs an after-video with someone logging into an intranet and just everything magically appearing would be nice. You need to sell something of this scale to CTOs, not engineers.
Generally, however, my personal biggest flag with this would be that it requires effectively a total rebuild of all infrastructure, learning entirely new tooling, management and oversight. It's a lot to ask and it doesn't seem like it can be that gradually rolled out. I suppose you could set up a second k8s cluster, deploy Octelium on it and then slowly migrate services over, but that's going to be expensive.
Some suggestions:
1) You have built a very impressive toolkit, why not operate this as a SaaS using your toolkit (with on-prem open source extensions)? You don't seem to have an actual product, you have a swiss army knife of ZTN tools which is way more work so hats off to you there. It seems you're partitioning this with "the toolkit is public, write your own glue for free, to get a working platform, come pay us" which is perfectly fine, the issue there is your "enterprise" offerings seem to be even more toolkit options rather than an actual offering. Bundle in some actual enterprise tools (fancy log tool with a web UI that also does user management and connection monitoring as a single dashboard?) and it would be a lot more appealing.
2) You require replacing industry standard technologies like directly managing k8s with kubectl with your own platform and tools - replacing "the way that everyone does X" with "new tool from relatively unknown ZTN provider" is going to be tough to sell. Can you make your octeliumctl tool a kubectl plugin? Could Octelium be less control-everything and just sit on top k8s rather than seemingly replace a lot of it?
Edit: 3) Have a homelabber edition, if that's a market you want to target, that's way easier to install and works in a single docker container or something (sacrificing some of the redundancy) but offers a basic complete suite of services (dashboard, HTTP upstream proxying, VPN) with a single "docker run...".
Good luck with Octelium, it's certainly interesting and I'll keep an eye on it as it evolves.
Reminds of the confusion when https://openziti.io/ shared on HN a while back. ZTN is a very different beast than WireGuard-derivatives.
Thank you really for your detailed comment. I will try to answer your questions and please don't hesitate to ask in the Slack/Discord channels or contact emails later if the answers here weren't clear enough to you.
1. Octelium Services and Namespaces are not really related or tied to Kubernetes services and namespaces. Octelium resources in general are defined in protobuf3 and compiled to Golang types, and they are stored as serialized JSON in the Postgres main data store simply as JSONB. That said, Octelium Services in specific are actually deployed on the underlying k8s cluster as k8s services/deployments. Octelium resources visually look like k8s resouces (i.e. they both have the same metadata, spec, status structure), however Octelium resources are completely independent of the underlying k8s cluster; they aren't some k8s CRDs as you might initially guess. Also Octelium has its own API server which do some kind of REST-y gRPC-based operations for the different Octelium resources to the Postgres via an intermediate component called the rscServer. As I said, Octelium and k8s resources are completely separate regardless of the visual YAML resemblance. As for managed containers, you don't really have to use it, it's an optional feature, you can deploy your own k8s services via kubectl/helm and use their hostnames as upstreams for Octelium Services to be protected like any other upstream. Managed containers are meant to automate the entire process of spinning up containers/scaling up and down and eventually cleaning up the underlying k8s pods and deployments once you're done with the owner Octelium Service.
2. Secret management in Octelium is by default stored in plaintext. That's a conscious and deliberate decision as declared in the docs because there isn't any one standard way to encrypt Secrets at rest. Mainline Kubernetes itself does exactly the same and provides a gRPC interface for interceptors to implement their own secret management (e.g. HashiCorp Vault, AWS KMS/GCP/Azure offerings, directly to software/hardware-based HSMs, some vault/secret management vendor that I've never heard of, etc...). There is simply no one way to do that, every company has its own regulatory rules, vendors and standards when it comes to secret management at rest. I provided a similar gRPC interface for everybody to intercept such REST operations and implement their own secret management according to their own needs and requirements.
3. Octelium has Session resources https://octelium.com/docs/octelium/latest/management/core/se... Every User can have one or more Sessions, where every Session is represented by an opaque JWT-like access token, which are used internally by the octelium/octeliumctl clients after a successful login, they are also set as a HTTPOnly cookies for BeyondCorp browser-based Sessions and they are used directly as bearer tokens by WORKLOAD Users for client-less access to HTTP-based resources. You can actually set different permissions to different Users and also set different permissions for different Sessions for the exact same User via the owner Credentials or even via your Policies. OAuth2 client credential flow is only intended for WORKLOAD Users. Human Users don't really use OAuth2 client credentials at all. They just login via OIDC/SAML via the web Portal or manually via issued authentication token which is not generally recommended for HUMAN Users. OAuth2 is meant for WORKLOAD Users to securely access HTTP-based Services without using any clients or SDKs. OAuth2 scopes are not really related to zero trust at all as mentioned in the docs. OAuth2 scopes are just an additional way for applications to further restrict their own permissions, not add new ones which are already set by your own Policies.
4. An Octelium Cluster runs on top of a k8s cluster. In a typical multi-node production k8s cluster, you should use at least one node for the control plane and another separate node for the data-plane and scale up if your needs grow. A knowledge with Kubernetes isn't really required to manage an Octelium Cluster. As I mentioned above, Octelium resources and k8s resources are completely separate. One exception when it comes to directly having to deal with the underlying k8s cluster, is setting/updating the Cluster TLS certificate, such cert needs to be fed to the Octelium Cluster via a specific k8s secret as mentioned in the docs. Apart from that, you don't really need to understand anything about the underlying k8s cluster.
5. To explain Octelium more technically from a control plane/data plane perspective: Octelium does with identity-aware proxies similarly to what Kubernetes itself does with containers. It simply builds a whole control plane around the identity-aware proxies which themselves represent and implement the Octelium Services, and automatically deploys them whenever you create an Octelium Service via `octeliumtl apply` commands, scales them up and down whenever you change the Octelium Service replicas and eventually cleans the up whenever you delete the Octelium Service. As I said it's similar to what k8s itself does with containers where your interactions with the k8s API server whether via kubectl or programmatically is enough for the k8s cluster to spin up the containers, do all the CRI/CNI work for you automatically without even having to know or care which node actually runs a specific container.
As for the suggestions:
1. I am not really interested in SaaS offerings myself and you can clearly see that the architecture is meant for self-hosting as opposed to having a separate cloud-based control plane or whatever. I do, however, offer both free and professional support for companies that need to self-host Octelium on their own infrastructure according to their own needs.
2. I am not sure I understand this one. But if I understood you correctly, then as I said above, Octelium resources are completely different and separate from k8s resources regardless of the visual YAML resources. Octelium has its own API server, rscServer, data store, and it does not use CRDs or mess with k8s data store whether it be etcd or something else.
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.
I'd appreciate if you could provide me a list of those buzzwords so that I can improve the readme.
“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
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.
I think the issue here is that while these terms may be very familiar to you (and to me personally also), they are not at all familiar to most people who will encounter your project.
Thus, those people coming across your project may quickly overlook it instead of giving it a chance which is disappointing.
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. That user then doesn't need to know any technical jargon or how it works under the hood or even what wireguard is at all. The tagline is what prompts them to install and try it out and from there the UX is the deciding factor in whether they keep using it or not.
Thank you. I completely understand your point. But as 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. For example, Humans can just use their browsers to access internal resources behind NAT like a typical protected SaaS resource. Workloads written in any programming language can access protected HTTP/gRPC APIs, Kubernetes, etc... via standard OAuth2 and bearer authentication without using any clients or special SDKs even such protected resources are protected by different API keys/access tokens.
But that's what I'm getting at. Even if it is much more, is all of that immediately relevant to a curious/potential new user?
I understand it may not be easy to narrow down the explanation, especially if you invested a lot of time and don't want to do a disservice to yourself by underselling it. Looking at the Tailscale tagline I quoted, it is small and ambiguous enough that it works marketing wise, regardless of all the features and solutions they offer. But it was just an example, I should maybe have used a totally different example of a product that is not in the same realm as yours.
The explanation you gave to me here is good but only because I vaguely know what all this jargon means. Try to think of a short simple sentence that a non-expert could understand.
I am sorry that you find whatever I say as nothing but "jargon". I assume that those interested in Octelium are already interested in zero trust architectures as defined by NIST, simply products such as Cloudlfare Access, Teleport, StrongDM, Google BeyondCorp, Zscaler ZTNA, etc... I will do my best to simplify the README soon.
I’ve read “zero trust” more times today, than ever before in my life. Still don’t know what this project does.
I am the potential target audience and I assure you it's understandable and clear.
I share some (very little) from some of the criticism regarding the clarity, but I disagree you need a tagine like Tailscale while your solution does several times more things.
Great product, im chewing through the docs already :)
Thank you. You're welcome to ask any questions regarding the internals of Octelium via the emails or Slack/Discord channels. You can find all the contact links in the repo's README or on the website.
I wouldn't take this line of thinking too much to heart. At some point, a piece of technology is too complex for a person to parse what it means without sufficient background in this space. The "buzzwords" simply aren't buzzwords; you are using real words that accurately describe the project. People look at them, and either don't have sufficient knowledge to parse them in context, or are used to seeing them co-opted for use in low-effort marketing. I have some experience in this space (not a whole lot), and I was able to understand.
I like where you are going with the graphics in the readme; I'd spend some effort on creating "intended usecase" scenarios, scenarios that highlight situations where the project is the perfect fit. Using a few of these to highlight very different applications give people a good mental map of where this project would fit well for them.
"John is looking for a way to provide access to an internal tool to work-from-home colleagues. This isn't simple to do because [...]. Octelium is a good fit because [...]. Here is how John would set it up: [...]"
What you took away from that was that “next-gen” was the problem?
Buzzwords can still be technically accurate and you seem to be ignoring that when it keeps being confronted. “But it is” doesn’t matter when it comes to “but it sounds like”.
Let me give you an example; if I was walk into a store, do you think I want to talk to the person who talks about the “bidirectional optoelectromechanical document transcription and reproduction apparatus implementing discrete photonic acquisition and microdeposition techniques for bidimensional substrate encoding”, or do I want to talk to the person who will sell me a “photocopier”?
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."
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.
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!)”
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.
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!
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.
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.
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.
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.
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.
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.
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 :)
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.
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...
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.
To be fair, I wouldn't call these buzz works, maybe just "next-gen".
Rather one could argue they are technical jargon? But then if the technical jargon is over someone's head, maybe they are not the target audience.
I understood most of it, but it is quite dense for the first paragraph.
"...to make the world a better place." was missing from this paragraph.
It is zero-trust.
I don't trust this.
You’re getting a lot of negative feedback but I think it’s mostly just people who don’t speak (or actively hate) enterprise jargon. Hacker News is not super enterprisey. Just don’t respond. I work for a company called StrongDM and we basically do exactly what Octelium does. I was able to determine that pretty quickly from your website which is not common. Enterprise security is just inherently a buzzwordy, vague cloud of companies all competing to own the magic quadrant.
That said, you are also including some buzzwords on your homepage that appeal to Hacker News folks, like “self-hosted”. That will get a blank stare from enterprise folks.
So I think you should pick one audience or the other. Tailscale took the strategy of appealing to Hacker News types and then shifting up market from there. My company appeals directly to the biggest enterprises we can find and the difference is stark.
I think you’ll get less negative feedback if you choose one of these target audiences and focus on them exclusively.
edit: by the way, Octelium looks awesome, well done!
Thank you really for your kind comment. I am not really against negative comments because they might actually lead to improvements. And btw I am personally a fan of what StrongDM has been doing lately especially when it comes with ABAC and Cedar. This is what I've been trying to achieve in Octelium with CEL and OPA.
There are so so many of these already...
- Tinc (the OG of P2P VPN)
- Hamachi (not open though)
- ZeroTier
- Nebula (from Slack)
- Tailscale
- Netbird
I wonder why people keep building more. I know each has its own quirks and things they're better at, but the difference is really quite minimal.
One of the things I really would like is zero-trust 'lighthouses'. With current Zerotier and Tailscale, you really have to trust them because they can add nodes on your account whenever they want. I don't want that, I want fully self-hosted and for the lighthouses to just coordinate but not to be part of the network. I have to do some research to see what would be best.
Reading through the docs. 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)
To build a proxy that is protocol aware, only solves half the problem. It gets you some coarse grain decision making and a good logging story.
To build a proxy that is also able to perform type-inference at the request layer, allows for a much richer authZ story. One where businesses can build an authorization layer at the proxy better than their in-house apps could even do natively. (As it turns out, having all the predicates of the request available to a policy engine is super useful).
The docs are a little verbose, the marketing maybe isn’t amazing. But this is inherently a complex problem. No one has fully solved.
Teleport was first to the market to OSS and commercialize a lot of these ideas. StrongDM also is doing really interesting work in this space. I wish Hashicorp had invested more in this space.
Disclaimer: my opinions are my own.
Thank you really for your comment. I was actually hoping myself to get more questions that are related to the internals and architecture of Octelium, especially from those who are familiar with commercial ZTAs such as Cloudflare Access, Teleport, StrongDM, Google BeyondCorp, Pomerium and many other ZTNA/BeyondCorp based solutions.
Will DM after I’ve had a chance to dig.
Happy to answer any questions regarding Octelium internals/architecture or regarding the project overall whenever you need to. You can find the project's Slack/Discord channels and contact emails in the repo's README or on the website.
I work for an enterprise and they don't want this. They still rely on traditional centralised VPNs. How they deal with this is enforcing then everywhere, even in the office. Though there they usually are only on in name.
I think the reason is that they want to inspect the traffic in central locations, if each endpoint is doing its own you need to log there which means you can't always access it immediately.
I do use Mesh VPNs privately and love them. I love the way I have this overlay, a personal network that works everywhere. My devices all keep the same address no matter where they are.
Depends on the industry. But many large enterprises in the Fortune 500 are actively trying to move away from your traditional VPN. (F5, Pulse, Cisco, etc).
Even with VPNs the question should be, what are we gating behind that VPN anyway. Does it actually give us the granularity of controls we want or is this all security theater. (Also what about hybrid infra, between the datacenter and cloud)
FWIW, my ideal architecture is Wireguard into Corp. (Ala CloudFlare Warp, Tailscale, etc) Corp doesn’t hold a ton of sensitive assets. Or put another way, it’s a lower trust tier.
And then using something like Teleport, Octelium, etc to reach production assets.
Admittedly no vendor product I’ve come across yet has bridged this gap nicely. The überProxy tend to focus on the application protocols they support. While the wireguard clients cares more about session control of the tunnel.
Really thoughtful take. That exact gap: bridging identity-aware tunneling (like WireGuard) with protocol-aware proxy decisions is exactly what we set out to solve with Border0.
We pair WireGuard-style tunnels with real-time identity (sso, device, group context) and protocol aware proxies for SSH, RDP, HTTP, psql, Mysql, mssql, ES, and Kubernetes. Our policy engine lets you write rules like “only the DBA group can run DELETEs in Prod” or “Support can exec into this pod,” and we log every query, command, or request, all tied back to the user and device.
Think of it as combining the modern VPN experience of Tailscale with the deep authZ and observability of Teleport. I call it VPN plus PAM. Would love your thoughts if you give it a look.
Quick 2-minute overview: https://www.youtube.com/watch?v=hU7QixSqnSM&t=3s
https://www.border0.com/
Oh yes I agree it's all theater. But we are a very big enterprise (though not big tech) but we're a very traditional company unfortunately.
We're also still working to go "on cloud" as our CIO wants. Because they want to be hip too.
Which in our case means lifting up an image of every server in our datacenter and moving it to a compute box on AWS that runs 24/7. This is not "cloud". It's just paying much more for someone else's server. There is no dynamic scaling or consumption-based billing. It's just setting money on fire so we can tick a box.
Of course we're also "on modern management" yet rely extremely heavily on SCCM policies. Always the same story here.
With all respect, regardless of the fact that Octelium can replace the products you just mentioned, its context of interest is much larger and focused towards zero trust rather than just merely a yet another VPN/a remote access tool to access internal resources. I'd really appreciate it if you could read the docs first so that you can understand the features and architecture of Octelium and what it is meant to be. 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...). The term is being however abused by the companies, some of which are extremely well funded, to distort reality and the fact that their products were not even built for zero trust. What these fake "zero trust" vendors are trying to achieve is something like: "either we all are zero trust, or zero trust doesn't really exist or mean anything at all and it's merely a buzzword, it's your choice".
[dead]
Look into sanctum [1] it's cathedral mode. You can self-host those entirely and they're only discovery nodes. Once the tunnel is up the cathedral isn't involved unless for black key distribution or if your peers are behind restrictive NAT.
There's reliquary [2] which I host and run for me and my hacker friends based on sanctum.
[1] https://github.com/jorisvink/sanctum
[2] https://reliquary.se
And many more: https://github.com/anderspitman/awesome-tunneling
what if this wasnt something you add after infra but the checkpoint you start with. right now you spin up a vm or db then wrap vpn or firewall around it. but imagine writing access rules first in way : 'team ml can hit service x' or 'web app can hit this backend' and the system wires infra from that.. infra becomes a side effect of access intent. access isnt something you cant guard always( as things move fast, breaks fast), it's may become seed where you can design with.
If I did understand your point then Octelium actually tries to do what you want to see, at least to a certain extent via managed containers. For example, Octelium can deploy, scale and manage your containerized applications (e.g. web apps, APIs, databases or even PiHole DNS servers) and automatically serve and protect them as Octelium Services. Once you're done with the Service with whatever reason, all the underlying managed container infrastructe is automatically cleaned up. You can see some examples from the docs here:
https://octelium.com/docs/octelium/latest/management/guide/s... https://octelium.com/docs/octelium/latest/management/guide/s... https://octelium.com/docs/octelium/latest/management/guide/s... https://octelium.com/docs/octelium/latest/management/guide/s...