Teleport alternative

The open source, self-hosted alternative to Teleport

Octelium is a free and open source, self-hosted zero trust access platform. It provides secretless access to SSH servers, Kubernetes clusters, databases and internal APIs, identity-based and layer-7 aware access control on a per-request basis, and one architecture for both client-based and clientless access.

  • Free and open source
  • Designed for self-hosting

Humans, workloads and AI agents reach web and internal APIs, SSH and RDP hosts, Kubernetes clusters, databases, MCP servers and LLM providers through one Octelium Cluster. Every request is identified, authorized against the request itself, authenticated to the upstream by the Cluster rather than by the caller, and logged.

  • ALLOW: jane@acme.com to bastion.prod over SSH, the private key is injected at the proxy and the session is recorded.
  • ALLOW: ci-runner to k8s-prod over KUBERNETES, verb=list resource=pods namespace=production, with no kubeconfig.
  • DENY: agent-07 to tools-mcp over MCP, tools/call name=transfer amount=25000, denied on its arguments.
  • ALLOW: linus@acme.com to reporting.db over POSTGRES, database reporting as readonly, with no password to distribute.
  • ALLOW: svc-billing to payments over HTTP, POST /v1/charges, with the API key injected at the proxy.
service-private.yaml
A private resourceA resource behind NAT in any environment, reached over the tunnel through a single stable route.
A private resource. A resource behind NAT in any environment, reached over the tunnel through a single stable route.
kind: Service
metadata:
  name: jenkins
spec:
  mode: HTTP
  config:
    upstream:
      url: http://10.0.6.40:8080
The same resource, clientlessly. One added field publishes the very same Service over HTTPS for browsers and for workloads.
kind: Service
metadata:
  name: jenkins
spec:
  mode: HTTP
  isPublic: true
  config:
    upstream:
      url: http://10.0.6.40:8080
Hosts with no SSH server. A connected client can serve SSH itself, which covers containers, CI runners and IoT fleets.
kind: Service
metadata:
  name: fleet
spec:
  mode: SSH
  config:
    ssh:
      eSSHMode: true
policy-k8s.yaml
KubernetesVerbs, resources, namespaces and API groups are all part of the request context.
Kubernetes. Verbs, resources, namespaces and API groups are all part of the request context.
kind: Policy
metadata:
  name: k8s-read
spec:
  rules:
    - effect: ALLOW
      condition:
        all:
          of:
            - match: ctx.request.kubernetes.verb == "get"
            - match: '"sre" in ctx.user.spec.groups'
PostgreSQL. The database and database user a request asks for are authorized before the connection is made.
kind: Policy
metadata:
  name: db-analysts
spec:
  rules:
    - effect: ALLOW
      condition:
        match: ctx.request.postgres.connect.user == "ro"
SSH and identity. The requested SSH user, the Session type and Group membership sit in one expression.
kind: Policy
metadata:
  name: ssh-non-root
spec:
  rules:
    - effect: ALLOW
      condition:
        all:
          of:
            - match: ctx.request.ssh.connect.user != "root"
            - match: '"sre" in ctx.user.spec.groups'
            - match: ctx.device.status.osType in ["MAC"]
Secretless access

Credentials that are never distributed

Application-layer credentials are stored in the Cluster as Secrets and injected into the upstream connection once a request is authorized. This removes credential sprawl for teams and, increasingly, for workloads and AI agents.

Read the secretless access guide
service-mysql.yaml
MySQLThe upstream password stays in the Cluster. Users connect without ever receiving it.
MySQL. The upstream password stays in the Cluster. Users connect without ever receiving it.
kind: Service
metadata:
  name: orders-db
spec:
  mode: MYSQL
  port: 3306
  config:
    upstream:
      url: mysql://10.0.4.31:3306
    mysql:
      user: app_ro
      database: orders
      auth:
        password:
          fromSecret: mysql-password
A credential chosen per request. The upstream account is selected from identity, so one Service serves several privilege levels.
kind: Service
metadata:
  name: bastion
spec:
  mode: SSH
  dynamicConfig:
    configs:
      - name: ops
        upstream:
          url: ssh://10.0.2.14
        ssh:
          user: root
          auth:
            privateKey:
              fromSecret: root-key
    rules:
      - condition:
          match: '"ops" in ctx.user.spec.groups'
        configName: ops
Kubernetes. A single kubeconfig is held as a Secret and injected once a request has been authorized.
kind: Service
metadata:
  name: prod-k8s
spec:
  mode: KUBERNETES
  config:
    upstream:
      url: https://k8s.internal:6443
    kubernetes:
      kubeconfig:
        context: prod
        fromSecret: kubeconfig-prod
