Octelium is a free and open source, self-hosted zero trust access platform. A service running on your machine is served to the Cluster over an outbound tunnel and published at a stable URL on your own domain, either openly or behind your identity provider, with policy, rate limiting and auditing in front of it.
kind: Service
metadata:
name: dev
spec:
mode: HTTP
isPublic: true
config:
upstream:
url: http://localhost:3000
user: laptopkind: Service
metadata:
name: hooks
spec:
mode: HTTP
isPublic: true
isAnonymous: true
config:
upstream:
url: http://localhost:3000
user: laptopkind: Policy
metadata:
name: team
spec:
rules:
- effect: ALLOW
condition:
all:
of:
- match: ctx.user.spec.type == "HUMAN"
- match: '"team" in ctx.user.spec.groups'Publishing a local service is one use of the same platform. Each capability is described in detail below, in the same order.
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 resource is represented by a Service, which is served by an identity-aware proxy that abstracts away the network details of the upstream behind it. Where that upstream runs, and whether the internet can see it, are two separate fields.
kind: Service
metadata:
name: dev
spec:
mode: HTTP
isPublic: true
config:
upstream:
url: http://localhost:3000
user: laptopkind: Service
metadata:
name: local-pg
spec:
mode: POSTGRES
port: 5432
config:
upstream:
url: postgres://localhost:5432
user: laptopkind: Service
metadata:
name: preview
spec:
mode: WEB
isPublic: true
config:
upstream:
container:
port: 3000
image: ghcr.io/acme/web:pr-482Access is authorized on a per-request basis, using CEL or Open Policy Agent, against the identity behind the request and the content of the request itself rather than the network path it arrived on.
kind: Policy
metadata:
name: webhook-only
spec:
rules:
- effect: ALLOW
condition:
all:
of:
- match: ctx.request.http.method == "POST"
- match: ctx.request.http.path == "/hooks/github"kind: Service
metadata:
name: hooks
spec:
mode: HTTP
isPublic: true
isAnonymous: true
config:
upstream:
url: http://localhost:3000
user: laptop
authorization:
enableAnonymous: true
inlinePolicies:
- spec:
rules:
- effect: ALLOW
condition:
match: ctx.request.http.method == "POST"kind: Service
metadata:
name: hooks
spec:
mode: HTTP
isPublic: true
config:
upstream:
url: http://localhost:3000
user: laptop
http:
plugins:
- name: minute-limit
condition:
matchAny: true
rateLimit:
limit: 60
window:
minutes: 1Application-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.
kind: Service
metadata:
name: api
spec:
mode: HTTP
isPublic: true
config:
upstream:
url: http://localhost:8080
user: laptop
http:
auth:
bearer:
fromSecret: api-keykind: Service
metadata:
name: local-pg
spec:
mode: POSTGRES
port: 5432
config:
upstream:
url: postgres://localhost:5432
user: laptop
postgres:
user: app
database: app
auth:
password:
fromSecret: pg-passwordkind: Service
metadata:
name: preview
spec:
mode: WEB
isPublic: true
config:
upstream:
container:
port: 3000
image: ghcr.io/acme/web:pr-482
credentials:
usernamePassword:
username: ghcr-user
password:
fromSecret: ghcr-tokenHuman and workload Users share the same identity management, authentication, access control and visibility model. The machine serving a resource is itself an identity, with its own Session and its own audit trail.
kind: IdentityProvider
metadata:
name: github-actions
spec:
oidcIdentityToken:
issuerURL: https://token.actions.githubusercontent.com
audience: https://example.comkind: User
metadata:
name: laptop
spec:
type: WORKLOAD
groups:
- servingkind: Service
metadata:
name: tools-mcp
spec:
mode: MCP
isPublic: true
config:
upstream:
url: http://localhost:8080
user: laptop
mcp:
endpoint: /mcpOpenTelemetry-ready, application-layer aware, structured auditing and visibility emitted to your OpenTelemetry OTLP receivers, where they can be exported to your log management and SIEM tools.
A Cluster runs on Kubernetes and uses it to scale its own data plane, place Service proxies across Gateways, and run containerized applications that the Cluster itself deploys.
$ octeliumctl apply ./cluster
Secret: ghcr-token Updated
Secret: pg-password Updated
IdentityProvider: github Updated
Policy: team Created
Group: team Created
Group: serving Updated
Service: dev Created
Service: hooks Created
Service: preview Created
User: laptop Created
Cluster Core resources successfully applied
7 resources created
3 resources updated
ClusterConfig updatedBoth products are described from the same structured capability dataset used across this site, with the same evidentiary standard applied to each. Emerging and experimental features are marked as partial regardless of vendor.
A curated view of the dataset, including 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
OpenID Connect
SAML 2.0
Native FIDO2 / Passkey
Native means implemented by the platform itself, not merely delegated to an external IdP.
Workload Identity
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
Device Posture
HTTP / HTTPS
gRPC
SSH
PostgreSQL
MySQL
Kubernetes
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.
NAT Traversal
OpenTelemetry-Native
L7-Aware Access Logs
SSH Session Recording
Client-Based VPN / Overlay
Clientless Browser Access
Private DNS
GitOps / Declarative Config
AI / LLM Gateway
MCP Gateway / MCP Access
Deploy Containers / PaaS
API Gateway
Kubernetes Ingress / Gateway
Reverse Proxy / Tunneling
Auto Horizontal Scaling
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
Developer Tunnel / Gateway
Strong developer gateway/API exposure product; not a full self-hosted ZTNA/PAM platform and lacks deep DB/SSH/K8s secretless protocol semantics.
Best for
Tradeoffs
The same platform capabilities ship with every deployment, whichever way you use it.
Publish resources behind NAT with no inbound ports, on infrastructure you operate end to end.
Read moreDeploy, scale and serve containerized applications that the Cluster itself runs, with or without public access.
Read moreReach everything at home from anywhere without forwarding a port, and host what you want on your own domain.
Read moreFree and open source. Self-hosted. No vendor lock-in.