Thank you. I understand it's hard to concisely define what Octelium is because it is designed as a unified/generic secure/zero trust access platform, a term that almost nobody would relate to. It's more of a generic Kubernetes-like architecture/infrastructure for zero trust secure access that can fit many different use cases (i.e. human to workload and workload to workload environments). Well, it can be used as a typical WireGuard/QUIC-based remote access/corporate VPN. It can be used as a ZTNA/BeyondCorp platform with identity-based, L7 aware, context-aware ABAC via policy-as-code with CEL and OPA where you can control access at layer-7 (e.g. HTTP request headers, serialized JSON body content, etc...). It can also be used as an ngrok alternative (both secure access via OIDC/SAML/GitHub IdP as well as anonymously which can fit for hosting, testing APIs, etc...). It can also deploy your containerized resources and automatically provide client-based/clientless secure access to them (kinda like a PaaS) and it does provide dynamic configuration and routing to upstreams via policy-as-code (e.g. route to different API versions, use different SSH credentials, different API keys, different postgres user/password based on identity/context, etc....). It can also fit as an API/AI gateway and a scalable infrastructure for MCP architectures/meshes. Therefore, it's not really a ZTNA/VPN in the rigid sense, it's a more generic platform where what it does to secure/remote access is similar to what Kuberentes does for containers.

Perhaps it would be easier to go through a few typical use cases and implementations, and describe how they work with less brand naming and technical fancywords.

I scanned the github, and your reply above, and I still don't really get it.

I imagine I would understand it better if I was more fluent in the vocabulary you use and understood what some of the platforms and interesting names did from the get go.

So yea, my 2p - break it down into some use cases from simple - intermediate - advanced, use more straight forward language and less platform / product names. Technical terms are fine, but try not to string a zillion of them together all in one go... it reads a bit too much like a sales pitch trying to cram in as many acronyms and cool sounding things as possible.

I do agree with that. As a potential customer , reading over the page, it was incredibly redundant / dense.

I recommend using an LLM to rewrite it far more succinctly.

I honestly don't understand where the "sales pitch" part is. This project has been so far a solo effort and I am the one who basically wrote all the code. It's not like this is some VC-backed product where I am a marketing guy replying to you. I would appreciate it if you could provide me direct questions about what you don't understand so that I can answer you.

define all the terms.

explain simple use cases.

explain why you built it, how you use it.

explain the 'size' of it (it requires k8s so might not be for my small homelab)

compare to 'similar' offerings.

Please update your HN profile with contact information.

This product? Framework? Solution? seems to be exactly what I’ve been looking for / attempting to put together for my company. We are entirely self hosted and use only FLO software.

We use Cloudron as our core PAAS and have been looking for a FLO zero trust / identity aware proxy for DB/RDP/SSH .

Happy to be your flagship customer.

We have a brand new k8s (self hosted) cluster deployed . We use wazuh as our SEIM, librenms for monitoring / alerting.

Currently we use tailscale (with magicdns disabled and we hand out our internal pi hole IP as our recursive DNS server ) (and we have an authoritative DNS for our internal corporate domain).

Charles@turnsys.com reaches me pretty quickly most days. Would love to deploy this immediately and write a testimonial etc

Thank you so much. I will definitely contact you very soon.

Gentle feedback: if it’s hard to concisely define what Octelium is, it will be hard to convince people to use it.

To me this sounds like an L7 identity & access management layer for wireguard, but again I had trouble parsing the readme.

Thank you. I completely understand your point of view. I did put a lot of effort actually trying to come up with a simple concise description that can fit in an HN 80-char wide title but I simply could not do it. If you think about it, other fairly complex projects such as Kubernetes or Istio are also very hard to concisely describe for newcomers. There is always some assumption that potential users of the project are already acquainted with the terms used in modern zero trust architectures and familiar with similar commercial products such as Cloudflare Access, Teleport, StrongDM and many other related products.