OpenZiti: a self-hosted zero-trust overlay network built on the ziti CLI

What OpenZiti actually removes from your network

The README frames the product as "an open-source zero-trust networking platform that makes network services invisible to unauthorized users". That sentence is the whole pitch, and it is worth unpacking because it changes what you have to defend. In a conventional setup, a service listens on a port, and the firewall decides who may reach it. In OpenZiti, the service itself has no listening port on the public network. An authorized client connects through the overlay, and everyone else sees nothing to scan. The README calls this a dark service and lists it as the first key capability: "Services have zero listening ports. Invisible to scanners and unauthorized users."

The intended audience is broader than the usual zero-trust buyer. The README names several groups explicitly: teams replacing VPNs, teams exposing APIs that should not be on the internet, IoT and machine-to-machine deployments, workload-to-workload traffic across clouds, and self-hosted users who want to reach a home lab service without opening a router port or depending on a third-party tunnel. There is also a section on agentic AI, where MCP servers and tool endpoints stay dark and each agent authenticates with its own identity. That last use case is the newest framing in the README, and it is the one where the identity model does the most work, because an autonomous process holding a long-lived credential is exactly the case where IP allowlists stop being meaningful.

Controller, edge routers and tunnelers: the shape of the overlay

The architecture image in the repository is captioned "Controller, Edge Routers, SDKs, and Tunnelers", and that caption is a fair map of the moving parts. The controller is the control plane. It holds identities and policies, issues the certificates and tokens used to enroll clients, and serves the management REST API plus a web admin console. Edge routers are the data plane. They form a mesh, and the README describes "Smart Routing" as "Mesh fabric with intelligent path selection for performance and reliability". Clients reach the overlay either through a tunneler, which intercepts traffic without code changes, or through an SDK embedded in the application.

The README lays out three deployment models, and they differ only in where the trust boundary sits. Network Access puts an edge router in a trusted zone and lets it forward traffic into the private network; no agent runs on the service host and no code changes are needed. Host Access runs a tunneler on the same machine as the service, so the service only has to accept connections from localhost and is invisible to the rest of the network. Application Access embeds an SDK and is described as the strongest model, because the application itself holds the identity and the trust boundary is inside the process. The README explicitly says you can mix these in one network and migrate between them over time, which is the practical answer for anyone with a mix of legacy services and new code.

Encryption is end to end, and the README is specific about the primitive: "Data encrypted from source to destination using libsodium. mTLS for authentication." Access revocation is also described as immediate, closing active connections in real time. That is a meaningful difference from a firewall rule change, which typically only affects new connections.

Installing OpenZiti and bringing up a first service

The repository ships a quickstart directory with subdirectories for docker, kubernetes, local and aws, plus a quickstart/README.md. The Docker path is the shortest route to a working controller and router on one machine. From the quickstart/docker directory, the README's compose file is started with:

docker compose up

After the containers come up, the controller's management API and console are reachable on the host. The CLI that talks to it is the ziti binary, and the quickstart uses it to log in before creating anything. The exact credentials and URLs are printed by the compose setup; the README does not restate them, so read the output rather than guessing.

Once you are logged in, the first real object is an identity, and the ziti CLI is how you create one. The enrollment step is documented in the quickstart rather than the top-level README, so follow quickstart/README.md for the exact command sequence and the file the tunneler consumes.

The next step is the service itself, which is a pair of objects: a service that describes what is being reached, and a config that describes how. For a host-access setup the config is an intercept/host pair, and the service is bound to it. Policy then decides who may dial it. The README does not print a full policy example, so the authoritative sequence is the one in quickstart/README.md rather than anything reconstructed here.

The Kubernetes path lives under quickstart/kubernetes/ and the AWS path under quickstart/aws.md. Both are documented in the repository rather than in the top-level README, which is worth knowing before you start, because the main README stops at the architecture and capability level and hands you off to those directories.

Where OpenZiti is the wrong tool

