# Octelium: a self-hosted zero trust access platform that spans VPN, ZTNA and gateways

> Octelium bundles WireGuard/QUIC client access, clientless BeyondCorp-style access, tunnels, an API/AI gateway and a PaaS into one Kubernetes-backed platform under AGPL-3.0. It is broad by design, and that breadth is the first thing to judge before you deploy it.

**octelium/octelium** — A next-gen FOSS self-hosted unified zero trust secure access platform that can operate as a remote access VPN, a ZTNA platform, API/AI/MCP gateway, a PaaS, an ngrok-alternative and a homelab infrastructure.

- Repository: https://github.com/octelium/octelium
- Website: https://octelium.com/docs
- Stars: 4,079 · Forks: 153
- Language: Go
- License: AGPL-3.0
- Published: 2026-09-23 · Updated: 2026-09-23 · Language: en
- Canonical page: https://hysenlabs.com/projects/octelium-octelium

## The problem Octelium targets: many access tools, one identity model

Most teams end up with a stack rather than a product. A VPN for engineers, a tunnel service for exposing an internal web app, an API gateway in front of microservices, and a separate proxy for SaaS credentials. Each has its own identity source, its own policy language and its own audit trail. Octelium's pitch is that these are the same problem seen from different angles: identity-based, application-layer access to a resource that may sit behind NAT or may be public. The README describes it as a unified zero trust secure access platform that can act as a remote access VPN, a ZTNA/BeyondCorp platform, an ngrok or Cloudflare Tunnel alternative, an API gateway, an AI/LLM gateway, a PaaS-like deployment platform and a Kubernetes ingress alternative.

The audience is correspondingly wide, and that is worth being honest about. It fits platform teams who already run Kubernetes and want one control plane for human and workload access. It also fits homelab operators who want remote access to devices behind NAT plus a place to deploy containers. It does not fit someone who wants a five-minute tunnel for a single port. The README lists use cases rather than a target user, so the reader has to do that sorting themselves.

## How Octelium works: identity-aware proxies over WireGuard and QUIC

The architecture described in the README is a set of identity-aware proxies that enforce access at layer 7, built on Kubernetes for scaling. Two access paths are offered. The first is client-based: a private tunnel over WireGuard or QUIC, described as zero-config, which is the VPN-like mode. The second is clientless, the BeyondCorp pattern, where a user reaches a resource through a browser-facing proxy without installing a client.

Policy is expressed as policy-as-code and evaluated per request, with context awareness. That per-request evaluation is the part that separates this from a classic VPN, where the decision is made once at connection time and the network position does the rest. Access control is identity-based and secretless, meaning users reach resources protected by application-layer credentials without those credentials being handed to them. The repository layout matches the description: apis/ holds protobuf definitions split into main, cluster, client and rsc, client/ holds the client code, cluster/ holds the cluster components, and pkg/ holds shared Go packages. The Makefile generates Go and gRPC stubs from those protobufs and builds CLI binaries, which tells you the client and cluster talk over gRPC rather than a bespoke protocol.

The breadth is real, and so is the cost. A single binary that can be a VPN, a gateway and a PaaS has a larger configuration surface than any one of those tools alone. The README points to a separate how-octelium-works page for the detail, and that page is where you should go before designing anything.

## Installing the CLI and standing up a first cluster

The README has two install-oriented sections in its table of contents: Install CLI Tools and Install your First Cluster. The README text itself does not spell out the commands, so the authoritative source is the documentation site at octelium.com/docs. Do not guess at package names or flags. What the repository does tell you is how the project is built from source, which is useful if you are evaluating it or building a custom image.

The Makefile defines the build targets and injects version metadata through ldflags, including the git commit, tag, branch and the image registry prefix. The registry defaults to ghcr.io with the octelium image prefix:

```makefile
REGISTRY ?= ghcr.io
IMAGE_PREFIX := octelium
LDFLAGS_PATH := $(REPOSITORY)/pkg/utils/ldflags
```

That means images are pulled from a GitHub Container Registry namespace with the octelium prefix unless you override REGISTRY. The protobuf toolchain is pinned in the Makefile, so regenerating the API stubs uses known plugin versions rather than whatever is latest:

```bash
make protoc-install
```

This installs protoc-gen-go at v1.36.1, protoc-gen-go-grpc at v1.5.1 and protoc-gen-doc at latest, then creates the generated docs directory. If you only want to run Octelium rather than contribute to it, you do not need this. For a first real use, follow the docs' cluster install page, then log in and create a Service that exposes an internal resource, and attach a Policy to it. The README links worked examples for HTTP services, a Next.js/Vite deployment, an API gateway and a self-hosted MCP gateway, which is the fastest way to see the policy model in practice. The README does not document rollback or uninstall steps.

## Where Octelium is the wrong tool