service-llm.yaml
An LLM gatewayThe inference request is validated and the provider credential is injected upstream.
An LLM gateway. The inference request is validated and the provider credential is injected upstream.
kind: Service
metadata:
  name: anthropic
spec:
  mode: LLM
  config:
    upstream:
      url: https://api.anthropic.com
    llm:
      protocol: ANTHROPIC
      auth:
        bearer:
          fromSecret: anthropic-api-key
      limits:
        maxOutputTokens: 8192
Tool-level authorization. MCP JSON-RPC methods and tool names are normalized into the request context.
kind: Policy
metadata:
  name: mcp-tools
spec:
  rules:
    - effect: ALLOW
      condition:
        all:
          of:
            - match: ctx.request.mcp.method == "tools/call"
            - match: ctx.request.mcp.name == "search_docs"
            - match: '"agents" in ctx.user.spec.groups'
Secretless workload identity. Workloads authenticate with OIDC assertions issued by the platform running them.
kind: IdentityProvider
metadata:
  name: github-actions
spec:
  oidcIdentityToken:
    issuerURL: https://token.actions.githubusercontent.com
    audience: https://example.com
Visibility and auditing

Real-time visibility at the application layer

OpenTelemetry-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.

Read about visibility and auditing
AccessLogOTLP
ALLOWjane@acme.combastionSSHsession recorded, upstream user=deploy
ALLOWlinus@acme.comprod-k8sKUBERNETESverb=list resource=pods namespace=production
DENYdana@acme.compg-prod.dbPOSTGRESconnect user=postgres policy=db-analysts
ALLOWci-runnerorders-db.dbMYSQLquery: select id, total from orders limit 20
ALLOWagent-07tools-mcpMCPtools/call name=search_docs
octeliumctl
❯octeliumctl apply ./cluster
$ octeliumctl apply ./cluster
Secret: bastion-key Updated
Secret: kubeconfig-prod Updated
IdentityProvider: okta Updated
Policy: sre-ssh Created
Policy: k8s-read Created
Group: sre Updated
Service: bastion Created
Service: prod-k8s Created
Service: orders-db.db Created
Namespace: db Created
Cluster Core resources successfully applied
 7 resources created
 3 resources updated

 ClusterConfig updated
Comparison

Octelium and Teleport, capability by capability

Both 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.

Capability comparison

Dataset reviewed August 2026

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

Architecture

Octelium
Kubernetes-native identity-aware proxy/gateway architecture in which policy evaluation is separated from enforcement, with client-based WireGuard/QUIC access, clientless BeyondCorp access, declarative resources, and self-hosted control/data planes.
Teleport
Centralized access proxy, auth/certificate authority, audit engine, reverse tunnels, and deployable agents. Self-hosted or Teleport Cloud. Proxy/Auth/Node services can be separated for HA and scale.

Authentication

Workload Identity

Octelium
OIDC assertions / workload identity
Teleport
Machine & Workload Identity

Anonymous / Public Access

Octelium
Yes
Teleport
No

SCIM Provisioning

Automated user/group lifecycle provisioning via SCIM, beyond just login-time IdP federation.

Octelium
SCIM 2.0 compliant
Teleport
SCIM (enterprise)

Authorization & Policy

Policy Model

Octelium
Layer-7 aware ABAC with policy-as-code via CEL and OPA
Teleport
RBAC with traits, labels, predicates, access requests, and certificate-scoped permissions.

Policy-as-Code

Octelium
CEL + OPA
Teleport
YAML roles / Terraform

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.

Octelium
Yes
Teleport
Protocol-dependentStrong session/protocol controls; not a generalized CEL-style per-request gateway for every request type.

L7-Aware Policies

Octelium
HTTP, gRPC, K8s, DB, SSH, mTLS-related context
Teleport
SSH, DB, K8s, RDP/Web/MCP depending on protocol

Zero Standing Privilege / JIT

Indicates strong architectural support for minimizing standing privilege; not an absolute claim that privileged access cannot exist.

Octelium
StrongDesigned to minimize static privilege through identity/policy-scoped access.
Teleport
JIT access requests / short-lived certs

Access Requests / Approvals

First-class request-and-approve / break-glass workflows (reviewers, time-bound grants), as opposed to static policy alone.

Octelium
Access requests + approvalsFirst-class access request and approval workflow, in addition to policy/identity-scoped access that can be time-bound.
Teleport
First-classAccess Requests with reviewers, Access Lists, and break-glass workflows.

Device Posture

Octelium
TPM/FIDO2/device attributes
Teleport
Device Trust

L7 Protocol Awareness & Secretless Access

SSH

Octelium
Secretless / embedded SSH patterns
Teleport
Cert-based + recording

