Octelium is a free and open source, self-hosted zero trust access platform. It provides secretless access to SSH servers, databases and Kubernetes clusters, identity-based and layer-7 aware access control on a per-request basis, and full application-layer auditing, with the control plane and the data plane both running on your own infrastructure.
kind: Service
metadata:
name: pg-prod
spec:
mode: POSTGRES
port: 5432
config:
upstream:
url: postgres://10.0.4.21:5432
postgres:
user: analytics_ro
database: analytics
auth:
password:
fromSecret: pg-passwordkind: Policy
metadata:
name: sre
spec:
rules:
- effect: ALLOW
condition:
all:
of:
- match: ctx.user.spec.type == "HUMAN"
- match: '"sre" in ctx.user.spec.groups'
- match: ctx.request.ssh.connect.user != "root"kind: Service
metadata:
name: prod-k8s
spec:
mode: KUBERNETES
config:
upstream:
url: https://k8s.internal:6443
kubernetes:
kubeconfig:
fromSecret: kubeconfig-prodSecure 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 resource is protected by an identity-aware proxy that provides application-layer-aware access control, secretless access, and visibility. Infrastructure protocols are reached over the tunnel, and web resources can be published clientlessly at the same time.
kind: Service
metadata:
name: redis
spec:
mode: TCP
port: 6379
config:
upstream:
url: tcp://10.0.7.9:6379kind: Service
metadata:
name: pg-edge
spec:
mode: POSTGRES
config:
upstream:
url: postgres://pg.branch.local
user: branch-gwkind: Service
metadata:
name: grafana
spec:
mode: HTTP
isPublic: true
config:
upstream:
url: http://10.0.6.12:3000Access 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: k8s-sre
spec:
rules:
- effect: ALLOW
condition:
all:
of:
- match: ctx.request.kubernetes.verb == "get"
- match: '"sre" in ctx.user.spec.groups'kind: Policy
metadata:
name: read-only-db
spec:
rules:
- effect: ALLOW
condition:
all:
of:
- match: ctx.request.postgres.connect.user
== "analytics_ro"
- match: '"analysts" in ctx.user.spec.groups'kind: Policy
metadata:
name: no-root-ssh
spec:
rules:
- effect: ALLOW
condition:
all:
of:
- match: ctx.request.ssh.connect.user != "root"
- match: '"ops" in ctx.user.spec.groups'Application-layer credentials are stored in the Cluster as Secrets and injected into the upstream connection once a request is authorized. Nobody receives the database password, the private key or the kubeconfig, so there is nothing to rotate across laptops when someone leaves.
kind: Service
metadata:
name: bastion
spec:
mode: SSH
port: 22
config:
upstream:
url: ssh://10.0.2.14
ssh:
user: deploy
auth:
privateKey:
fromSecret: bastion-keykind: Service
metadata:
name: mysql-prod
spec:
mode: MYSQL
port: 3306
config:
upstream:
url: mysql://10.0.4.30:3306
mysql:
user: reporting
database: sales
auth:
password:
fromSecret: mysql-passwordkind: Service
metadata:
name: ssh1
spec:
mode: SSH
dynamicConfig:
configs:
- name: root
upstream:
url: ssh://10.0.2.14
ssh:
user: root
auth:
password:
fromSecret: root-password
- name: usr
upstream:
url: ssh://10.0.2.14
ssh:
user: usr
auth:
password:
fromSecret: usr-password
rules:
- condition:
match: '"ops" in ctx.user.spec.groups'
configName: root
- condition:
matchAny: true
configName: usrHuman and workload Users share the same identity management, authentication, access control and visibility model. A migration job reaching a production database is authorized and audited exactly as an engineer would be.
kind: IdentityProvider
metadata:
name: github-actions
spec:
oidcIdentityToken:
issuerURL: https://token.actions.githubusercontent.com
audience: https://example.comkind: User
metadata:
name: migrations
spec:
type: WORKLOAD
groups:
- cikind: Service
metadata:
name: tools-mcp
spec:
mode: MCP
isPublic: true
config:
upstream:
url: http://mcp.internal:8080
mcp:
endpoint: /mcp
protocol:
requireVersion: trueOpenTelemetry-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: pg-password Updated
Secret: kubeconfig-prod Updated
IdentityProvider: okta Updated
Policy: no-root-ssh Created
Group: sre Created
Group: analysts Updated
Service: pg-prod.db Created
Service: mysql-prod.db Created
Service: prod-k8s Created
Namespace: db 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
Workload Identity
SCIM Provisioning
Automated user/group lifecycle provisioning via SCIM, beyond just login-time IdP federation.
Policy Model
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
Zero Standing Privilege / JIT
Indicates strong architectural support for minimizing standing privilege; not an absolute claim that privileged access cannot exist.
Access Requests / Approvals
First-class request-and-approve / break-glass workflows (reviewers, time-bound grants), as opposed to static policy alone.
Device Posture
SSH
PostgreSQL
MySQL
Kubernetes
RDP
mTLS / cert injection
Raw TCP / UDP
WireGuard Data Plane
Whether the product's own client/data plane is built on WireGuard, versus a proprietary or TLS-based transport.
Embedded SSH
Platform provides its own SSH server/CA or SSH implementation, rather than only tunneling an external sshd.
NAT Traversal
OpenTelemetry-Native
L7-Aware Access Logs
SSH Session Recording
Client-Based VPN / Overlay
Clientless Browser Access
Private DNS
Dynamic Upstream Routing
Dynamic Credential Selection
Secrets Backend Integration
Integration with external secret stores / KMS (e.g. Vault, cloud KMS) or native secretless credential handling.
GitOps / Declarative Config
Secretless SaaS API Access
AI / LLM Gateway
MCP Gateway / MCP Access
Deploy Containers / PaaS
Kubernetes-Native
Auto Horizontal Scaling
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
Infrastructure Access / PAM
Strong for enterprise PAM, database access, JIT workflows, and audit/recording; weaker for open-source self-hosting, API gateway, and broad secretless SaaS/API access.
Best for
Tradeoffs
The same platform capabilities ship with every deployment, whichever way you use it.
Secretless PostgreSQL and MySQL access with per-request authorization and application-layer auditing.
Read moreSecretless SSH without distributing keys or operating a PKI, with session recording and embedded SSH for fleets.
Read morePer-verb Kubernetes authorization with the kubeconfig held by the Cluster rather than handed to a User.
Read moreFree and open source. Self-hosted. No vendor lock-in.