When you deploy infrastructure for a community, you need to expose services safely. A Nextcloud instance behind a reverse proxy. A Matrix homeserver on a non-standard port. An internal API for a community application. The default answer from the internet is Cloudflare Tunnels or ngrok — both proprietary, both routing your traffic through someone else's servers.

For communities that care about sovereignty, that's not acceptable. The alternatives have been WireGuard (good, but L3 — no application-layer awareness), Tailscale (convenient, but a third-party control plane), or building your own VPN + reverse proxy + access control stack from parts.

Octelium is a new option that's worth a look.

What It Is

Octelium is a self-hosted, unified zero-trust secure access platform. Written in Go. AGPL-3.0 and Apache-2.0 dual licensed. 3,900 GitHub stars, 1,685 commits. The project describes itself as operating across several roles:

  • Remote access VPN — WireGuard/QUIC tunnels for client-based access to private resources
  • ZTNA / BeyondCorp — identity-based, application-layer (L7) access control on a per-request basis
  • ngrok / Cloudflare Tunnel alternative — public, clientless access to internal services
  • API gateway — routing, policy enforcement for internal and external APIs
  • AI/LLM and MCP gateway — access control for AI agent architectures
  • PaaS — containerized application deployment
  • Kubernetes gateway/ingress

That's a broad surface area. In practice, the core value proposition is: one self-hosted binary that handles secure access to your services with per-request, context-aware policy — no third-party control plane, no traffic routing through a vendor.

Why It Matters for Community Deployments

The typical community infrastructure deployment looks like this: a Proxmox node running a few containers — Nextcloud, Matrix, maybe Keycloak. You need to expose some of these to the internet (Nextcloud for remote access, Matrix for federation) and keep others internal (admin interfaces, databases, monitoring).

The current approaches each have problems:

Cloudflare Tunnels route your traffic through Cloudflare's network. Cloudflare can inspect, log, and terminate your TLS. For a community that chose self-hosting specifically to avoid third-party data processing, this defeats the purpose.

ngrok is proprietary, has rate limits on the free tier, and routes through ngrok's servers. Same problem.

WireGuard gives you encrypted L3 tunnels but no application-layer access control. You can reach the network or you can't. There's no "this user can access Nextcloud but not the admin panel" granularity.

Tailscale is the pragmatic choice many communities use. It's WireGuard under the hood with acoordination server. The control plane is third-party (Tailscale the company), though the data plane is peer-to-peer. For communities that accept "convenient with a third-party control plane" this works. For communities that want zero third-party dependencies, it doesn't.

Octelium fills the gap: self-hosted control plane, WireGuard/QUIC data plane, per-request L7 access policy. You run it on your own infrastructure. No traffic touches a third party. Access decisions are made by a policy engine you control.

The Technical Details

The architecture is a cluster model — an Octelium cluster with a control plane and data plane. Clients connect via WireGuard or QUIC. Access is granted per-request based on identity, context, and policy. The policy model is ABAC (attribute-based access control), not just RBAC — you can write rules like "allow this user to access this endpoint during business hours from this device posture."

It supports both private (client-based) and public (clientless) access. The clientless mode is the ngrok replacement — you can expose an internal service publicly with access control in front of it, without a VPN client.

The AI/LLM gateway and MCP gateway capabilities are interesting if you're building community AI infrastructure. It can sit in front of AI services and enforce access policy, rate limiting, and audit logging. For a community running local AI models (which is increasingly practical), this is the access layer.

The Honest Concerns

Here's where I have to be skeptical, because this project has a real governance problem.

No external contributions accepted. The README states plainly: "The project is not currently open to external contributions. In other words, pull requests will not be accepted." The code is AGPL-3.0, which means you can fork it, modify it, and distribute modifications. But the upstream is controlled by a single entity — Octelium Labs, LLC — and they're not accepting community contributions.

This matters for sovereign infrastructure. The whole point of FOSS for community deployments is that the community can participate in the software's development, not just consume it. A project that releases source code but doesn't accept contributions is "source available" in practice, even if the license is AGPL. If the maintainer stops working on it, you have a fork, not a community.

Single-entity governance. Octelium Labs, LLC owns the trademark. There's no foundation, no community council, no governance model documented. Compare this to Matrix (Matrix.org Foundation), Nextcloud (Nextcloud GmbH but with a clear community contribution model), or Keycloak (Red Hat but with an open contribution process). If Octelium Labs decides to change direction, close the source, or stop maintaining it, the community has no structural recourse beyond forking.

Broad surface area. A platform that tries to be a VPN, ZTNA, API gateway, AI gateway, PaaS, and Kubernetes ingress is either very well-architected or trying to do too much. I haven't deployed it in production. The README is comprehensive, the docs site exists, and the commit history shows sustained development. But breadth isn't depth, and for community infrastructure, you need the specific feature you rely on to be solid, not just present.

When to Use It vs. When Not To

Use it if: You're building a multi-service community infrastructure deployment and you need application-layer access control without a third-party control plane. You're comfortable running a Go binary cluster and writing ABAC policies. You need an ngrok replacement that doesn't route through a vendor.

Don't use it if: You just need remote access to a single Nextcloud instance. WireGuard configured manually or via Proxmox 9.2's native SDN is simpler, has no governance concerns, and is battle-tested. Don't deploy a zero-trust platform when a VPN solves your problem.

Don't use it if: Community governance of the software itself is a hard requirement for your deployment. As of July 2026, Octelium doesn't offer that. If the maintainer loses interest, you're maintaining a fork.

The Broader Pattern

Octelium represents a pattern I'm seeing more of in the FOSS infrastructure space: powerful self-hosted tools that solve real problems but are built by individuals or small companies without a community governance model. The license is right (AGPL-3.0). The code is open. The contributions are closed.

This is better than proprietary. It's better than source-available with a non-compete clause. But it's not the same as a community-governed project, and for infrastructure that a community will depend on for years, that distinction matters.

The ideal outcome is that Octelium succeeds enough to attract a community, the maintainer opens contributions, and it becomes a proper FOSS project with distributed governance. The AGPL license makes that transition structurally possible — if Octelium Labs stops maintaining it, the community can fork and continue. That's the AGPL doing its job.

Until then: it's a tool worth knowing about, worth evaluating for the right deployment, and worth being honest about its limitations.

The code is at github.com/octelium/octelium. Docs at octelium.com/docs. Read the README, read the policy model docs, and decide for yourself whether the governance model is acceptable for your community's risk profile.