PostgreSQL

Octelium
Secretless + query-aware policy/logging
Teleport
DB access / audit

Kubernetes

Octelium
Secretless + verb/resource/namespace policy
Teleport
K8s access / audit

RDP

Octelium
with clientless secretless browser access
Teleport
Desktop access / RDP support

Transport & Networking

WireGuard Data Plane

Whether the product's own client/data plane is built on WireGuard, versus a proprietary or TLS-based transport.

Octelium
Kernel / userspaceWireGuard via kernel module, TUN, or unprivileged userspace (wireguard-go) implementations.
Teleport
NoNot a WireGuard VPN; uses mTLS reverse tunnels.

Embedded SSH

Platform provides its own SSH server/CA or SSH implementation, rather than only tunneling an external sshd.

Octelium
Secretless embedded SSH
Teleport
Built-in SSH CAProvides its own certificate-based SSH (Teleport SSH), not just tunneling external sshd.

Visibility, Auditing & Observability

OpenTelemetry-Native

Octelium
Yes
Teleport
No

L7-Aware Access Logs

Octelium
HTTP/gRPC/K8s/DB/SSH identity-aware logs
Teleport
Audit events, DB query logs, session activity

SSH Session Recording

Octelium
Yes
Teleport
SSH, DB, K8s, desktop/RDP, web depending on edition/config

Access Methods

Client-Based VPN / Overlay

Octelium
WireGuard / QUIC
Teleport
NoTeleport is not a WireGuard-style VPN.

Clientless Browser Access

Octelium
Yes
Teleport
Web apps / desktops

Workload OAuth2 / Bearer

Octelium
Yes
Teleport
No

Private DNS

Octelium
Yes
Teleport
No

Dynamic Configuration

Dynamic Credential Selection

Octelium
Yes
Teleport
Partial

GitOps / Declarative Config

Octelium
Kubernetes-like resources / YAML
Teleport
YAML / Terraform

SaaS / Public Cloud API Access

Secretless SaaS API Access

Octelium
Yes
Teleport
No

AI / MCP / Agent Compatibility

AI / LLM Gateway

Octelium
Native LLM Service modeProtocol-aware OpenAI/Anthropic gateway: validated operations, per-request authorization on model, tools and token limits, CEL-based model selection, and token usage in access logs.
Teleport
No

MCP Gateway / MCP Access

Octelium
Native MCP Service modeProtocol-aware MCP gateway: JSON-RPC method and tool-level authorization, protocol version pinning, origin validation, and managed-container MCP upstreams.
Teleport
First-classMCP server access with tool-level RBAC, query-level audit, JIT, and workload identity.

Deploy Containers / PaaS

Octelium
Yes
Teleport
No

Scalability & Cloud-Nativeness

Kubernetes-Native

Octelium
Built on Kubernetes
Teleport
Partial

High Availability

Octelium
K8s-native HA model
Teleport
Yes

Openness & Self-Hosting

Fully Self-Hosted

Octelium
Yes
Teleport
Yes

Server Code Open Source

Octelium
Yes
Teleport
Core

No Mandatory Proprietary Cloud

Octelium
Yes
Teleport
Self-hosted option
Questions

Frequently asked

Is Octelium free and open source?
Yes. Octelium is free and open source and is designed for single-tenant self-hosting. It is not a limited edition of a separate paid product and there is no proprietary cloud-based control plane. 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 issue and distribute certificates?
No. Upstream credentials are stored in the Cluster as Secrets and injected once a request has been authenticated and authorized, so there is no certificate authority for you to operate and nothing to distribute to Users. Access is granted and revoked by changing a Policy rather than by rotating credentials across every system a person or workload could reach.
How does secretless SSH access work?
The SSH mode connects to the upstream on the User's behalf using a password or private key held as a Secret, and forces the upstream SSH user regardless of what the client asks for. No changes are required on your SSH servers or clients. Hosts with no SSH server at all, such as containers, CI runners and IoT devices, are covered by the embedded SSH mode served from within a connected client.
Can I control Kubernetes and database access at the request level?
Yes. The Kubernetes mode exposes the verb, resource, namespace, API group and subresource of each request, and the PostgreSQL and MySQL modes expose the requested database and database user, all of them available to Policies and recorded in the access logs. Users never receive a kubeconfig or a database password.
How do workloads and AI agents authenticate?
Workload Users share the same identity model as human Users. They authenticate with authentication tokens, with the standard OAuth2 client credentials flow, or secretlessly with federated OpenID Connect assertions issued by the platform hosting them, such as GitHub Actions, a cloud provider or a Kubernetes cluster. No special SDK or client is required.
Do I need to know Kubernetes to run it?
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/server 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.