yjftsjthsd-h9 hours ago
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)?
>centralized router(s)
When using Tailscale, your packets may be sent through centralized routers, FYI.
Literally every single word of it
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”?
"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."
“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!
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.
- "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 :)
> Funnily enough, Octelium started as a sidecar ext_authz svc for Envoy instances to operate as an IaP but I ended up creating my own Golang-based IaP, Vigil, from scratch because Envoy was just nothing but pain outside HTTP-based resources.
That's really funny... we went the opposite direction as the original versions were based on a custom Go proxy. Of course there are tradeoffs either way. Envoy is blazing fast, and does great with HTTP naturally, but has a giant configuration surface area (both pro and con), but we are now having to write some pretty low level filters /protocol capabilities in envoy for the other protocols we support (SSH, MCP, and so on) in C++ which does not spark joy. So I totally feel what you are saying.
Thanks for the kind words, though I am one of the contributors my colleague did the heavy lifting on the WebAuthN side.
Genuinely happy to see the release and where you are headed on the AI/MCP side. If you (or others) are interested, I am trying to bring more light to this model in the spec if you (or others) would like to weigh in: https://github.com/modelcontextprotocol/modelcontextprotocol/discussions/804
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.
I understand it may not be easy to narrow down the explanation, especially if you invested a lot of time and don't want to do a disservice to yourself by underselling it. Looking at the Tailscale tagline I quoted, it is small and ambiguous enough that it works marketing wise, regardless of all the features and solutions they offer. But it was just an example, I should maybe have used a totally different example of a product that is not in the same realm as yours.
The explanation you gave to me here is good but only because I vaguely know what all this jargon means. Try to think of a short simple sentence that a non-expert could understand.
I don't trust this.
Even the diagrams for API vs AI gateways are almost identical.
I am also working on extending the process of modifying HTTP requests/body content beside what's been provided (see more https://octelium.com/docs/octelium/latest/management/core/service/http). 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.
Last year I wrote an article about how to write a good README:
It’s way too long and excessively prescriptive, and the author goes too far with inserting their opinions (ie, don’t use github, don’t use discord etc.). I couldn’t possibly recommend this howto.
I think this is the part where I’m supposed to tell third parties to disregard yours, but I’m not going to.
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!
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.
Not all are commercial (but why would you want that anyway). But ZeroTier is another one like that. Basically the same thing.
The README is way too verbose though. It should explain the project at a glance and have links to docs for the details.
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."
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.
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.
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.
One might posit that you're repackaging a fOSS project from somewhere with no clear ethos.
> 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.
Tunneled Reverse Proxy Server with Access Control - your own self-hosted zero trust tunnel. AGPL3
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.
https://octelium.com/docs/octelium/latest/management/guide/service/http/nextjs-vite https://octelium.com/docs/octelium/latest/management/guide/service/ai/remote-ollama https://octelium.com/docs/octelium/latest/management/guide/service/homelab/pihole https://octelium.com/docs/octelium/latest/management/guide/service/homelab/remote-vscode-code-server
- 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.
What enterprises want is to move away from perimeter based security models towards the promise that Google überProxy/BeyondCorp popularized many years ago. Which has been lost in the buzzword soup. It’s very simple.
1. A clean separation between Prod, Corp, and the public internet. And the UX to hop between them as an employee is as transparent as possible. (Often times network segmentation comes with additional painful friction for engineerings.)
2. One pipe to observe, and clearly attenuate permissions as traffic/messages flows between these boundaries.
3. Strong proofing of identity for every client, as an inherit requirement.
The problem is everyone outside Google has incredibly diverse protocol ecosystems. It makes those three promises incredibly difficult to deliver on as a vendor. (I’ve evaluated many)
To build a proxy that is protocol aware, only solves half the problem. It gets you some coarse grain decision making and a good logging story.
To build a proxy that is also able to perform type-inference at the request layer, allows for a much richer authZ story. One where businesses can build an authorization layer at the proxy better than their in-house apps could even do natively. (As it turns out, having all the predicates of the request available to a policy engine is super useful).
The docs are a little verbose, the marketing maybe isn’t amazing. But this is inherently a complex problem. No one has fully solved.
Teleport was first to the market to OSS and commercialize a lot of these ideas. StrongDM also is doing really interesting work in this space. I wish Hashicorp had invested more in this space.
Disclaimer: my opinions are my own.
There's reliquary [2] which I host and run for me and my hacker friends based on sanctum.
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.
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.
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.
I recommend using an LLM to rewrite it far more succinctly.
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
To me this sounds like an L7 identity & access management layer for wireguard, but again I had trouble parsing the readme.