Kubernetes is not optional. The README states the architecture is built on top of Kubernetes for automatic scalability, and the repository has a cluster/ directory alongside client/. If you are not running Kubernetes and do not want to, this is a heavy dependency for what might otherwise be a single tunnel daemon. A homelab with one Raspberry Pi can run Kubernetes, but the operational cost is real and the README does not present a non-Kubernetes deployment path.

The second limitation is scope creep in the configuration surface. Every capability listed in the README (VPN, ZTNA, tunnels, API gateway, AI gateway, MCP gateway, PaaS, Kubernetes ingress) brings its own concepts. A team that only needs an SSH bastion will spend time learning concepts it will never use. The README's use-case list is written as an invitation, not as a warning about the learning curve.

Third, the README does not document rollback or uninstall. That matters for a platform that sits in the access path of your infrastructure. Before you put it in front of production resources, you need your own answer for how you remove it, and the documentation available here does not give you one. Treat that as a gap to resolve, not a detail.

## Octelium compared with single-purpose access tools

The README names its own comparisons, which is a useful starting point. For remote access it positions itself against OpenVPN Access Server, Twingate and Tailscale, with the stated difference being layer-7 awareness and per-request, context-aware policy rather than network-level reachability. For ZTNA it names Cloudflare Access, Google BeyondCorp and Teleport. For tunnels it names ngrok and Cloudflare Tunnel, with the difference being self-hosting. For API gateways it names Kong Gateway and Apigee. For PaaS it names Vercel and Netlify.

The honest framing is that Octelium is not trying to be better than each of these at its own job. It is trying to be one system where the identity and policy layer is shared. If you already run Teleport for SSH and Kong for APIs and you are happy with two policy models, consolidating onto Octelium buys you a single policy language at the cost of migrating both. If you run Tailscale because you want a mesh that works without a control plane you operate, Octelium's self-hosted model is the opposite trade: you own the control plane and the uptime.

The comparison that the search data suggests people make, Octelium versus Teleport, comes down to this. Teleport is centered on infrastructure access with its own protocol handling; Octelium centers on L7-aware policy across private and public resources with a WireGuard/QUIC client path and a clientless path. Which one fits depends on whether your access problem is mostly SSH and Kubernetes or mostly HTTP and API surfaces.

## Licensing, releases and the upgrade cost

The repository carries two licence files at the top level: LICENSE-AGPL-3.0 and LICENSE-APACHE. The project description lists AGPL-3.0 as the licence, and the README badges show both Apache 2.0 and AGPL v3. The README does not break down which components fall under which licence, and that distinction matters if you intend to embed Octelium components in something you distribute. This is not legal advice; read both files and the Legal section of the README before you build a product around it.

Release cadence is visible from the tags. v0.40.0, v0.41.0 and v0.42.0 were published on 2026-08-23, 2026-08-31 and 2026-09-08 respectively, roughly weekly, and the last push to the repository was on 2026-09-20. That is a fast-moving project. Weekly minor releases mean you should expect to read release notes before upgrading, and you should not assume a quiet maintenance branch. The README does not describe an upgrade procedure or a compatibility policy between versions, so pinning a version and testing the upgrade path yourself is the only defensible approach. For a platform in the access path, that is a standing operational cost, not a one-time setup task.

## Conclusion

Adopt Octelium if you want one self-hosted control plane for client-based WireGuard/QUIC access and clientless L7 policy over private and public resources, and you are willing to run it on Kubernetes. Do not adopt it if you need a single-purpose tool you can reason about in an afternoon, or if AGPL-3.0 obligations across the cluster components are a problem for your distribution model. Before committing, verify the exact CLI install commands and cluster install steps on the docs site, confirm which components fall under LICENSE-APACHE rather than LICENSE-AGPL-3.0, and read the how-octelium-works page to check that the identity-aware proxy model matches your network layout.

## FAQ

### What does Cloudflare Access do?

The README names Cloudflare Access as one of the ZTNA platforms Octelium is positioned against, alongside Google BeyondCorp and Teleport. It does not describe Cloudflare Access's own behaviour.

### What does Cloudflare Access do?

The README lists Cloudflare Access among the ZTNA platforms Octelium competes with, but it does not explain what Cloudflare Access itself provides. For that, the Cloudflare documentation is the source, not this repository.

### What does Cloudflare Access do?

Octelium's README positions itself as a ZTNA platform similar to Cloudflare Access, Google BeyondCorp and Teleport, so Cloudflare Access is treated as a peer rather than described in detail. Details of its behaviour are outside this material.

## Sources

- [License: AGPL-3.0](https://github.com/octelium/octelium/blob/main/LICENSE)
- [octelium/octelium on GitHub](https://github.com/octelium/octelium)
- [Project website](https://octelium.com/docs)
- [README](https://github.com/octelium/octelium/blob/main/README.md)
- [Releases](https://github.com/octelium/octelium/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/octelium-octelium