Tailscale alternative

The open source, self-hosted alternative to Tailscale

Octelium is a free and open source, self-hosted zero trust access platform. It provides identity-based, layer-7 aware access control on a per-request basis, dynamic secretless access, and a unified architecture for both client-based and clientless access, for humans, workloads and AI agents alike.

  • 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.
Client-based and clientless

A unified architecture for client-based and clientless access

Each resource is protected by an identity-aware proxy that provides application-layer-aware access control, secretless access, and visibility. Users reach Services through two equivalent modes.

Read how Octelium works
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: grafana
spec:
  mode: HTTP
  config:
    upstream:
      url: http://10.0.6.12:3000
The same resource, clientlessly. One added field publishes the very same Service over HTTPS for browsers and for workloads.
kind: Service
metadata:
  name: grafana
spec:
  mode: HTTP
  isPublic: true
  config:
    upstream:
      url: http://10.0.6.12:3000
Anonymous public access. A containerized application that the Cluster deploys itself and serves to the public internet.
kind: Service
metadata:
  name: docs
spec:
  mode: HTTP
  isPublic: true
  isAnonymous: true
  config:
    upstream:
      container:
        port: 8080
        image: ghcr.io/acme/docs:2.1.0
Access control

Layer-7 aware access control with policy-as-code

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

Read about Policies and access control
policy-http.yaml
HTTPMethod, path, headers and serialized JSON body are all part of the request context.
HTTP. Method, path, headers and serialized JSON body are all part of the request context.
kind: Policy
metadata:
  name: api-read-only
spec:
  rules:
    - effect: ALLOW
      condition:
        all:
          of:
            - match: ctx.request.http.method == "GET"
            - match: ctx.request.http.path == "/v1/stats"
            - match: '"analysts" in ctx.user.spec.groups'
Kubernetes. Kubernetes verbs, resources and namespaces are authorized without sharing a kubeconfig.
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'
Identity and context. Device posture, session type and group membership are attributes like any other.
kind: Policy
metadata:
  name: sensitive
spec:
  rules:
    - effect: ALLOW
      condition:
        all:
          of:
            - match: ctx.user.spec.type == "HUMAN"
            - match: ctx.session.status.type == "CLIENT"
            - 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
postgres.yaml
PostgreSQLThe upstream password stays in the Cluster. Users connect without ever receiving it.
PostgreSQL. The upstream password stays in the Cluster. 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
      sslMode: REQUIRE
SSH. No private keys or passwords are distributed, and no PKI has to be operated.
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
Kubernetes. One kubeconfig lives in the Cluster and is never handed to a User.
kind: Service
metadata:
  name: prod-k8s
spec:
  mode: KUBERNETES
  config:
    upstream:
      url: https://k8s.internal:6443
    kubernetes:
      kubeconfig:
        fromSecret: kubeconfig-prod
mcp.yaml
MCP gatewayA containerized MCP server, deployed and scaled by the Cluster as the Service upstream.
MCP gateway. A containerized MCP server, deployed and scaled by the Cluster as the Service upstream.
kind: Service
metadata:
  name: tools-mcp
spec:
  mode: MCP
  isPublic: true
  config:
    upstream:
      container:
        port: 8080
        image: ghcr.io/acme/mcp:1.4.0
        replicas: 2
    mcp:
      endpoint: /mcp
      protocol:
        requireVersion: true
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
ALLOWlinus@acme.compg-prod.dbPOSTGRESquery: select id, email from users limit 50
ALLOWci-runnerprod-k8sKUBERNETESverb=list resource=pods namespace=production
DENYagent-07tools-mcpMCPtools/call name=transfer policy=mcp-tools
ALLOWjane@acme.combastionSSHsession recorded, upstream user=deploy
ALLOWagent-07openaiLLMCHAT_COMPLETIONS model=gpt-5-mini tokens=1284
octeliumctl
❯octeliumctl apply ./cluster
$ octeliumctl apply ./cluster
Secret: pg-password Updated
Secret: bastion-key Updated
IdentityProvider: okta Updated
Policy: analysts Created
Group: analysts Created
Group: sre Updated
Service: pg-prod.db Created
Service: bastion Created
Service: tools-mcp Created
Namespace: db Created
Cluster Core resources successfully applied
 7 resources created
 3 resources updated

 ClusterConfig updated
Comparison

