Why Octelium

Four challenges of modern secure remote access

As humans, workloads, services, and AI agents converge on the same infrastructure, four challenges become fundamental: identity, authorization, secure connectivity, and visibility. Octelium unifies all four in a single secure access platform.

01
Credential sprawl
API keys, SSH keys, database passwords, kubeconfigs, and cloud credentials must be distributed, stored, rotated, and revoked across a growing fleet.
In Octelium
Octelium keeps upstream credentials as Cluster Secrets and injects them only after authorization. Users, workloads and agents never need to hold them.
02
Fragmented identity
Human identity lives in directories and SSO providers, while service accounts, CI jobs, workloads and AI agents accumulate separate credentials and identities elsewhere.
In Octelium
Unified identity management for humans and workloads. People authenticate through your OIDC and SAML 2.0 identity providers and native FIDO2, WebAuthn and TPM 2.0 authenticators, while workloads use OAuth2, authentication tokens or federated OIDC assertions.
03
Broad network access
VPNs and network-level controls often make more infrastructure reachable than a user or workload actually needs.
In Octelium
Every resource is protected behind an identity-aware proxy. Access control is enforced at the application layer on a per-request basis with policy-as-code.
04
Incomplete visibility
Network and connection logs rarely explain who performed an application action, why it was authorized, and what the request actually contained.
In Octelium
OpenTelemetry-native, application-layer-aware, real-time visibility. Structured logs and metrics are exported to your SIEM providers.

Unified Access Platform

A unified architecture for client-based and clientless access

One zero trust architecture built on identity-aware proxies for humans, workloads and AI agents to access internal resources behind NAT in any environments, protected SaaS resources and containerized applications.

Connecting to a Cluster

One stable route, stable private dual-stack addresses and automatic private DNS. Upstreams stay behind NAT, nothing is exposed publicly, and only outbound connectivity is required on both sides.

least-privilege access

Identity-based access control at the application layer

Access is authorized on a per-request basis against the identity behind the request, the context around it and the content of the request itself, rather than against the network path it arrived on.

Read about Policies

Identity, Groups, Device and Session

Attributes of the subject, combined in one expression, evaluated per request

Policy p-sre-consoleCEL or OPA

all:  of:    - match: ctx.user.spec.type == "HUMAN"    - match: ctx.session.status.type == "CLIENT"    - match: ctx.device.status.osType in ["MAC", "LINUX"]    - match: '"sre" in ctx.user.spec.groups'

ALLOWjane@acme.com
CLIENT session, MAC device, Group sre
all four expressions match
DENYjane@acme.com
CLIENTLESS session from a browser
session type is not CLIENT
DENYagent-07
WORKLOAD User, no Device
User type is not HUMAN

Dynamic Secretless Access

Access resources without distributing their credentials

Dynamic secretless access where teams and AI agents access protected infrastructure without ever holding a credential.

Covers HTTP API keys and access tokens, SSH and RDP credentials, database passwords, kubeconfigs and mTLS certificates.
Select different upstream identities and credentials dynamically based on the request's identity and context.
Revoke access through Policy instead of rotating credentials across every user, workload and agent.

Read about secretless access

The API key stays in the Cluster. The caller never receives one, and revoking access is a Policy change rather than a rotation across every consumer.

Identity management

One identity model for humans, workloads and AI agents

Humans, workloads and AI agents use the same User, Group, Policy and audit model while authenticating through mechanisms appropriate to each type of identity.

Read about Users and identity

Any OIDC or SAML 2.0 identity provider

Plus native FIDO2, WebAuthn passkeys, TPM 2.0 and TOTP, required through Policy

Agentic AI

Secure AI agents, MCP servers and LLM access

Identity-based secretless access to MCP servers, AI/LLM providers and infrastructure for AI agents at scale.

Read about the MCP mode

Every tool call is authorized on its own

The MCP mode parses JSON-RPC, so the method, the tool and its arguments are all in the request context

ctx.request.mcpmethod · name · arguments

ALLOWinitialize
protocolVersion 2025-06-18
handshake permitted for the finance-agents Group
ALLOWtools/list
12 tools returned
rule 2 allows listing
ALLOWtools/call
name=search_invoices q=overdue
tool is in the allowed set
DENYtools/call
name=transfer amount=25000
arguments.amount exceeds the ceiling in rule 1

MCP servers can also run as managed containers deployed and scaled by the Cluster itself.

Visibility

Real-time, L7-aware visibility and auditing

OpenTelemetry-native, real-time, structured, L7-aware visibility exported to the log management and SIEM tools your organization already operates.

