OpenZiti is an open-source zero-trust networking platform that makes network services invisible to unauthorized users. Every connection, whether from a user, a service, a device, or a workload, is authenticated with cryptographic identity, authorized by policy, and encrypted end-to-end.

OpenZiti works with both existing applications (using lightweight tunnelers with no code changes required) and new applications (using embedded SDKs for the strongest zero-trust model). This makes it practical for both brownfield environments and greenfield development.

Created and sponsored by NetFoundry. Licensed under Apache 2.0.

• Use Cases
• Key Capabilities
• Three Deployment Models
• Getting Started
• Architecture
• Zero Trust, Dark Services, and End-to-End Encryption
• SDKs
• Community & Support
• Contributing
• Adopters
• Managed Solution

OpenZiti enables you to extend zero-trust anywhere for any use case, including non-human workloads and workflows, across multiple networks and third parties. The following are some common use cases.

Provide secure access to internal services without VPN clients, split tunneling headaches, or concentrator bottlenecks. Each service is individually authorized. No "once you're in, you can reach everything" problem.

Make APIs and services invisible to the internet. Zero listening ports means zero attack surface. Authorized clients connect through OpenZiti; everyone else sees nothing.

Give every device, sensor, and machine a unique cryptographic identity. OpenZiti's identity model works for non-human workloads just as well as human users, providing strong authentication for the machine-to-machine connections that make up the majority of modern network traffic.

Secure workload-to-workload communication across clouds and environments. Services authenticate each other with cryptographic identity, not network location. No shared secrets, no IP allowlists, no ambient authority.

One overlay network across AWS, Azure, GCP, on-prem data centers, and edge locations. No cloud-specific networking tools, no VPN tunnels between environments, no complex peering arrangements.

Access home lab or self-hosted services like Nextcloud, Home Assistant, media servers, and development environments from anywhere. No open router ports, no dynamic DNS, no reliance on third-party tunnel services. You control the entire path.

Connect services across Kubernetes clusters without complex ingress rules, service mesh sidecars, or VPN tunnels between clusters. Works beyond Kubernetes, supporting connecting k8s services to VMs, bare metal, IoT devices, or anything else on the overlay.

Private and secure connectivity to MCP Servers and private LLMs.

OpenZiti supports three zero-trust models. Mix them in a single network and migrate between them over time.

Deploy an OpenZiti edge router in a trusted network zone. Traffic enters the overlay from authenticated clients and exits into the private network where services run.

• Code changes: None
• Agent on service host: None
• Security model: Identity-based access at the network boundary. Similar to a gateway, but with cryptographic identity and encrypted transport.

Run an OpenZiti tunneler on the same host as your service. The tunneler handles identity, authentication, and encryption. The service only needs to accept connections from localhost.

• Code changes: None
• Setup: Install tunneler, enroll identity
• Security model: Trust boundary at the host OS. Service is dark to the network and only reachable through the tunneler.

Embed an OpenZiti SDK directly in client and/or server applications. The application itself holds the cryptographic identity and encrypts traffic in-process. No listening ports exist, not even on localhost.

• Code changes: Yes
• Security model: Strongest. End-to-end encryption in-process. Fully dark. Identity at the application layer, not the network, not the host.

Where to start: Many teams begin with Host Access (tunnelers) for existing services. It deploys in minutes with no code changes. For new development or high-security workloads, Application Access (SDKs) provides the strongest zero-trust posture.

The following Quick Starts show how to set up a local OpenZiti network for development, testing, and learning. For production deployments, see the product documentation at https://netfoundry.io/docs/openziti/category/deployments/.

The fastest way to get a local OpenZiti network running:

wget https://get.openziti.io/dock/all-in-one/compose.yml
docker compose up

This starts a controller, edge router, and the Ziti console in a single compose stack. The console is available at https://localhost:1280/zac/. From here you can create identities, define services, and configure access policies.

See the all-in-one Docker quickstart for full details including storage options, environment variables, and CLI usage.

