One Binary, Six Categories: What Octelium's VPN-ZTNA-MCP-Gateway-PaaS Convergence Actually Buys and Costs

Most self-hosted infrastructure tools pick one job and do it well: a VPN, a reverse proxy, a deploy target. Octelium picks six. The 3.9k-star, AGPL-licensed project bills itself as a single binary that replaces a remote-access VPN, a ZTNA/BeyondCorp platform, an ngrok-style tunnel, an API and MCP gateway, and a PaaS-like container deployment layer — all running out of the same Cluster.

The interesting part isn't the feature count. It's the specific bet Octelium is making on AI agents: instead of the shared bearer token most MCP servers hand out today, every agent gets its own OAuth2 client-credentials identity, and every tool call gets evaluated at Layer 7 — path, method, headers, and the serialized JSON-RPC body itself — before it's allowed through. That's a real answer to a real problem. It also arrives bundled inside a pre-1.0, single-company, closed-to-external-PRs binary that also happens to be your VPN.

Does convergence make agent-to-tool traffic safer, or does it just concentrate six different kinds of risk into one blast radius? Both, as it turns out — and which one wins depends entirely on what you're using it for.

What One Binary Actually Replaces​

Octelium's GitHub README lists its use cases without much modesty: VPN, ZTNA, tunnel, gateway, PaaS, homelab. Here's what each of those categories actually maps to, and what tool a team would otherwise be running instead.

For a solo operator or a small team, that table is the whole pitch: one octeliumctl instead of gluing together a VPN control plane, a separate reverse proxy, an MCP gateway config, and a deploy pipeline. The license is split cleanly along a client/server line — the CLIs and Go SDK are Apache 2.0, everything under /cluster (the part that actually runs your access control and routing) is AGPLv3, with Octelium Labs LLC selling a commercial license to anyone who doesn't want the copyleft terms attached to a system they're building a product on top of.

Some rows in that table are genuinely equivalent to the dedicated tool. Others are thinner. The MCP gateway row is the one worth slowing down on, because it's the one making the most specific technical claim.

The Per-Agent Identity Model for MCP​

Here's the failure mode Octelium is explicitly designing against: a single API token, scoped once at creation time, that ends up covering every operation an agent might ever call through it. It's the same shape of failure that's shown up repeatedly in 2026's agent-incident postmortems — a token minted for one narrow purpose (say, managing DNS records) turns out to also carry destructive access to something unrelated (say, deleting a database), because the platform issuing it never modeled "this token, this operation, nothing else."

Octelium's answer is to stop treating an agent's credential as a single flat scope and start treating it as an identity. Every MCP client authenticates individually through the OAuth2 client-credentials flow — no bespoke SDK required, any OAuth2-capable client works. Once authenticated, access decisions aren't "does this token have API access" but "does this specific identity, on this specific request, match a CEL or OPA policy that allows this HTTP path, this method, these headers, and this serialized JSON-RPC body content." An agent's tool call to deploy.rollback and its tool call to logs.read can carry the same token and still be evaluated as two entirely separate authorization decisions, because the policy engine is reading the request body, not just checking a bearer header against an allowlist.

Concretely: instead of one Railway-style API token with blanket access to every domain and volume operation a CLI supports, an agent calling through an Octelium-fronted MCP gateway gets a policy that can say "this identity may call POST /rollback for service X, and nothing else" — evaluated per request, logged via OpenTelemetry with the full JSON body attached, not inferred after the fact from an audit log that only recorded "token Y made a call."

That's a materially better default than the shared-token model most MCP integrations still ship with today. It's also not exclusive to Octelium — it's a design pattern, not patented technology, and it's adoptable by any platform willing to build it.

What Convergence Costs​

The same six-in-one binary that makes the identity model possible also concentrates four real costs that a narrower, purpose-built tool doesn't carry.

AGPLv3 on everything that matters. The client CLIs are permissively licensed, but every component that actually enforces access control and routes traffic — the part under /cluster — is AGPLv3. That license's network-use clause means offering Octelium's Cluster functionality as a service to others typically triggers source-disclosure obligations, which is exactly why Octelium Labs sells a commercial license as the escape hatch. That's not unusual for infrastructure software, but it's a cost the "self-hosted VPN alternative" framing doesn't lead with, and it's worth pricing in before a business builds a commercial offering on top of the free tier.

