Solutions

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.

  • Free and open source
  • Designed for self-hosting
hr-app.yaml
An internal web appEvery protected resource is a Service, whatever protocol it speaks and wherever it runs.
An internal web app. Every protected resource is a Service, whatever protocol it speaks and wherever it runs.
kind: Service
metadata:
  name: hr-app
spec:
  mode: HTTP
  config:
    upstream:
      url: http://10.0.3.18:8080
An SSH server. The private key stays in the Cluster and is used to authenticate to the upstream.
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-key
A database. The upstream password is never distributed. Users connect without ever receiving it.
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-password
An MCP server. The MCP mode understands JSON-RPC messages and validates them before the upstream sees them.
kind: Service
metadata:
  name: tools-mcp
spec:
  mode: MCP
  isPublic: true
  config:
    upstream:
      url: http://mcp.internal:8080
    mcp:
      endpoint: /mcp
      protocol:
        versions: ["2026-07-28"]
An LLM provider. The provider key is injected upstream once the inference request has been authorized.
kind: Service
metadata:
  name: openai
spec:
  mode: LLM
  isPublic: true
  config:
    upstream:
      url: https://api.openai.com
    llm:
      protocol: OPENAI
      auth:
        bearer:
          fromSecret: openai-api-key
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.

By the resource you need to reach

08

Start here if a specific protocol or platform is the problem: the credentials it needs, who is allowed to use it, and what ends up in the audit trail.

For AI agents and models

03

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.

Replacing a product you already run

07

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.

metrics.yaml
Reached over the tunnelA private upstream anywhere, reached through a single stable route and private DNS.
Reached over the tunnel. A private upstream anywhere, reached through a single stable route and private DNS.
kind: Service
metadata:
  name: metrics
spec:
  mode: HTTP
  config:
    upstream:
      url: http://10.0.3.44:9090
Reached from a browser. The same Service published over HTTPS for people and for workloads, with no client.
kind: Service
metadata:
  name: metrics
spec:
  mode: HTTP
  isPublic: true
  config:
    upstream:
      url: http://10.0.3.44:9090
Deployed by the Cluster. The upstream can be a container the Cluster itself deploys, scales and serves.
kind: Service
metadata:
  name: docs
spec:
  mode: WEB
  isPublic: true
  config:
    upstream:
      container:
        port: 3000
        image: ghcr.io/acme/docs:2.1.0
        replicas: 3
Grouped and governed together. Services are grouped into Namespaces, and Policies can be attached to a whole Namespace.
kind: Namespace
metadata:
  name: internal
spec:
  authorization:
    policies:
      - engineering
      - deny-contractors
policy-http.yaml
An HTTP requestMethods, paths, headers and JSON bodies are visible to the same expression as identity.
An HTTP request. Methods, paths, headers and JSON bodies are visible to the same expression as identity.
kind: Policy
metadata:
  name: reporting
spec:
  rules:
    - effect: ALLOW
      condition:
        all:
          of:
            - match: ctx.request.http.method == "GET"
            - match: '"analysts" in ctx.user.spec.groups'
A Kubernetes operation. The verb, the resource and the namespace are each part of the decision.
kind: Policy
metadata:
  name: k8s-readers
spec:
  rules:
    - effect: ALLOW
      condition:
        all:
          of:
            - match: ctx.request.kubernetes.verb == "get"
            - match: ctx.request.kubernetes.namespace == "prod"
            - match: '"sre" in ctx.user.spec.groups'
An MCP tool call. A named tool is authorized on its own, rather than the MCP server as a whole.
kind: Policy
metadata:
  name: finance-tools
spec:
  rules:
    - effect: ALLOW
      condition:
        all:
          of:
            - match: ctx.request.mcp.method == "tools/call"
            - match: ctx.request.mcp.name == "transfer"
            - match: '"finance" in ctx.user.spec.groups'
Identity, device and session. Group membership, Session type and Device attributes sit in the same expression.
kind: Policy
metadata:
  name: managed-devices
spec:
  rules:
    - effect: ALLOW
      condition:
        all:
          of:
            - match: '"sre" in ctx.user.spec.groups'
            - match: ctx.session.status.type == "CLIENT"
            - match: ctx.device.status.osType in ["LINUX", "MAC"]
Explicit denial. A DENY rule is matched before any ALLOW rule, whichever Policy it came from.
kind: Policy
metadata:
  name: deny-contractors
spec:
  rules:
    - effect: DENY
      condition:
        match: '"contractors" in ctx.user.spec.groups'
AccessLogOTLP
ALLOWjane@acme.comhr-appHTTPGET /reviews/2026 200, device=MAC
ALLOWlinus@acme.combastionSSHsession recorded, upstream user=deploy
ALLOWci-runnerprod-k8sKUBERNETESverb=list resource=pods namespace=prod
DENYcontractor-3pg-prodPOSTGRESdatabase=payroll policy=deny-contractors
ALLOWagent-07openaiLLMCHAT_COMPLETIONS model=gpt-5-mini tokens=1284
octeliumctl
octeliumctl apply ./cluster
$ octeliumctl apply ./cluster
Secret: openai-api-key Updated
Secret: bastion-key Updated
IdentityProvider: github-actions Created
Policy: engineering Created
Policy: deny-contractors Created
Group: sre Updated
User: ci-runner Created
Service: bastion Created
Service: pg-prod Created
Namespace: internal Created
Cluster Core resources successfully applied
 8 resources created
 2 resources updated

 ClusterConfig updated
Questions

Frequently asked

What is Octelium, in one paragraph?
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

Deploy Octelium on your own infrastructure in minutes

Free and open source. Self-hosted. No vendor lock-in.