Download the latest ziti binary from GitHub Releases, then:

ziti edge quickstart

This brings up a local development network: controller, router, and a default admin identity. Ideal for testing and learning.

OpenZiti's overlay network runs on top of existing infrastructure: any IP network, any cloud, any combination. The core components:

The controller is the management plane. It handles:

• Identity management: issues and verifies cryptographic identities (x509 certificates) for every participant in the network
• Policy enforcement: defines which identities can access which services, through which edge routers
• Network state: tracks routers, services, and topology; provides a REST API and web-based admin console for management

Edge routers form the data plane, a mesh fabric that carries encrypted traffic between endpoints.

• Public routers are reachable from the internet, serving as entry points to the network
• Private ("dark") routers are deployed inside private networks with only outbound connections

Routers automatically discover each other, form mesh connections, and use smart routing to select the best path based on latency, throughput, and cost.

Endpoints are how applications and users connect to the OpenZiti network:

• SDKs (Go, C, Python, Node.js, Java, Swift, C#): embed zero trust directly in your application. The app itself holds the identity and handles encryption. No sidecar, no agent, no listening ports.

• Tunnelers (Linux, Windows, macOS, iOS, Android): lightweight apps that provide OpenZiti connectivity to unmodified software. Traffic is intercepted and routed through the overlay transparently. No code changes required.

Every participant (e.g., user, service, device, workload) in an OpenZiti network carries a unique cryptographic identity backed by x509 certificates. When a connection is attempted, OpenZiti verifies:

1. The identity is valid and enrolled
2. A policy exists granting that identity access to the requested service
3. The connection is through an authorized edge router

If any check fails, the connection is denied. If access is later revoked, active connections are terminated immediately. There is no implicit trust based on network location. Being on the same LAN grants no more access than being across the internet, unless policy explicitly allows it.

This model provides zero trust application segmentation: each service is independently authorized. Gaining access to one service does not grant access to any other.

A "dark" service has no open ports. It doesn't listen on any network interface for incoming connections. Instead, the service (or a tunneler alongside it) makes an outbound connection to an OpenZiti edge router and registers itself. Clients reach it only through the OpenZiti fabric, after authentication and authorization.

What this means in practice:

• Port scans find nothing: there are no listening ports to discover
• No attack surface: you can't exploit what you can't reach
• DDoS resistance: there is no public endpoint to flood
• Invisible to unauthorized users: only identities with matching policy even know the service exists
• NAT and firewall friendly: all connections are outbound, so CG-NAT, double-NAT, and restrictive firewalls are not a concern

Edge routers can also be dark. Private routers make only outbound connections, so no inbound firewall rules are needed in your private network.

With OpenZiti SDKs, traffic is encrypted from the sending application to the receiving application using libsodium for the data path and mTLS for identity authentication. Even if routers or intermediate networks are compromised, traffic cannot be decrypted or tampered with.

With tunnelers, encryption covers the path from tunneler to tunneler (or tunneler to SDK), providing machine-to-machine encryption without application changes.

Embed zero-trust networking directly in your applications:

All SDKs are listed under the OpenZiti GitHub organization.

OpenZiti has an active and growing community:

• Discourse Forum: Ask questions, share projects, get help from the community and maintainers
• YouTube: Tutorials, demos, and deep dives
• Blog: Project updates and technical articles
• Twitter/X: News and announcements

The OpenZiti project welcomes contributions including code, documentation, bug reports, and feedback.

See the local development tutorial for build instructions.

• Developer Overview
• Local Development
• Local Deployment
• Controller PKI
• Release Notes

See who's using OpenZiti: ADOPTERS.md

Using OpenZiti in your project or organization? We'd love to add you. Open an issue or submit a PR.

For zero-trust networking without managing your own infrastructure, NetFoundry provides a fully managed, globally distributed OpenZiti network as a service, with SLAs, enterprise support, and a global fabric of edge routers.

OpenZiti is developed and open-sourced by NetFoundry, Inc.