Open source zero trust access, for every resource your team reaches
Octelium is a free and open source, self-hosted zero trust access platform for humans, workloads and AI agents. The pages below are the same Cluster described from different starting points: the architecture you are building, the resource you need to reach, the AI workload you are running, or the product you are replacing.
Unified identity management for humans, workloads and AI agents
Adaptive authentication for humans and non-human identities
Identity-based, application-layer-aware access control
OpenTelemetry-native real-time visibility and auditing
Unified access architecture for private and SaaS resources
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.
Every solution
Find the page that matches what you are doing
Four ways in, depending on what brought you here. Every page describes the same platform, so nothing below is a different product or a different deployment.
By access architecture
06
Start here if the shape of the deployment is what you are deciding: whether people connect over a tunnel, reach applications from a browser, or both at the same time.
Start here if the identities holding your credentials are increasingly not people. Agents, MCP servers and inference traffic sit in the same identity, authorization and auditing model as everything else.
Start here if you are evaluating against something specific. Each page sets out the capability matrix side by side and describes what Octelium does, in the same terms.
A Service is a protected resource plus the identity-aware proxy that serves it. The proxy understands the protocol, which is what makes authorization, credential injection and auditing possible at the application layer rather than at the connection.
The same authorization language for every protocol
Access is authorized per request, using CEL or Open Policy Agent, against the identity behind the request and the content of the request itself. The vocabulary changes with the protocol; the model does not.
jane, a member of the finance Group, runs curl -i billing/invoices/42 and gets HTTP/1.1 200 OK Content-Type: application/json {"id":42,"status":"paid","total":1290}. The access log records ALLOWED GET /invoices/42 with POLICY_MATCH.
jane, a member of the finance Group, runs curl -i -X DELETE billing/invoices/42 and gets HTTP/1.1 403 Forbidden X-Octelium-Unauthorized: true Content-Length: 0. The access log records DENIED DELETE /invoices/42 with NO_POLICY_MATCH.
LLM: the LLM Service openai is configured as follows.
kind: Service
metadata:
name: openai
spec:
mode: LLM
config:
authorization:
inlinePolicies:
- spec:
rules:
- effect: ALLOW
condition:
any:
of:
- match: '"ai-admins" in ctx.user.spec.groups'
- all:
of:
- match: '"ai-agents" in ctx.user.spec.groups'
- match: ctx.request.llm.operation == "GENERATE"
- match: ctx.request.llm.model == "gpt-5-mini"
support-bot, a member of the ai-agents Group, runs curl openai/v1/responses --json '{"model":"gpt-5-mini","input":"Hello"}' and gets { "id": "resp_68e8e1f0c4d0", "object": "response", "created_at": 1791628935, "status": "completed", "model": "gpt-5-mini-2025-08-07",. The access log records ALLOWED RESPONSES gpt-5-mini with POLICY_MATCH.
support-bot, a member of the ai-agents Group, runs curl openai/v1/responses --json '{"model":"gpt-5","input":"Hello"}' and gets {"error":{"message":"Octelium: unauthorized request","type":"permission_error","param":null,"code":"octelium_unauthorized"}}. The access log records DENIED RESPONSES gpt-5 with NO_POLICY_MATCH.
Kubernetes: the KUBERNETES Service k8s-prod is configured as follows.
kind: Service
metadata:
name: k8s-prod
spec:
mode: KUBERNETES
config:
authorization:
inlinePolicies:
- spec:
rules:
- effect: ALLOW
condition:
all:
of:
- match: '"sre-agents" in ctx.user.spec.groups'
- match: ctx.request.kubernetes.verb in ["get", "list"]
ops-agent, a member of the sre-agents Group, runs kubectl get configmaps -n production and gets NAME DATA AGE app-config 4 12d feature-flags 2 3d kube-root-ca.crt 1 12d. The access log records ALLOWED list configmaps · production with POLICY_MATCH.
ops-agent, a member of the sre-agents Group, runs kubectl get secrets -n production and gets Error from server (Forbidden): Octelium: Unauthorized request. The access log records DENIED list secrets · production with NO_POLICY_MATCH.
One audit trail
Every request, with the identity behind it
A Cluster produces one stream of AccessLogs for everything it serves. An access review does not depend on correlating a VPN log, a bastion log, a database log and a proxy log that each name the subject differently.
A Cluster is administered the way a Kubernetes cluster is: resources are declared in YAML, kept in a Git repository, and applied in one command that reproduces the entire Cluster state.
Cluster resources applied declaratively from YAML with octeliumctl and managed programmatically with the Go, TypeScript, Python and Rust SDKs
GitOps: cluster.yaml in the main branch of the ~/octelium repository describes the desired state of the Cluster. Its diff reads as follows, with + for added, ~ for changed and - for removed lines.
+ kind: Group
+ metadata:
+ name: payments
+ spec: {}
+ ---
+ kind: User
+ metadata:
+ name: alice
+ spec:
+ type: HUMAN
+ email: alice@acme.com
+ groups: ["payments"]
---
kind: User
metadata:
name: bob
spec:
type: HUMAN
~ groups: ["payments"]
---
kind: Service
metadata:
name: billing
spec:
mode: HTTP
config:
upstream:
~ url: http://10.0.3.24:8080
- ---
- kind: Service
- metadata:
- name: billing-legacy
- spec: ⋯
- ---
- kind: User
- metadata:
- name: john
- spec: ⋯
~/octelium ❯ octeliumctl apply --prune .
Group: payments Created
User: alice Created
User: bob Updated
Service: billing.default Updated
Service: billing-legacy.default Deleted
User: john Deleted
Cluster Core resources successfully applied
2 resources created
2 resources updated
2 resources deleted
Go: main.go uses the octelium-go SDK to list the Users of the Cluster and update the email and Policies of linus.
Octelium is a free and open source, self-hosted zero trust access platform. Every protected resource is represented by a Service, served by an identity-aware proxy that understands the protocol in front of it. Users reach Services either over zero-config WireGuard and QUIC tunnels or clientlessly over HTTPS, and every request is authorized on its own against the identity behind it and the content of the request, then logged.
Are these separate products?
No. Every page here describes the same Cluster, configured differently. A single deployment can serve internal web applications, SSH servers, Kubernetes clusters, PostgreSQL and MySQL databases, SaaS and internal APIs, MCP servers and LLM providers at the same time, under one identity model, one policy language and one audit trail.
Which page should I start with?
If you are deciding on an architecture, start with zero trust network access, which describes the platform end to end. If a specific protocol or platform is the immediate problem, start with that page. If you are evaluating against a product you already run, the alternative pages set out a capability matrix side by side.
Is Octelium free and open source?
Yes. Octelium is free and open source and is designed for single-tenant self-hosting. There is no proprietary cloud-based control plane and it is not a limited edition of a separate paid product. An enterprise package is available for organizations that need capabilities such as a web console, SCIM provisioning and secret encryption at rest, and it is free for personal, homelab and evaluation use.
Do I have to replace my identity provider?
No. Any OpenID Connect or SAML 2.0 identity provider is supported, as well as GitHub OAuth2. Octelium additionally provides native FIDO2 and WebAuthn passkeys, TOTP and TPM 2.0 authenticators that can be required through Policy on sensitive Services, independently of what the identity provider itself enforces.
What does it take to run one?
An Octelium Cluster runs on top of Kubernetes, but you do not need Kubernetes experience to install, operate or use it. The quick installer provisions a complete single-node Cluster, including Kubernetes itself, on one fresh Linux VM with 2 vCPUs, 2 GB of RAM and a domain you own. Production Clusters run on scalable managed or on-premise Kubernetes installations.
Get started
Run Octelium on your own infrastructure
Install a self-hosted Cluster and start applying identity-aware access control to your Services.