2026.10.18
Octelium: Unified Zero-Trust Access, Gateways, and Self-Hosting
Octelium targets teams and individuals who want self-managed access control for VPN, ZTNA, API/AI/MCP gateways, container services, and homelabs.
Project focus
Octelium is a self-hosted unified zero-trust secure access platform. Its README presents it as a remote-access VPN, a ZTNA/BeyondCorp platform, a reverse-tunnel and API gateway, and infrastructure for AI/LLM, MCP, container deployment, Kubernetes ingress, and homelabs. It is aimed at teams that want to centralize identity, application-layer access control, and access to internal services, as well as individuals managing remote access to home or lab environments.
Known capabilities
The project describes both client-based and clientless access. Client-based connections use WireGuard/QUIC tunnels, while clientless access is intended for browser-facing or other public entry points. The README emphasizes Layer 7 request awareness and per-request controls for internal resources, services behind NAT, and protected public resources.
For policy, Octelium documents fine-grained, attribute- and context-aware access control using policy-as-code with CEL and OPA. It also describes dynamic configuration and routing, allowing different upstreams or credential contexts to be selected according to a request. The README lists secretless access scenarios for HTTP APIs, SSH, Kubernetes, PostgreSQL/MySQL, and L7 protocols protected by mTLS. These claims should still be checked against the documentation for the specific protocol and deployment.
Identity options listed by the project include OIDC, SAML 2.0, and GitHub OAuth2 for web identity, plus OIDC assertions for workloads. It also lists FIDO2/WebAuthn/Passkey, TOTP, and TPM 2.0 authenticators. For observability, the project says requests can be logged and exported to OpenTelemetry OTLP receivers for integration with logging and SIEM systems.
The v0.45.0 release notes mention connection detection and reconnection after client-host suspend and resume, Linux split-DNS improvements, connection-address cleanup, and reliability changes in the APIServer and Envoy ingress. These changes show the release’s focus, but they do not establish compatibility for every environment.
Adoption limits and deployment considerations
Because Octelium covers many use cases, adopters should define the primary goal first: replacing remote access VPN, protecting APIs, or operating a homelab and container platform. Each path involves different identity providers, DNS, certificates, network exposure, upstream services, and policy design. The supplied sources do not confirm minimum hardware requirements, a complete compatibility matrix, or performance data, so those details should not be assumed for capacity planning.
The project describes Kubernetes as part of its architecture. Operators should therefore plan for cluster operations, persistence, upgrades, backups, and an OpenTelemetry receiver or equivalent observability pipeline. Zero-trust and secretless access do not remove the need to review policy mistakes, identity-provider outages, excessive upstream permissions, or audit-data handling.
Licensing requires particular attention. Repository metadata identifies AGPL-3.0, while the README and project page display both AGPL-3.0 and Apache-2.0 license files or badges. The supplied sources do not explain the scope for each component. Organizations embedding Octelium in a product or offering it as a network service should inspect the repository license files and component terms before adoption.
Sources
Sources checked: 2026-10-18