A bus factor of roughly one. Octelium is built and maintained by Octelium Labs LLC, and the project's own contribution policy is unambiguous: "the project is not currently open to external contributions. In other words, pull requests will not be accepted." Bug reports and feature requests are welcome; code changes from anyone outside the company are not. That's a defensible choice for a young project protecting its architecture pre-1.0 — but it means a tool sitting in the critical path of a team's VPN, access control, gateway, and deploy target all at once has exactly one company that can fix it when something breaks.

Pre-1.0, by the maintainer's own account. As of the v0.37.0 release on July 2, 2026, Octelium describes itself as "getting ready for v1.0 soon," with architecture and APIs "stabilized" ahead of open-sourcing — a claim worth taking at face value, but still a claim about software that hasn't hit a 1.0 tag. Six categories of infrastructure risk are riding on a project that, by its own version number, isn't done yet.

One blast radius for six jobs. This is the structural cost, independent of licensing or maintainer count. If the Cluster misconfigures a policy, restarts badly, or hits a bug in its gateway logic, the failure doesn't stay contained to "the VPN is down" or "the deploy pipeline is stuck." It's all of them, at once, because they're the same process reading the same policy store. A composed stack — Teleport for access, a purpose-built gateway for MCP traffic, a separate deploy platform — has the opposite property: a bad Teleport config doesn't take your deploy pipeline down with it, because they were never sharing a fault domain to begin with.

None of these four costs make Octelium a bad project. They make it a concentrated one, and concentration is a trade a team should make deliberately, not inherit by default because the README listed six use cases and the setup instructions only needed one binary.

Where Convergence Wins, Where It Doesn't, and What Bex Should Borrow Either Way​

For a homelab, a solo developer, or a small team that would otherwise be hand-wiring Tailscale, Teleport, an ngrok tunnel, an API gateway, and a deploy tool into something that vaguely holds together, Octelium's convergence is a genuine win. The integration tax of gluing five separate control planes together is real, and collapsing it into one octeliumctl and one Cluster is worth the AGPL terms and the single-vendor risk for a team that isn't running production revenue through it.

That calculus flips once a team treats one of those six categories as its most safety-critical surface. For a platform whose entire pitch is that an AI agent can deploy and roll back a running service through the same API a human uses, deploy authority isn't a feature alongside VPN and tunneling — it's the thing the whole business depends on getting right. Concentrating that authority inside a pre-1.0, single-maintainer, closed-to-outside-code binary is a different risk profile than a dedicated deploy platform that does exactly one job and composes with whatever zero-trust access layer — Octelium included — a team already trusts.

And that leaves the question the comparison actually turns on: should a platform like bex borrow Octelium's per-agent identity model for its own MCP surface, regardless of whether it ever runs Octelium itself? Yes. The reasoning has nothing to do with adopting the binary and everything to do with the status quo it's reacting against — most deploy-from-chat MCP integrations today, bex's included, are only as scoped as the API key sitting behind them. Octelium's actual contribution isn't the VPN or the tunnel; it's proof that per-agent OAuth2 identity plus request-body-aware policy is a shippable pattern for exactly the kind of deploy/rollback/logs tool calls an MCP-driven agent makes. A platform doesn't need to run Octelium's Cluster to decide that "one identity per agent, one policy decision per request" is the right default for its own gateway — it needs to build it.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own, with a Render-compatible API that treats an agent's deploy call as a first-class citizen. It doesn't try to also be your VPN or ZTNA layer — it composes with whatever zero-trust access a team already runs, Octelium or otherwise. Star the repo on GitHub or deploy your first app today.

Sources​

• Octelium GitHub repository — stars, license split, v0.37.0 release date, contribution policy
• Octelium official site — product overview and use-case list
• Octelium MCP gateway solution page — per-agent OAuth2 identity model, CEL/OPA policy details
• Octelium README — license breakdown by directory, "pull requests will not be accepted" contribution policy, supported deployment targets
• Tailscale, Teleport, and NetBird 2026 pricing and positioning coverage, used for the VPN and ZTNA comparison landscape in this article.