What is Octelium?

Octelium is a free and open source, self-hosted, unified platform for zero trust resource access that is primarily meant to be a modern alternative to corporate VPNs and remote access tools, yet it is built to be generic enough to not only operate as a ZTNA/BeyondCorp platform, but also an API gateway, an AI gateway, an infrastructure for MCP gateways and A2A architectures, a PaaS-like platform for secure as well as anonymous hosting and deployment, a Kubernetes gateway/ingress/load balancer and even as an infrastructure for your own homelab. Octelium provides a scalable zero trust architecture (ZTA) for identity-based, application-layer (L7) aware secret-less secure access, via both private client-based access over WireGuard/QUIC tunnels as well as public clientless access (i.e. BeyondCorp), for users, both humans and workloads, to any private/internal resource behind NAT in any environment as well as to publicly protected resources such as SaaS APIs and databases via context-aware access control on a per-request basis through policy-as-code.

Use Cases

Octelium is designed to be generic enough (check out the main features below for more details) to be completely or partially used as a solution for various use cases depending on your needs/requirements, notably:

• Unified ZTNA/BeyondCorp architecture A Zero Trust Network Access (ZTNA) platform/ BeyondCorp architecture (i.e. alternative to Cloudflare Zero Trust, Google BeyondCorp, Zscaler Private Access, Teleport, Fortinet, etc...).
• Modern remote access VPN A modern zero trust L-7 aware alternative to commercial remote access/corporate VPNs to provide zero-config client-based over WireGuard/QUIC tunnels as well as client-less secret-less access via dynamic identity-based, L-7 aware, context-aware access control via policy-as-code (i.e. alternative to OpenVPN Access Server, Twingate, Tailscale, etc...).
• Secure tunnels A self-hosted secure tunnels and reverse proxy programmable infrastructure (i.e. alternative to ngrok, Cloudflare Tunnel, etc...).
• Self-hosted PaaS A scalable PaaS-like hosting/deployment platform to deploy, scale and provide both secure as well as anonymous public hosting for your containerized applications (i.e. similar to Vercel, Netlify, etc...).
• API gateway A self-hosted, scalable, secure API gateway that takes care of access, routing, deployment and scaling of containerized microservices, authentication, L-7 aware/context aware authorization and visibility (i.e. alternative to Kong Gateway, Apigee, etc...) (see example here).
• AI gateway A scalable AI gateway to any AI LLM providers with identity-based, context-aware access control, routing and visibility (see example here).
• MCP gateways and A2A-based architectures A secure infrastructure for Model Context Protocol (MCP) gateways and Agent2Agent Protocol (A2A)-based architectures that provides identity management, authentication over standard OAuth2 client credentials and bearer authentication, secure remote access and deployment as well as identity-based, L7-aware access control via policy-as-code and visibility.
• Kubernetes ingress alternative A much more advanced alternative to Kubernetes Ingress and load balancers where you can route to any remotely accessible internal resources from anywhere, not just Kubernetes services running on the same cluster, via much more than just path prefixes (e.g. identity, request headers, body content, context such as time of the day, etc...) via dynamic policy-as-code.
• Homelab A unified self-hosted Homelab infrastructure to connect and provide secure remote access to all your resources behind NAT from anywhere (e.g. all your devices including your laptop, IoT, cloud providers, Raspberry Pis, routers, etc...) as well as a secure deployment platform to deploy and privately as well as publicly host your websites, blogs, APIs or to remotely test heavy containers (e.g. LLM runtimes such as Ollama, databases such as ClickHouse and Elasticsearch, Pi-hole, etc...).

Main Features

• A modern, unified, scalable zero trust architecture Octelium is built from the ground up to control access at the application layer using a scalable architecture that is based on identity-aware proxies (IAPs) rather than at the network level using segmentation as is the case in remote access VPNs with the following main goals:

  • A unified access platform for humans and workloads.
  • A unified architecture to access any kind of private/internal resources behind NAT (e.g. on-prem, one or more private clouds, your own laptop behind NAT, IoT, etc...) as well as protected public resources (e.g. SaaS APIs, databases, protected public SSH servers, etc...).
  • A unified architecture for both zero trust access methods:
    • Private access using VPN-like zero-config client-based zero trust network access (ZTNA) over WireGuard/QUIC tunnels with automatic private DNS.
    • Public client-less BeyondCorp access for both humans via their browsers and workloads via standard OAuth2 client credential flows and bearer authentication.
  • Built on top of Kubernetes to provide automatic horizontal scalability and availability. An Octelium Cluster can run on top of a single node Kubernetes cluster running over a cheap cloud VM instance/VPS and it can also run over managed, scalable Kubernetes installations.

