[HN Gopher] Show HN: Octelium - FOSS Alternative to Teleport, Cl...
___________________________________________________________________
Show HN: Octelium - FOSS Alternative to Teleport, Cloudflare,
Tailscale, Ngrok
I have been working on Octelium for quite a few years now but it
was open sourced only by late May 2025. Octelium, as described more
in detail in the repo's README, is simply an open source, self-
hosted, unified platform for zero trust resource access that is
primarily meant to be a modern alternative to corporate VPNs and
remote access tools. It can operate as a remote access/corporate
VPN (i.e. alternative to Twingate, Tailscale, OpenVPN Access
Server, etc...), a ZTNA/BeyondCorp platform (i.e. alterntive to
Cloudflare Access, Teleport, Google BeyondCorp, etc...), and it can
also operate as an API/AI gateway, an infrastructure for MCP and
A2A architectures and meshes, an ngrok alternative, a homelab
infrastructure or even as a more advanced Kubernetes ingress. It's
basically designed to operate like a unified Kubernetes-like
scalable architecture for zero trust secure/remote access that's
suitable for different human-to-workload and workload-to-workload
environments. You can read more in detail the full set of main
features and links about how it works in the repo's README or
directly in the docs https://octelium.com/docs
Author : geoctl
Score : 260 points
Date : 2025-06-29 11:24 UTC (11 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| kosolam wrote:
| It looks very interesting, but I'm getting lost in the pages of
| features and different use cases. It would have been nice to have
| a succinct list of features/capabilities (technical, not
| buzzword) and why this solution solves better than alternatives.
| geoctl wrote:
| Thank you. I understand it's hard to concisely define what
| Octelium is because it is designed as a unified/generic
| secure/zero trust access platform, a term that almost nobody
| would relate to. It's more of a generic Kubernetes-like
| architecture/infrastructure for zero trust secure access that
| can fit many different use cases (i.e. human to workload and
| workload to workload environments). Well, it can be used as a
| typical WireGuard/QUIC-based remote access/corporate VPN. It
| can be used as a ZTNA/BeyondCorp platform with identity-based,
| L7 aware, context-aware ABAC via policy-as-code with CEL and
| OPA where you can control access at layer-7 (e.g. HTTP request
| headers, serialized JSON body content, etc...). It can also be
| used as an ngrok alternative (both secure access via
| OIDC/SAML/GitHub IdP as well as anonymously which can fit for
| hosting, testing APIs, etc...). It can also deploy your
| containerized resources and automatically provide client-
| based/clientless secure access to them (kinda like a PaaS) and
| it does provide dynamic configuration and routing to upstreams
| via policy-as-code (e.g. route to different API versions, use
| different SSH credentials, different API keys, different
| postgres user/password based on identity/context, etc....). It
| can also fit as an API/AI gateway and a scalable infrastructure
| for MCP architectures/meshes. Therefore, it's not really a
| ZTNA/VPN in the rigid sense, it's a more generic platform where
| what it does to secure/remote access is similar to what
| Kuberentes does for containers.
| alienbaby wrote:
| 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.
| geoctl wrote:
| 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.
| homarp wrote:
| define all the terms.
|
| explain simple use cases.
|
| explain why you built it, how you use it.
|
| explain the 'size' of it (it requires k8s so might not be
| for my small homelab)
|
| compare to 'similar' offerings.
| reachableceo wrote:
| 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.
| reachableceo wrote:
| Please update your HN profile with contact information.
|
| This product? Framework? Solution? seems to be exactly what
| I've been looking for / attempting to put together for my
| company. We are entirely self hosted and use only FLO
| software.
|
| We use Cloudron as our core PAAS and have been looking for a
| FLO zero trust / identity aware proxy for DB/RDP/SSH .
|
| Happy to be your flagship customer.
|
| We have a brand new k8s (self hosted) cluster deployed . We
| use wazuh as our SEIM, librenms for monitoring / alerting.
|
| Currently we use tailscale (with magicdns disabled and we
| hand out our internal pi hole IP as our recursive DNS server
| ) (and we have an authoritative DNS for our internal
| corporate domain).
|
| Charles@turnsys.com reaches me pretty quickly most days.
| Would love to deploy this immediately and write a testimonial
| etc
| geoctl wrote:
| Thank you so much. I will definitely contact you very soon.
| catlifeonmars wrote:
| Gentle feedback: if it's hard to concisely define what
| Octelium is, it will be hard to convince people to use it.
|
| To me this sounds like an L7 identity & access management
| layer for wireguard, but again I had trouble parsing the
| readme.
| geoctl wrote:
| 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.
| yjftsjthsd-h wrote:
| The big thing to me about Tailscale is easy p2p connectivity. I
| _think_ it looks like this doesn 't do that and uses centralized
| router(s)?
| geoctl wrote:
| 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.
| gen6acd60af wrote:
| >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
| mzhaase wrote:
| 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.
| geoctl wrote:
| I'd appreciate if you could provide me a list of those
| buzzwords so that I can improve the readme.
| drexlspivey wrote:
| "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
| geoctl wrote:
| 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.
| therealpygon wrote:
| 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"?
| maxmcd wrote:
| 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."
| geoctl wrote:
| 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.
| dudeinjapan wrote:
| 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!)"
| geoctl wrote:
| 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.
| dudeinjapan wrote:
| 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!
| geoctl wrote:
| 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.
| dudeinjapan wrote:
| 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.
| geoctl wrote:
| 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.
| bdesimone wrote:
| 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
| :)
| geoctl wrote:
| 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.
| bdesimone wrote:
| 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: ht
| tps://github.com/modelcontextprotocol/modelcontextprotoco
| l...
| geoctl wrote:
| 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.
| sureglymop wrote:
| 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.
| geoctl wrote:
| 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.
| sureglymop wrote:
| 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.
| geoctl wrote:
| 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.
| mdavid626 wrote:
| I've read "zero trust" more times today, than ever before
| in my life. Still don't know what this project does.
| swells34 wrote:
| 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: [...]"
| pelagicAustral wrote:
| "...to make the world a better place." was missing from
| this paragraph.
| mystraline wrote:
| It is zero-trust.
|
| I don't trust this.
| rollcat wrote:
| 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>
| geoctl wrote:
| 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 htt
| ps://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.
| sneak wrote:
| 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/
| geoctl wrote:
| Thank you. I will definitely work on making the README more
| concise and hopefully more useful and easy to understand.
| sevg wrote:
| Your readme isn't great, but I wouldn't pay much attention to
| this guide that this person keeps posting.
|
| It's way too long and excessively prescriptive, and the
| author goes too far with inserting their opinions (ie, don't
| use github, don't use discord etc.). I couldn't possibly
| recommend this howto.
| sneak wrote:
| 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.
| ar-nelson wrote:
| For everyone who's having a hard time parsing what Octelium does,
| I found this page to be the clearest explanation:
| https://octelium.com/docs/octelium/latest/overview/how-octel...
|
| It's clearer because, instead of starting with a massive list of
| everything you could do with Octelium (which is indeed
| confusing), it starts by explaining the core primitives Octelium
| is built on, and builds up from there.
|
| And it actually looks pretty cool and useful! From what I can
| tell, the core funtionality is:
|
| - A VPN-like gateway that understands higher-level protocols,
| like HTTP or PostgreSQL, and can make fine-grained security
| decisions using the content of those protocols
|
| - A cluster configuration layer on top of Kubernetes
|
| And these two things combine to make, basically, a personal
| cloud. So, like any of the big cloud platforms, it does a million
| things and it's hard to figure out which ones you need at first.
| But it seems like the kind of system that could be used for a
| homelab, a small company that wants to keep cloud costs down, or
| a custom PaaS selling cloud functionality. Neat!
| ttul wrote:
| TailScale is wonderful but they do need competition. I imagine
| an IPO is on the horizon, and as soon as they enter that phase,
| nasty price increases are sure to follow unless someone else is
| nipping hard at their heels.
| seabrookmx wrote:
| Hopefully their tolerance to self-hosters (Headscale) doesn't
| change.
| wkat4242 wrote:
| 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.
| candrewlee wrote:
| 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.
| wkat4242 wrote:
| 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.
| wiesbadener wrote:
| 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
| PoachedEggs wrote:
| I've been meaning to explore Netbird. Fewer features at the
| moment, but can be fully self hosted.
| wkat4242 wrote:
| 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.
| dahrkael wrote:
| there is also the chinese EasyTier https://easytier.cn/en/
| cchance wrote:
| I mean the fact headscale exists and is still in decent
| development, means i doubt it really is an issue, what i'd
| like to see is an effort for an opensource tailscale client
| so we could use headscale without the closed source client.
| maxboone wrote:
| Isn't the client entirely OSS? -
| https://github.com/tailscale/tailscale
| dangoodmanUT wrote:
| See Nebula by slack
| toomuchtodo wrote:
| Programmable network tunnel fabric.
| cedws wrote:
| Definitely interested in an open source alternative to Tailscale.
|
| The README is way too verbose though. It should explain the
| project at a glance and have links to docs for the details.
| homarp wrote:
| headscale is an open source alternative to tailscale:
|
| https://github.com/juanfont/headscale
| uneekname wrote:
| Headscale is great (I use it) but it is an alternative to the
| Tailscale control server, not the client applications. Some
| of those are closed source, and their compatibility with
| Headscale is not guaranteed.
| CharlesW wrote:
| 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."
| aspenmayer wrote:
| 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?
| CharlesW wrote:
| > _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.
| aspenmayer wrote:
| > 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.
| CharlesW wrote:
| 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.
| aspenmayer wrote:
| > 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.
| therealpygon wrote:
| Just some feedback to share some problems I personally think
| you're going to have and why I suspect you'll face a healthy
| amount of skepticism. There is a lack of history of development
| that ends with a major initial commit of unknown origin, a lack
| of any public information, a company that does not appear
| (publicly) to exist, and a product that is going to solve every
| need that can be imagined by packing it with buzzwords and little
| to no evidence of security. When faced with those things, my next
| step would be to consider how much is original versus built on
| underlying technologies I know and trust; information that is
| lacking.
|
| If you're launching a business, I would suggest making sure the
| business looks legitimate; if it's a pet project, trying to make
| yourself sound like a big business and then not having the
| footprint gives off "fake"/scam/caution vibes. If you're a solo
| dev, drop all the fake business stuff and get rid of the buzz
| words and "it can do everything" marketing and focus on what it
| excels at as an open source project.
|
| People are going to be skeptical (rightfully) that a solo dev/no
| name company is going to suddenly drop a product that rivals
| those of massive companies. Either massive shortcuts were taken,
| or there is a high chance that it will be insecure, which is not
| something you want from a VPN or any of the other things it
| claims to do. If you've built on existing secure technologies,
| you should emphasizing them because known names that have a
| security history are going to build a lot more trust than a no-
| name product.
|
| If a software is hard to explain the purpose of to an average
| person in a single sentence, you have an uphill battle. Listing
| more features isn't usually going to be the answer, regardless of
| how accurate you're attempting to be. "It's a VPN! and a PaaS!
| and a ZTNA! And an API Gateway! and AI!" It screams "please
| download me" rather than "I'm here to solve a problem", which is
| why I wouldn't even bother to try it; the opposite of what any
| project is going for.
|
| My intention isn't to just be critical, but rather to point out
| things that are likely harming your efforts.
| geoctl wrote:
| Thank you for your insightful feedback. I completely understand
| the criticism because Octelium is conciously designed to be
| many things at the same time. As mentioned in the other
| replies, Octelium is a unified/generic zero trust access
| platform that can fit in many human-to-workload and workload-
| to-workload use cases (the docs contain various examples in
| detail) that's why it might be confusing for newcomers. The
| initial commit came out of nowhere because I've been working on
| this project since early 2020 actually and decided to start
| with a clean public repo when I publicly released the code a
| month ago, after nearly 9000 manual commits over the past 5
| years. I simply could not verify that I could have potentially
| leaked private info esepcially in early commits and the project
| itself almost entirely changed over the past 5 years from a
| simple remote access WireGuard VPN to what it is today in terms
| of architecture, features and complexity.
| cyanydeez wrote:
| I think the primary concern was you look like a State actor
| using a AI to generate a project you hope private companies
| will use and your intentions don't appear clear, and the
| verbose replies & github suggest a lot of effort into a
| facade without anything else.
|
| One might posit that you're repackaging a fOSS project from
| somewhere with no clear ethos.
| geoctl wrote:
| I have been developing the project solo on a private GitHub
| repo since 2020. I am not VC-backed or whatever else,
| Octelium has been a solo effort so far basically. The
| project itself is now 100% open source as you can see.
| However, even if I open sourced the initial private repo,
| what would make you believe that I am who I really am?
| maybe even all those git commits from 2020 weren't really
| from 2020 and their timestamps have been spoofed to make
| you believe so. If 100% of the codebase of the project
| being open source is still not enough, I guess nothing can
| be enough.
| csomar wrote:
| Give open source devs a break. We don't know the OP background
| or his motivations. He might have been working on this for fun.
| He doesn't need to justify any of this. This is open source
| _and_ Free software. Take it as it is.
|
| > If a software is hard to explain the purpose of to an average
| person in a single sentence, you have an uphill battle.
|
| It does. If you use tailscale/cloudflare access and ngrok, the
| product is pretty well described. If you don't, then probably
| you don't need this product.
| noname120 wrote:
| I use those but I still don't understand what Octelium does
| or doesn't
| pydry wrote:
| Can you use VPNs outside of your infra (e.g. protonvpn, mullvad)
| as an exit node?
| geoctl wrote:
| 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.
| pydry wrote:
| This is similar to the current set up I have with tailscale,
| but it's not ideal, hence why i asked.
| geoctl wrote:
| 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".
| shrubble wrote:
| One takeaway is that this can replace ZLayer, and it does offer
| much more functionality than that. Is that correct?
| Onavo wrote:
| How does it compare to Pangolin?
| homarp wrote:
| 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
| geoctl wrote:
| 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.
| fariszr wrote:
| 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.
| kevmo314 wrote:
| 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.
| ghoshbishakh wrote:
| So this is something like pinggy.io - self hosted?
| geoctl wrote:
| 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...
| b0a04gl wrote:
| 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.
| geoctl wrote:
| 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...
| wkat4242 wrote:
| 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.
| apitman wrote:
| And many more: https://github.com/anderspitman/awesome-
| tunneling
| geoctl wrote:
| 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".
| metmac wrote:
| 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
| uberProxy/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.
| geoctl wrote:
| 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.
| jvink wrote:
| 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
| Arch-TK wrote:
| 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.
| thealistra wrote:
| 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.
| geoctl wrote:
| 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...
| guigg wrote:
| I don't understanding why you're embedding a full k3s cluster
| install in your app, it would be much clearer to everybody if
| this was something that you could add to existing infrastructure,
| with simpler CRDs to expose services. The pitch for the project
| looks awesome (opensource Cloudflare access / Teleport), but most
| of the features are customizations on top of k8s anyway, I'd be
| more interested in testing this if it was focused on the access
| part.
| geoctl wrote:
| 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.
___________________________________________________________________
(page generated 2025-06-29 23:00 UTC)