Octelium
Unified Access Platform
A unified secure access platform with secretless access, CEL/OPA-style ABAC, OpenTelemetry-native real-time visibility, and both client-based and clientless access.
Best for
Tradeoffs
Octelium is a free and open source, self-hosted zero trust access platform. A resource behind NAT is served to the Cluster over an outbound tunnel from a connected client, so it can be reached privately or published to the internet without an inbound port, on infrastructure you operate end to end.
Every request from a human, a browser, a CLI, a workload or an AI agent is authenticated against your identity providers, authorized per request at the application layer by the Octelium Service in front of the resource, exported to your SIEM and observability stack whether it is allowed or denied, and only then routed to the upstream HTTP API, database, SSH server, Kubernetes cluster, LLM or MCP server.
Secure humans, workloads and AI agents with one model for identity, authorization, connectivity, credentials and visibility.
One architecture for client-based zero-config VPN-like access over WireGuard and QUIC tunnels and clientless access over browsers for humans and OAuth2 access for workloads.
Read moreIdentity-based, application-layer aware ABAC access control with policy-as-code via CEL and OPA, applied on a per-request basis.
Read moreDynamic secretless access where teams and AI agents access protected infrastructure without ever holding a credential.
Read moreTeams, workloads and AI agents share the same model for identity management, access control, and auditing.
Read moreOpenTelemetry-native, real-time, application-layer-aware visibility and structured logging.
Read moreOctelium is administered like Kubernetes. Define your resources in YAML files, store them in a Git repository.
Read moreEach protected resource is represented as a Service behind an identity-aware proxy that enforces application-layer access control, credential isolation and auditing. Where that upstream actually lives is a detail of the Service definition.
Signing in once, then reaching Services with and without a client
Authorize every request from authenticated identity, request context and application-layer attributes with policy-as-code using CEL or Open Policy Agent.
Requests authorized one by one against CEL rules in the HTTP, LLM and Kubernetes modes
Application-layer credentials are stored in the Cluster as Secrets and injected into the upstream connection once a request is authorized. The credential a caller presents to the Cluster and the credential the Cluster presents upstream are entirely separate.
Upstream credentials injected per request by identity in the HTTP, SSH and PostgreSQL modes
Human and workload Users share the same identity management, authentication, access control and visibility model. The host that serves a resource is itself an identity, with its own Session and its own audit trail.
Signing in with a passkey and opening the Portal
Emit structured, application-layer access logs in real time and export them through OpenTelemetry OTLP to the observability, analytics and SIEM systems your organization already operates.
Run the Cluster on Kubernetes infrastructure you control, scale the data plane horizontally, manage resources declaratively, automate the platform through APIs and SDKs, and optionally deploy containerized Service upstreams with the Cluster itself.
Cluster resources applied declaratively from YAML with octeliumctl and managed programmatically with the Go, TypeScript, Python and Rust SDKs
Both products are compared from the same structured capability dataset and evaluated using the same evidentiary standard. Emerging or experimental capabilities are marked as partial regardless of vendor.
A curated view of the dataset, weighted here towards tunneling, publishing and hosting. It includes the rows where Octelium is stronger, the rows where it is not, and the rows where the two are equivalent. The complete capability matrix, with search and filters, is one click away.
Architecture
Anonymous / Public Access
Policy-as-Code
Per-Request Authz
For L7 products, this means each HTTP/gRPC/API/K8s request can be evaluated. For overlays, session/connection policy is not counted as per-request. This modeling choice structurally favors L7 gateways over network overlays.
L7-Aware Policies
HTTP / HTTPS
gRPC
SSH
PostgreSQL
MySQL
Kubernetes
RDP
DNS
Raw TCP / UDP
HTTP Manipulation
WireGuard Data Plane
Whether the product's own client/data plane is built on WireGuard, versus a proprietary or TLS-based transport.
QUIC Transport
Product-native QUIC transport/tunneling. Experimental or internal-only QUIC is marked partial.
IPv6 Support
NAT Traversal
OpenTelemetry-Native
L7-Aware Access Logs
SSH Session Recording
SIEM Integration
Client-Based VPN / Overlay
Clientless Browser Access
Private DNS
Dynamic Upstream Routing
GitOps / Declarative Config
Secretless SaaS API Access
Deploy Containers / PaaS
API Gateway
Kubernetes Ingress / Gateway
Reverse Proxy / Tunneling
Kubernetes-Native
High Availability
Fully Self-Hosted
Server Code Open Source
No Mandatory Proprietary Cloud
Data Sovereignty
Unified Access Platform
A unified secure access platform with secretless access, CEL/OPA-style ABAC, OpenTelemetry-native real-time visibility, and both client-based and clientless access.
Best for
Tradeoffs
Edge SASE / ZTNA
Extremely strong global edge/SASE product; less comparable to Octelium where deep self-hosted L7 protocol semantics, secretless app credentials, and data sovereignty are primary requirements.
Best for
Tradeoffs
The same platform capabilities ship with every deployment, whichever way you use it.
Publish local and private Services on your own domain and infrastructure, with optional identity-aware access control in front of them.
Read moreUnified zero trust remote access to infrastructure.
Read moreDeploy, scale and serve containerized applications as Octelium Services with private, authenticated or anonymous access.
Read moreInstall a self-hosted Cluster and start applying identity-aware access control to your Services.