What is OpenZiti?
OpenZiti is an open-source zero-trust networking platform that hides network services from unauthorized users. Each user, service, device or workload carries a cryptographic identity backed by x509 certificates, every connection is authorized against policy, and traffic is encrypted end to end. Services can be "dark", meaning they have no listening ports and connect outward to the overlay instead. The project was created and is sponsored by NetFoundry, and the core repository openziti/ziti is licensed under Apache 2.0.
The platform has three main components. The controller is the management plane: it issues and verifies identities, stores policies and network state, and exposes REST APIs and a web admin console (ZAC). Edge routers form the data plane, a mesh fabric that carries encrypted traffic and selects paths by latency, throughput and cost; public routers are reachable from the internet, while private routers make only outbound connections. Endpoints connect through SDKs embedded in applications (Go, C, Python, Node.js, Java and Kotlin, Swift, C#) or through tunnelers for Linux, Windows, macOS, iOS and Android that carry traffic for unmodified software. Data-path encryption uses libsodium, and authentication uses mTLS.
The latest GitHub release is v2.0.8, published on October 8, 2026, a bug-fix release that resolves controller and router deadlocks and link-reporting issues. Version 2.0.0 (May 2026) declared HA controller clusters ready for general use, switched authentication to JWTs by default, introduced a new permissions model and OIDC or JWT token-based enrollment. 2.x routers only work with 2.x controllers, so controllers are upgraded first. A published release policy makes 2.0 the current LTS and 1.6 the maintenance LTS; the 1.6 line continues to receive fixes, most recently v1.6.22 on October 19, 2026.
Release archives contain the single ziti binary for Linux (amd64, arm, arm64), macOS (amd64, arm64) and Windows (amd64), along with SHA-256 checksums and an SPDX SBOM. The ziti CLI runs the controller and routers, manages the network, and can start a local development network with ziti edge quickstart. An all-in-one Docker Compose file starts a controller, an edge router and the console. Documentation, quickstarts and deployment guides are hosted on the NetFoundry documentation site, and questions go to the OpenZiti Discourse forum.
The whole platform can be self-hosted with no vendor dependency. NetFoundry also operates a managed, globally distributed OpenZiti network as a service with SLAs and enterprise support. The README lists production adopters such as DeltaSecure and Resulticks and open-source projects built on OpenZiti, including zrok and BlueBubbles. Other private-networking listings on iThub include NetBird and Nebula.
OpenZiti screenshots
Explore the interface. Open a screenshot to view it at full size.

Official OpenZiti architecture figure from the project README.

Official overview of the network, host and application access models, from trusted network zones to fully zero-trust connections.

Documentation figure of an HTTP service reached through Ziti tunnelers and edge routers across the overlay fabric.

Topology of the Docker Compose quickstart: controller, admin console and edge routers across purple, blue and red networks.
Source: official OpenZiti project page.
Key capabilities
- Identity for every participant Users, services, devices and non-human workloads each receive a unique cryptographic identity backed by x509 certificates. Access decisions use these identities and policies rather than IP addresses or network location, so being on the same LAN grants no extra access.
- Policy-driven access A connection succeeds only when the identity is valid and enrolled, a policy grants it the requested service, and it passes through an authorized edge router. Each service is authorized separately, and revoking access terminates active connections.
- Dark services A service, or the tunneler beside it, connects outbound to an edge router and registers itself, so it has no listening ports. Port scans find nothing, and because all connections are outbound, CG-NAT, double NAT and restrictive firewalls do not block it. Private edge routers are dark in the same way.
- End-to-end encryption With SDKs, traffic is encrypted from the sending application to the receiving application with libsodium, so routers and intermediate networks cannot read or alter it. With tunnelers, encryption covers the path between tunnelers or between a tunneler and an SDK.
- Three deployment models Network access places an edge router in a trusted zone with no code changes. Host access runs a tunneler on the service host so the service only accepts localhost connections. Application access embeds an SDK so the application holds the identity and has no listening ports, not even on localhost. The models can be mixed in one network.
- Controller with HA clustering The controller manages identities, policies, services and routers. Since 2.0.0, HA controller clusters are considered ready for general use, and authentication uses JWTs by default so sessions do not have to be stored and pushed to routers.
- Mesh edge routers with smart routing Routers discover each other, form mesh links and choose paths based on latency, throughput and cost. Public and private routers can be combined, with private routers needing no inbound firewall rules.
- SDKs in seven languages Official SDKs exist for Go, C, Java and Kotlin (including Android), Swift (iOS and macOS), Node.js, C# and .NET, and Python. The C SDK is described as suited to embedded systems and IoT. The 2.0 release policy states that the latest SDK releases work against any active LTS controller and router.
- Tunnelers for unmodified software Desktop Edge for Windows, edge clients for macOS and iOS, an Android client and the Linux tunneler intercept traffic for existing applications and route it through the overlay. The tunneler reference covers installation and configuration, including a Kubernetes sidecar.
- Management and client REST APIs The controller exposes an Edge Management API for creating identities, services and policies and an Edge Client API for SDKs to authenticate and dial or bind services. Both have OpenAPI 2.0 specifications, and a running controller serves API reference pages, as described in the API documentation.
- Ziti Admin Console ZAC is a web console for identities, services and policies. It can be installed into a controller with
ziti ops console downloadandconfigure, or served locally withziti run consoleand pointed at any controller. - ziti CLI One binary provides the controller, routers and administration commands such as
ziti edge.ziti edge quickstartbrings up a local controller, router and default admin identity for testing. - Docker quickstart An all-in-one Compose file from
get.openziti.iostarts a controller, an edge router and the console, with the console athttps://localhost:1280/zac/. Separate quickstarts cover local, Docker and hosted environments. - Token-based enrollment Version 2.0.0 introduced OIDC and JWT token-based enrollment for identities, together with a new permissions model.
- LTS release policy 2.0 is the current LTS with security and critical fixes, 1.6 is the maintenance LTS with security and critical production fixes, and only sequential LTS upgrades are tested. Releases between LTS cuts form a development track without LTS guarantees.
- Release artifacts Each GitHub release ships
zitiarchives for Linux, macOS and Windows, a source tarball, SHA-256 checksums and an SPDX SBOM. - Security process The project publishes a vulnerability disclosure policy, a product security incident response process and a safe-harbor statement, with reports going to security@openziti.org and a response within 7 days.
Where OpenZiti fits
Replacing a VPN for internal services
Instead of a VPN concentrator that grants access to a whole network, OpenZiti authorizes each service separately. Users run a tunneler on their device, enroll an identity, and reach only the services their policies allow, without split-tunneling configuration or inbound firewall rules.
Making APIs and services dark
A service host runs a tunneler, or the application embeds an SDK, and connects outbound to the overlay. The service has no public listening port; only identities with a matching policy can reach it, and only through OpenZiti routers.
IoT devices and non-human identities
Devices, sensors and machines receive their own x509-backed identities, which the C SDK and tunnelers use for authenticated machine-to-machine connections. The README notes that the identity model treats non-human workloads the same way as human users.
Agentic AI and MCP servers
The README describes securing agent-to-service and agent-to-agent traffic: MCP servers, tool endpoints and private LLMs stay dark with no public URLs, and each agent authenticates with its own identity and reaches only the resources its policy allows.
Multi-cloud, Kubernetes and hybrid connectivity
One overlay spans AWS, Azure, GCP, on-premises data centers and edge locations. Services in different Kubernetes clusters, VMs, bare metal and IoT devices connect without ingress rules, VPN tunnels between environments or peering, and the documentation includes a Kubernetes sidecar pattern.
Home lab and self-hosted service access
Self-hosted services such as Nextcloud, Home Assistant or media servers become reachable from anywhere without open router ports or dynamic DNS. The quickstart guides cover setting up a local or Docker-based network to begin with.
Upgrading between LTS lines
Networks on the 1.6 maintenance LTS move to the 2.0 LTS by upgrading the controllers first and then the routers one by one, since 2.x routers require 2.x controllers. The release policy states that only sequential LTS upgrades are tested and that 1.6 reaches end of life when the next LTS is cut.
Install
wget https://get.openziti.io/dock/all-in-one/compose.yml && docker compose upReviews of OpenZiti
Be the first to share your experience with OpenZiti.
Write a review
Loading review form…