OpenZiti is infrastructure, and infrastructure has an operator cost. If nobody on your team will run the controller, keep its certificate authority healthy, and upgrade edge routers, you have moved the problem rather than solved it. The README's managed-solution section points at NetFoundry for teams in that position, which is an honest signal that self-hosting is a commitment and not a checkbox.

The second boundary is public reachability. OpenZiti is designed to make services invisible. If your actual requirement is that anyone on the internet can reach a service without enrolling an identity, the overlay is working against you, and a conventional reverse proxy with TLS is the simpler answer. The same applies to latency-sensitive paths: traffic is routed through edge routers, and the README does not publish latency figures or a routing-cost model, so the only way to know whether the mesh path is acceptable is to measure it on your own topology.

The third boundary is version drift. The repository currently carries v1.5.18, v1.6.21 and v2.0.6, and the go.mod declares module github.com/openziti/ziti/v2 with go 1.27.1. The presence of an lts-versions.json file at the repository root suggests long-term-support lines exist, but the README does not explain which line a new deployment should start on. That is a real gap for anyone planning an upgrade path, and it is the first thing to resolve with the project's own release policy document before you standardize.

OpenZiti compared with NetBird and with a plain overlay like WireGuard

The most common comparison people search for is OpenZiti versus NetBird, and the difference is in what carries the identity. NetBird and WireGuard-based overlays build a peer-to-peer encrypted network and then authorize peers by IP or by peer group. Once a peer is on the network, reachability is largely a routing question. OpenZiti authorizes at the service level: the README states that "Each service is individually authorized" and warns about the "once you're in, you can reach everything" problem. In practice that means a compromised laptop on an OpenZiti network does not inherit reachability to every other host, because each service requires its own policy grant.

The other structural difference is the SDK. WireGuard and most peer overlays are purely network-level; an application cannot hold its own identity. OpenZiti's Application Access model puts an SDK inside the process, so the workload authenticates directly and the trust boundary sits in the code. That is more work to adopt and strictly stronger. If your services are all off-the-shelf and you will never modify them, the tunneler path is the one you will use, and the SDK advantage does not apply to you. If you are writing the services, it does.

Licence, releases and the cost of staying current

OpenZiti is licensed under Apache-2.0, and the README states the project is "Created and sponsored by NetFoundry". Apache-2.0 permits commercial use and modification, and it includes a patent grant. It does not, on its own, settle questions about the certificates you generate, the data you route, or the obligations you owe your own customers. Those are fact-specific, and nothing here is legal advice.

The upgrade surface is the part to budget for. The repository root contains RELEASE_POLICY.md, RELEASING.md, CHANGELOG.md and a changelogs directory, so the project does document its release process, and lts-versions.json indicates that some lines are designated long-term support. Three release lines were published within days of each other in September 2026, which means backports are active across more than one branch. In practice, an operator should pick a line, read RELEASE_POLICY.md to understand how long it is supported, and treat edge router upgrades as a scheduled activity rather than an emergency. The README does not describe an in-place upgrade procedure for edge routers, so that procedure has to come from the release notes or the Discourse forum.

Editorial conclusion

Adopt OpenZiti when you need identity-based access to services that currently sit behind a VPN or an exposed port, and you are willing to run a controller and at least one edge router yourself, either from the quickstart Docker Compose setup or the Kubernetes manifests under quickstart/kubernetes/. Skip it if you have no one to operate the controller and routers, or if you only need to publish a public website, since OpenZiti is built around making services invisible rather than reachable by everyone. Before committing, verify three things in your own environment: that the tunneler for your operating system is available for your users, that the overlay path between your edge routers meets your latency budget, and that the policy model in your version matches what you plan to write, because the repository carries three release lines at once (v1.5.18, v1.6.21 and v2.0.6 were all published in September 2026) and the go.mod module path is github.com/openziti/ziti/v2.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. openziti/ziti on GitHub
3. Project website
4. README
5. Releases