Octelium and Tailscale, 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.
Tailscale
Decentralized WireGuard P2P mesh with SaaS coordination/control plane for identity, keys, ACLs, posture, and policy. Data path is usually peer-to-peer, with relay/DERP fallback.

Authentication

Native FIDO2 / Passkey

Native means implemented by the platform itself, not merely delegated to an external IdP.

Octelium
NativeFIDO2/Passkey/WebAuthnN with attestation and hardware-resistant authenticator checks
Tailscale
NoDelegates MFA to IdP rather than native gateway MFA.

Workload Identity

Octelium
OIDC assertions / workload identity
Tailscale
Federated workload identity

SCIM Provisioning

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

Octelium
SCIM 2.0 compliant
Tailscale
SCIM / IdP user & group sync

Authorization & Policy

Policy Model

Octelium
Layer-7 aware ABAC with policy-as-code via CEL and OPA
Tailscale
ACL/HuJSON policy network-level/Layer-3 identity controls.

Policy-as-Code

Octelium
CEL + OPA
Tailscale
Limited ACLs over HuJSON

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
Tailscale
NoMesh policy is connection/network-oriented, not L7 per-request authorization.

L7-Aware Policies

Octelium
HTTP, gRPC, K8s, DB, SSH, mTLS-related context
Tailscale
No

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.
Tailscale
Partial

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.
Tailscale
Tailnet lock / approvalsDevice approval and tailnet lock exist; not a PAM-style ticketed request workflow.

Device Posture

Octelium
TPM/FIDO2/device attributes
Tailscale
Yes

L7 Protocol Awareness & Secretless Access

SSH

Octelium
Secretless / embedded SSH patterns
Tailscale
Tailscale SSH

PostgreSQL

Octelium
Secretless + query-aware policy/logging
Tailscale
Transport only

Kubernetes

Octelium
Secretless + verb/resource/namespace policy
Tailscale
No

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.
Tailscale
Built on WireGuard

NAT Traversal

Octelium
Via GatewaysReaches resources behind NAT through Cluster Gateways; client-to-Gateway path rather than a direct P2P mesh.
Tailscale
CoreDirect P2P with NAT traversal; DERP relay fallback.

Visibility, Auditing & Observability

OpenTelemetry-Native

Octelium
Yes
Tailscale
No

L7-Aware Access Logs

Octelium
HTTP/gRPC/K8s/DB/SSH identity-aware logs
Tailscale
No

Access Methods

Clientless Browser Access

Octelium
Yes
Tailscale
Funnel/Serve and web exposure patterns, not general BeyondCorp

Workload OAuth2 / Bearer

Octelium
Yes
Tailscale
No

Private DNS

Octelium
Yes
Tailscale
MagicDNS

Dynamic Configuration

GitOps / Declarative Config

Octelium
Kubernetes-like resources / YAML
Tailscale
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.
Tailscale
Aperture beta

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.
Tailscale
No

Deploy Containers / PaaS

Octelium
Yes
Tailscale
No

Scalability & Cloud-Nativeness

Kubernetes-Native

Octelium
Built on Kubernetes
Tailscale
No

High Availability

Octelium
K8s-native HA model
Tailscale
SaaS coordination + DERP infrastructure

Openness & Self-Hosting

Fully Self-Hosted

Octelium
Yes
Tailscale
No official self-hosted coordination server; Headscale is community alternative

Server Code Open Source

Octelium
Yes
Tailscale
Client open source; official control plane proprietary

No Mandatory Proprietary Cloud

Octelium
Yes
Tailscale
NoOfficial product depends on Tailscale SaaS coordination.

Data Sovereignty

Octelium
Yes
Tailscale
Traffic can be P2P; metadata/control plane remains SaaS in official product
Questions

Frequently asked

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 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.
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.
Does Octelium use WireGuard?
Yes. Client-based access runs over WireGuard, using the kernel implementation where it is available and an unprivileged userspace implementation elsewhere, so clients also run inside containers, CI runners and IoT devices. A QUIC-based tunneling mode is supported alongside it. Each Service is reachable over a single stable route with an automatically managed private DNS name.
How does secretless access work?
Upstream application-layer credentials are stored in the Cluster as Secrets and injected by the identity-aware proxy once a request has been authenticated and authorized. Users never receive the API key, password, private key, kubeconfig or client certificate. Which credential is used can itself be selected per request from identity and context.
Can I keep my existing identity provider?
Yes. 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.
Get started

Deploy Octelium on your own infrastructure in minutes

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