Introduction

What is Octelium?

Octelium is a free and open source, self-hosted unified zero trust secure access platform. Octelium replaces VPNs, tunnels, gateways, reverse proxies, bastion hosts, and other remote access tools with a unified, modern, scalable zero trust architecture.

Octelium provides secure access for humans and workloads to private and internal resources behind NAT, protected public resources such as SaaS APIs and databases, and containerized applications, via a common model for identity management, client-based and clientless access, application-layer aware access control via policy-as-code, dynamic secretless access, and real-time auditing and visibility.

Depending on the deployment and use case, Octelium can serve as a remote access VPN, ZTNA/BeyondCorp platform, secure tunnel infrastructure, API, AI or MCP gateway, infrastructure AI agentic systems, Kubernetes ingress alternative, application deployment platform, or homelab infrastructure.

How is Octelium Different?

• A modern, unified, secure access platform Octelium is built around identity-aware proxies rather than broad network access. Its unified architecture brings together three concerns that are commonly handled by separate systems:

  • Unified access platform for humans and workloads Human and workload Users share the same identity management, authentication, access control and visibility model. Humans authenticate via your OpenID Connect or SAML 2.0 identity providers as well as native FIDO2/WebAuthn/Passkey, TOTP and TPM 2.0, while workloads authenticate via standard OAuth2 client credentials, authentication tokens or secretless OIDC-based assertions (e.g. from GitHub Actions, Azure, Kubernetes clusters, etc...).

  • Unified architecture for client-based and clientless access Both private zero-config client-based access over WireGuard/QUIC tunnels, and public clientless BeyondCorp access, via browsers for humans and via standard OAuth2 and bearer authentication for workloads, without any agents, clients or SDKs.

  • Unified access to private, protected public, and containerized applications Any private resource behind NAT in any environment (e.g. on-prem, private clouds, your own laptop, IoT devices, etc...), protected public resources such as SaaS APIs and databases, as well as containerized applications (via managed containers) deployed and scaled by the Octelium Cluster itself.

• Dynamic secretless access Users access protected HTTP APIs, SSH servers, PostgreSQL and MySQL databases, Kubernetes clusters, RDP servers and mTLS-protected resources without ever holding the API key, password, private key, kubeconfig or certificate. Such credentials are stored in the Cluster as Secrets and injected on a per-request basis at the identity-aware proxy without having to share, manage, rotate, and distribute such credentials to Users (read more here).

• Dynamic application-layer aware access control with policy-as-code Octelium provides centralized, fine-grained attribute-based access control (ABAC) on a per-request basis via policy-as-code using CEL as well as OPA (Open Policy Agent). This L7-aware access control includes HTTP request path, method, serialized JSON body, etc..., database queries, Kubernetes verbs and namespaces (read more here).

• Zero standing privileges Octelium intentionally has no notion whatsoever of an "admin" or "superuser" User. Every permission, including access to the API Server itself, must be explicitly granted by a Policy and is evaluated on a per-request basis, which means that access can be tied to time, context and attributes (read more here).

• Sandboxed development and AI agent execution with Cordium Cordium is an open-source, self-hosted sandbox platform built on Octelium. Cordium Workspaces provide isolated execution environments for developers, AI agents, and automated workloads, and can be accessed through browser-based terminals, SSH, the cordium CLI, or gRPC-based SDKs. Processes running inside a Workspace can access authorized Octelium Services through the Workspace identity without distributing upstream API keys, SSH keys, database passwords, or other application credentials into the sandbox.

• Declarative, GitOps-friendly management A Cluster is administered like Kubernetes: you define your resources in YAML files, store them in a Git repository, and a single octeliumctl apply command is enough to (re)produce the entire Cluster state anywhere. Management is centralized via the Cluster's gRPC-based APIs, which means you never SSH into servers to set up configurations, and the entire Cluster is programmable via SDKs (read more here).

• OpenTelemetry-ready, application-layer aware auditing and visibility Access logs identify the User, Session and Device as well as the application-layer details of the request (e.g. HTTP paths, database queries, SSH session recordings, etc...) and are emitted in real time to your OpenTelemetry OTLP receivers, where they can be exported to your log management and SIEM tools (read more here).

• Built on Kubernetes for seamless horizontal scalability and high availability An Octelium Cluster uses Kubernetes as an infrastructure to deploy and scale its control-plane and data-plane components, place Service proxies across Gateways, restart failed components, and run containerized applications deployed by the Cluster. This allows the same architecture to run on a single-node Kubernetes installation for small deployments or scale across multi-node managed and on-prem Kubernetes environments.

• Context-aware, identity-based, L7 aware dynamic configuration and routing Octelium can select upstreams, upstream accounts and credentials, protocol-specific settings, and routing behavior dynamically from request context. These decisions can be expressed with policy-as-code via CEL or OPA and evaluated on a per-request basis.

• No change in your infrastructure is needed Your upstream resources don't need to be aware of Octelium at all. They can be listening to any behind-NAT private network, even to localhost. No public gateways, no need to open ports behind firewalls to serve your resources wherever they are. Connected clients only need outbound internet connectivity.

• Avoiding traditional VPN networking problems altogether Each Service is assigned stable private dual-stack addresses and an automatically managed private DNS name within a single stable route. There are no injected routes for remote networks, no routing conflicts, and no NAT64/DNS64 pain, regardless of what the upstreams themselves support (read more here).

• Open source and designed for self-hosting No proprietary cloud-based control plane or paid SaaS. Octelium Clusters are meant to be self-hosted. You can host a Cluster on top of a single-node Kubernetes cluster running on a cheap cloud VM/VPS, and you can also host it on scalable cloud-based or on-prem multi-node Kubernetes installations with no vendor lock-in.

Use Cases

Secure access:

• Modern Remote Access VPN: Zero-config, layer-7 aware client-based and clientless access. See the quick installation guide here.

• Zero Trust Access to SaaS APIs: Secretless access without distributing long-lived API keys. See examples for a generic API here, AWS Lambda here and AWS S3 here.

• API Gateway: A self-hosted, scalable and secure API gateway for microservices. See an example here.

• AI Gateway: Identity-based access control, routing and visibility for any LLM provider. See an example here.

• MCP Gateways and AI Agent-based Architectures: Identity management, authentication, access control and visibility for MCP gateways and AI agent architectures and agentic meshes. See an example here.

Deployment and hosting:

• Self-Hosted Secure Tunnels: An ngrok/Cloudflare Tunnel alternative for identity-based as well as anonymous access. See an example here.

• Self-Hosted PaaS: Deploy, scale and host containerized applications, similar to Vercel or Netlify. See an example for Next.js/Vite apps.

• Kubernetes Ingress Alternative: Route to any Kubernetes service via dynamic, L7-aware policy-as-code.

• Homelab: Securely access all your resources behind NAT from anywhere, and privately or publicly host your websites, APIs and heavy containers (e.g. Ollama, ClickHouse, Pi-hole, etc...). See examples for remote VSCode and Pi-hole.

Where to Go Next

• Try it in your browser: Spin up a full Cluster inside a GitHub Codespace via the playground with zero installation.

• Install a Cluster in minutes: The quick installation guide installs a full single-node Cluster on any cheap VM/VPS using your own domain.

• Understand the architecture first: How Octelium Works walks through the identity-aware proxy model, the request lifecycle and the control plane.