• Dynamic secret-less access Octelium's layer-7 awareness enables Users to seamlessly resources that are protected by application-layer credentials eliminating the need to expose, manage and share such typically long-lived and over-privileged secrets required to access such protected resources. The following protocols are currently supported:

  • HTTP-based resources (e.g. HTTP APIs, gRPC APIs, protected web apps, etc...) without having to share and expose API keys, access tokens or OAuth2 client credentials.
  • SSH without having to share passwords or manage keys and certificates.
  • Kubernetes clusters without sharing Kubeconfigs, certificates or access tokens.
  • PostgreSQL and MySQL-based databases without exposing passwords.
  • Any application-layer protocol that is protected by mutual TLS (mTLS) without managing PKI/sharing certificates.

• Context-aware, identity-based, application-layer aware access control Octelium provides you a modern, centralized, scalable, fine-grained, dynamic, context-aware, layer-7 aware, attribute-based access control system (ABAC) on a per-request basis using modular and composable Policies that enable you to write your policy-as-code using CEL as well as OPA (Open Policy Agent).

  Octelium intentionally has no notion whatsoever of an "admin" or "superuser" User. In other words, zero standing privileges are the default state. Any permissions including those to the API Server can be restricted via Policies and tied to time and context on a per-request basis.

• Context-aware, identity-based, L-7 aware dynamic configuration and routing Route to different upstreams, different credentials representing different upstream contexts and accounts using policy-as-code with CEL and OPA on a per-request basis.

• Continuous strong authentication A unified, continuous authentication system for both human and workload Users:

  • Any web identity provider (IdP) that supports OpenID Connect or SAML 2.0 (e.g. Okta, Auth0, OneLogin, AWS Cognito, etc...) as well as Github OAuth2.
  • "Secret-less" authentication for workloads via OIDC-based assertions where workloads can authenticate themselves using OIDC identity tokens issued by the identity provider hosting the workload ( e.g. Azure, CI/CD providers such as GitHub Actions as well as Kubernetes clusters, etc...)
  • Integrate Your IdP and control access to sensitive resources based on NIST SP 800-63 Authenticator Assurance Levels to force using strong MFA (e.g. WebAuthn/Passkeys) via phishing resistant security keys (e.g. Yubikey).

• OpenTelemetry-ready, application-layer aware auditing and visibility Identity and application-layer aware visibility where every request is logged and exported in real-time to your OpenTelemetry OTLP receivers and collectors which can be further exported to log management and SIEM tools and providers.

• Effortless, password-less, serverless SSH access Octelium clients are capable of serving SSH even when they are not running as root enabling Users to SSH into containers, IoT devices or other hosts that do not have or cannot run SSH servers.

• Effortlessly deploy, scale and secure access to your containerized applications as Services Octelium provides you out-of-the-box PaaS-like capabilities to effortlessly deploy, manage and scale your your containerized applications and serve them as Services to provide seamless secure client-based private access, client-less public BeyondCorp access as well as public anonymous access.

• Centralized, declarative and programmable management Octelium Clusters are designed to be administered like Kubernetes. It can be administered via declarative management where one command (i.e. octeliumctl apply) is enough to (re)produce the state of the Octelium Cluster anywhere. The Cluster's management is also centralized via its APIs which means you do not have to ever again SSH into your servers to set up configurations/rules. Instead, the octeliumctl CLI tool is used to control all the Cluster's resources in a clean, centralized and declarative way that is dev/DevOps/GitOps friendly where you can store your Cluster configurations and resources in a git repo and effortlessly reproduce them at anytime and anywhere. Furthermore, the Cluster is fully programmable using gRPC-based APIs that can be compiled to your favorite programming language.

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

• Avoiding traditional VPN networking problems altogether Octelium's client-based private networking mode eliminates a whole class of networking and routing problems that traditional VPNs suffer from. In Octelium, each resource is represented by a Service that is implemented by an identity-aware proxy (IaP) and is assigned stable private dual-stack IP address(es) within a single dual-stack private range abstracting the actual upstream resource's dynamic network details. This architecture eliminates classes of decades-old networking problems via:

  • Using a single stable route instead of injecting countless routes of the actual different remote private networks into the users' machines which cause routing conflicts.
  • Effortless dual-stack private networking where Users seamlessly access Services at both IPv4/IPv6 regardless of whether the upstream supports them both or not, without having to deal with the pain and inconsistency of NAT64/DNS64.
  • A unified, automatically managed, private DNS using your own domain for all resources scattered across the different remote networks that works consistently and independently of the dynamic network details of the upstreams.
  • Simultaneous support for WireGuard (Kernel, TUN as well as unprivileged implementations via gVisor) as well as experimentally QUIC (both TUN and unprivileged via gVisor) tunnels via a lightweight zero-config client that can run in any Linux, MacOS, Windows environment as well as container environments (e.g. Kubernetes sidecar containers for your workloads).

• Open source and designed for self-hosting Octelium is fully open source and it is designed for single-tenant self-hosting. There is no proprietary cloud-based control plane, nor this is some crippled demo open source version of a separate fully functional SaaS paid service. You can host it on top of a single-node Kubernetes cluster running on a cheap cloud VM/VPS and you can also host it on scalable production cloud-based or on-prem multi-node Kubernetes installations with no vendor lock-in.