Layer-7 visibility into every request: HTTP paths, methods and bodies, database queries, Kubernetes operations, SSH session recordings, DNS questions, and MCP and LLM calls with token usage.
Provide detailed access evidence for SOC 2, ISO/IEC 27001 and internal security controls through identity-aware, application-level auditing.

Read about visibility and logs

A request to an internal application

The method, the path and the response code, not only a connection

ALLOWED

Platform

Self-hosted, Kubernetes-native and GitOps-managed

Run Octelium on your own Kubernetes infrastructure and manage Cluster resources declaratively through YAML, GitOps, gRPC APIs and SDKs.

Read the management guide

service.yaml

A ServiceEvery protected resource is a Service, whatever protocol it speaks and wherever it runs.

A Service. Every protected resource is a Service, whatever protocol it speaks and wherever it runs.

kind: Service
metadata:
  name: hr-app
spec:
  mode: WEB
  config:
    upstream:
      url: http://10.0.3.18:8080
  authorization:
    policies: ["p-hr-app"]

A Policy. Authorization is written as code and evaluated per request, with the request itself in context.

kind: Policy
metadata:
  name: p-hr-app
spec:
  rules:
    - effect: DENY
      condition:
        match: ctx.request.http.path.startsWith("/admin")
    - effect: ALLOW
      condition:
        match: '"hr" in ctx.user.spec.groups'

Secretless access. The upstream credential is a Cluster Secret. Nothing is distributed to the Users who need the resource.

kind: Service
metadata:
  name: reporting
spec:
  mode: POSTGRES
  config:
    upstream:
      url: postgres://pg.internal:5432
    postgres:
      user: readonly
      database: reporting
      auth:
        password:
          fromSecret: reporting-password

A managed container. The Cluster can also deploy, scale and serve the containerized application behind a Service.

kind: Service
metadata:
  name: docs
spec:
  mode: HTTP
  isPublic: true
  config:
    upstream:
      container:
        port: 80
        image: nginx:latest

A workload User. Non-human subjects are Users too, with the same Groups, the same Policies and the same audit trail.

kind: User
metadata:
  name: ci-runner
spec:
  type: WORKLOAD
  groups: ["ci"]

Use cases

Use Octelium across your infrastructure

Start with a VPN replacement or ZTNA deployment, then apply the same identity, Services, Policies and audit model to SSH, Kubernetes, databases, APIs, MCP servers and AI agents.

Secure access

10

Deployment and hosting

04

On every Octelium Cluster

The same platform capabilities ship with every deployment, whichever way you use it.

Questions

Frequently asked

Is it really free and open source?: Yes. Octelium is free and open source and is designed for 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 2.0 provisioning and Secret encryption at rest, and it is free to use, forever, for personal and evaluation use.
How is this different from a VPN?: A VPN grants access to a network. Octelium represents each protected resource as a Service behind an identity-aware proxy and authorizes every request against the identity behind it, the context around it and the content of the request itself. Client-based access still uses WireGuard and QUIC tunnels, but establishing one grants access to nothing on its own.
Which protocols does it cover?: HTTP, gRPC and web applications, SSH, Kubernetes, PostgreSQL and MySQL, RDP, DNS, SOCKS5, generic TCP and UDP, and the MCP and LLM modes for AI workloads. Each one is covered by the same identity, Policy and auditing model, and the layer-7 aware ones expose their protocol details to both Policies and logs.
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

Install a Cluster on your own infrastructure in minutes

One fresh Linux VM/server, and a domain you own. The installer takes care of the Cluster and all of its dependencies, Kubernetes included.

Quick install guide GitHub repo

$ curl -o install-cluster.sh https://octelium.com/install-cluster.sh$ chmod +x install-cluster.sh$ ./install-cluster.sh --domain <DOMAIN>

Four challenges of modern secure remote access

Credential sprawl

Fragmented identity

Broad network access

Incomplete visibility

A unified architecture for client-based and clientless access

Client-based access

Clientless access

Identity-based access control at the application layer

Identity, Groups, Device and Session

HTTP method, path, headers and body

Kubernetes verbs, resources and namespaces

Database users, databases and queries

Access resources without distributing their credentials

One identity model for humans, workloads and AI agents

Any OIDC or SAML 2.0 identity provider

Workloads and AI agents are Users too

Secure AI agents, MCP servers and LLM access

Every tool call is authorized on its own

Model, operation, tools and token limits

Real-time, L7-aware visibility and auditing

A request to an internal application

A session on a bastion host

A query against a reporting database

A CI job listing pods in production

An agent calling a tool it may not call