For everyone who's having a hard time parsing what Octelium does, I found this page to be the clearest explanation: <a href="https://octelium.com/docs/octelium/latest/overview/how-octelium-works" rel="nofollow">https://octelium.com/docs/octelium/latest/overview/how-octel...</a><p>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.<p>And it actually looks pretty cool and useful! From what I can tell, the core funtionality is:<p>- 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<p>- A cluster configuration layer on top of Kubernetes<p>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 <i>especially</i> 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.<p>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”?<p>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.<p>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.<p>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.<p>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).<p>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]<p>[1] <a href="https://tailscale.com/blog/tailnet-lock-ga#self-hosting" rel="nofollow">https://tailscale.com/blog/tailnet-lock-ga#self-hosting</a>
They're fine with it <i>now</i>. They won't be, when the next potential revenue source on their list is to crack down on it.<p>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 <a href="https://netbird.io" rel="nofollow">https://netbird.io</a>
But there are so so many competing products already?<p>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 <a href="https://easytier.cn/en/" rel="nofollow">https://easytier.cn/en/</a>
Netbird is nipping at their heels
See Nebula by slack
I’ve been meaning to explore Netbird. Fewer features at the moment, but can be fully self hosted.
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.
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.<p>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.<p>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.<p>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.<p>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.<p>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.<p>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.<p>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.
If these comments are “caustic” I’d recommend steering well clear of…the <i>rest</i> 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.<p>Should a user call people posting their software here state actors and the such? I really don’t think it helps anyone.<p>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.
[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 <i>and</i> Free software. Take it as it is.<p>> If a software is hard to explain the purpose of to an average person in a single sentence, you have an uphill battle.<p>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<p>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!).<p>That's a big NOPE.<p>(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’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.
Here is some unsolicited advice on clarity.<p>Pick one or two descriptive phrases per subject. If you need more sentences, that's okay.<p>For example:<p>> 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.<p>-><p>"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."
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.<p>Even the diagrams for API vs AI gateways are almost identical.<p><<a href="https://tailscale.com/blog/ai-normal" rel="nofollow">https://tailscale.com/blog/ai-normal</a>>
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: <a href="https://octelium.com/docs/octelium/latest/management/guide/service/ai/ai-gateway" rel="nofollow">https://octelium.com/docs/octelium/latest/management/guide/s...</a>
As for the API gateway: <a href="https://octelium.com/docs/octelium/latest/management/guide/service/http/api-gateway" rel="nofollow">https://octelium.com/docs/octelium/latest/management/guide/s...</a><p>I am also working on extending the process of modifying HTTP requests/body content beside what's been provided (see more <a href="https://octelium.com/docs/octelium/latest/management/core/service/http" rel="nofollow">https://octelium.com/docs/octelium/latest/management/core/se...</a>). 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.
Definitely interested in an open source alternative to Tailscale.<p>The README is way too verbose though. It should explain the project at a glance and have links to docs for the details.
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)<p>Or put another way, I hope that Kubernetes integration is an option, not a prerequisite and the only supported deployment.<p>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 <a href="https://octelium.com/docs/octelium/latest/overview/how-octelium-works" rel="nofollow">https://octelium.com/docs/octelium/latest/overview/how-octel...</a><p>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.
The big thing to me about Tailscale is easy p2p connectivity. I <i>think</i> 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<p>>centralized router(s)<p>When using Tailscale, your packets may be sent through centralized routers, FYI.<p><a href="https://tailscale.com/kb/1257/connection-types" rel="nofollow">https://tailscale.com/kb/1257/connection-types</a>
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".<p>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 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 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.
Is this a replacement for a huge corpo botnet like access control?<p>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?<p>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...
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.<p>I scanned the github, and your reply above, and I still don't really get it.<p>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.<p>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.<p>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.
Please update your HN profile with contact information.<p>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.<p>We use Cloudron as our core PAAS and have been looking for a FLO zero trust / identity aware proxy for DB/RDP/SSH .<p>Happy to be your flagship customer.<p>We have a brand new k8s (self hosted) cluster deployed . We use wazuh as our SEIM, librenms for monitoring / alerting.<p>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).<p>Charles@turnsys.com reaches me pretty quickly most days. Would love to deploy this immediately and write a testimonial etc
Gentle feedback: if it’s hard to concisely define what Octelium is, it will be hard to convince people to use it.<p>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.
OP this looks insane, very broad set of functionality.<p>Im going to run this on my k8s, congratz for now.
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:<p><a href="https://octelium.com/docs/octelium/latest/management/guide/service/http/nextjs-vite" rel="nofollow">https://octelium.com/docs/octelium/latest/management/guide/s...</a>
<a href="https://octelium.com/docs/octelium/latest/management/guide/service/ai/remote-ollama" rel="nofollow">https://octelium.com/docs/octelium/latest/management/guide/s...</a>
<a href="https://octelium.com/docs/octelium/latest/management/guide/service/homelab/pihole" rel="nofollow">https://octelium.com/docs/octelium/latest/management/guide/s...</a>
<a href="https://octelium.com/docs/octelium/latest/management/guide/service/homelab/remote-vscode-code-server" rel="nofollow">https://octelium.com/docs/octelium/latest/management/guide/s...</a>
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.
One takeaway is that this can replace ZLayer, and it does offer much more functionality than that. Is that correct?
As the other commenters have pointed out, your README is offputting.<p>Last year I wrote an article about how to write a good README:<p><a href="https://sneak.berlin/20241224/readme-howto/" rel="nofollow">https://sneak.berlin/20241224/readme-howto/</a>
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 <a href="https://octelium.com/docs/octelium/latest/management/guide/service/http/nextjs-vite" rel="nofollow">https://octelium.com/docs/octelium/latest/management/guide/s...</a> and <a href="https://octelium.com/docs/octelium/latest/management/guide/service/http/open-source-self-hosted-ngrok-alternative" rel="nofollow">https://octelium.com/docs/octelium/latest/management/guide/s...</a>
I’m impressed with how helpful HN commenters are being despite the unilateral opinion about the pitch and readme.<p>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.
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
<a href="https://github.com/fosrl/pangolin">https://github.com/fosrl/pangolin</a><p>Tunneled Reverse Proxy Server with Access Control - your own self-hosted zero trust tunnel.
AGPL3
Ah yes, use a no-name do-all program for securing my network instead of headscale, a proven and battle tested wireguard mesh
Can you use VPNs outside of your infra (e.g. protonvpn, mullvad) as an exit node?
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.<p>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.<p>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:<p>"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."<p>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.<p>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?<p>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.<p>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.<p>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.<p>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.<p>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.<p>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.<p>Some suggestions:<p>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 <i>product</i>, 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.<p>2) You require <i>replacing</i> 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?<p>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...".<p>Good luck with Octelium, it's certainly interesting and I'll keep an eye on it as it evolves.
Reminds of the confusion when <a href="https://openziti.io/" rel="nofollow">https://openziti.io/</a> 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.<p>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.<p>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.<p>3. Octelium has Session resources <a href="https://octelium.com/docs/octelium/latest/management/core/session" rel="nofollow">https://octelium.com/docs/octelium/latest/management/core/se...</a> 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.<p>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.<p>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.<p>As for the suggestions:<p>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.<p>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.
There are so so many of these already...<p>- Tinc (the OG of P2P VPN)<p>- Hamachi (not open though)<p>- ZeroTier<p>- Nebula (from Slack)<p>- Tailscale<p>- Netbird<p>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.<p>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.<p>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.<p>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.)<p>2. One pipe to observe, and clearly attenuate permissions as traffic/messages flows between these boundaries.<p>3. Strong proofing of identity for every client, as an inherit requirement.<p>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)<p>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.<p>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).<p>The docs are a little verbose, the marketing maybe isn’t amazing. But this is inherently a complex problem. No one has fully solved.<p>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.<p>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.
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.<p>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.<p>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).<p>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)<p>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.<p>And then using something like Teleport, Octelium, etc to reach production assets.<p>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.<p>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.<p>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.<p>Quick 2-minute overview: <a href="https://www.youtube.com/watch?v=hU7QixSqnSM&t=3s" rel="nofollow">https://www.youtube.com/watch?v=hU7QixSqnSM&t=3s</a><p><a href="https://www.border0.com/" rel="nofollow">https://www.border0.com/</a>
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.<p>We're also still working to go "on cloud" as our CIO wants. Because they want to be hip too.<p>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.<p>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.<p>There's reliquary [2] which I host and run for me and my hacker friends based on sanctum.<p>[1] <a href="https://github.com/jorisvink/sanctum">https://github.com/jorisvink/sanctum</a><p>[2] <a href="https://reliquary.se" rel="nofollow">https://reliquary.se</a>
And many more: <a href="https://github.com/anderspitman/awesome-tunneling">https://github.com/anderspitman/awesome-tunneling</a>