OpenZiti

Open-source zero-trust networking, honestly reviewed. Not a VPN replacement you’ll set up in 20 minutes — but something more powerful if you’re willing to invest.

TL;DR

• What it is: Open-source (Apache 2.0) zero-trust overlay network — services get cryptographic identities, stop listening on public ports, and become invisible to unauthorized users [README][1].
• Who it’s for: Security-focused founders, devops teams, and engineers building IoT, B2B SaaS platforms, or multi-cloud infrastructure where VPN-style “once you’re in, you see everything” is the wrong model [1].
• Cost: Software is free and Apache-licensed. Commercial managed cloud and enterprise support available via NetFoundry — pricing not publicly listed, requires contacting sales [2].
• Key strength: “Dark services” model — zero listening ports, invisible to port scanners and unauthorized users. Services can’t be breached if they can’t be found [README][1].
• Key weakness: This is not a beginner tool. Setup requires understanding zero-trust concepts, PKI basics, and network architecture. Compared to Tailscale or Cloudflare Tunnel, the learning curve is steep.

---

What is OpenZiti

OpenZiti is an open-source zero-trust overlay network platform. The core idea: instead of controlling access by IP address, subnet, or firewall rule, every user, service, device, and workload gets a cryptographic identity. Connections happen between identities through an encrypted overlay, not through the underlying network. Services don’t need to expose ports to the public internet at all [README].

The project’s own tagline — “Cloak Your Network. Secure Services not IPs” — describes this reasonably accurately. Where traditional networking says “devices on subnet 10.0.1.0/24 can reach this service on port 443,” OpenZiti says “this identity can reach this service, and nothing else can even see it exists” [website].

NetFoundry created and sponsors the project, offers a managed cloud version of it, and provides commercial support under the same brand [README][2]. The open-source code sits on GitHub under Apache 2.0 with 3,924 stars. That’s a modest star count compared to tools in adjacent categories — Tailscale’s open-source components or WireGuard have broader community recognition — but the project has genuine enterprise adopters including US military contractors, edge device companies, and B2B SaaS platforms [2].

OpenZiti supports three implementation models depending on how deep you want to go [website]:

• ZTAA (Zero Trust Application Access): SDKs embedded directly into your application code. The app holds its own cryptographic identity. Strongest security posture, requires code changes.
• ZTHA (Zero Trust Host Access): Tunnelers installed at the host level. Existing applications get zero-trust access with no code changes. Most common production path.
• ZTNA (Zero Trust Network Access): Router in trusted network space. For devices that can’t run a tunneler.

SDKs exist for Go, C, JVM-based languages, Swift, NodeJS, and C# [4].

---

Why people choose it

The Startupik analysis [1] frames OpenZiti’s appeal clearly: this isn’t a generic “better VPN” pitch. The decision to use OpenZiti is fundamentally architectural — you’re choosing identity-based access over network-level access.

The VPN replacement argument. Traditional VPNs grant network access. Once a user connects to a VPN, they often have reach into broad swaths of infrastructure. OpenZiti’s model is narrower: a given identity can reach exactly the services its policy allows, and nothing else. For companies with contractors, external partners, or remote developer access, this least-privilege model prevents the common VPN failure where a compromised credential exposes the whole internal network [1]. As the Startupik review puts it: “Give a person or workload access to one app, one port, one service class.”

The dark services argument. If a service has zero listening ports, it can’t be port-scanned, it can’t be exploited through unauthenticated protocol bugs, and it can’t be found by automated attack tooling. This is the “dark API” use case [README][1]. For a self-hosted founder running an internal admin panel or a staging environment, replacing “hide behind nginx auth” with “the port doesn’t exist for unauthorized clients” is a meaningfully better security posture.

The IoT and non-human identity argument. OpenZiti’s identity model was explicitly designed to work for machines, sensors, and devices — not just humans logging in. Every device gets a unique cryptographic certificate. If a device is compromised, you revoke that identity. This is a stronger model than shared secrets or IP-based allowlists for embedded systems [README][1].

The multi-cloud argument. Organizations running services across AWS, Azure, on-prem, and edge locations face complex peering, VPN tunnels between environments, and cloud-vendor-specific networking tools. OpenZiti’s overlay spans all of it through one consistent identity model [README]. The FerretDB blog [5] demonstrates a concrete version of this: an entire database stack (PostgreSQL + FerretDB) running inside an OpenZiti network with zero exposed ports, accessible only to enrolled identities.

Where the argument weakens. The Startupik review is explicit about this: “Do not use OpenZiti first if your team only needs simple office VPN access and lacks time for network architecture changes.” If your mental model is “I want my laptop to connect to my home server without port forwarding,” something like Tailscale or Cloudflare Tunnel will have you running in 15 minutes. OpenZiti will have you learning about controllers, edge routers, enrollment tokens, and policies before you’re done. The tool rewards the investment — but the investment is real [1].

---

Features

From the README and website documentation:

Core network fabric:

• Zero-port service model — services have no listening ports on the public internet [README]
• Cryptographic identity for every endpoint: users, services, devices, workloads [README]
• End-to-end encryption using libsodium [website]
• Policy-based authorization: fine-grained, identity-aware [website]
• Smart routing through OpenZiti Fabric — traffic takes the optimal path [website]
• Private DNS — authenticated service name resolution, not public DNS [website]
• No port inference / single-port transport to prevent service fingerprinting [website]

Deployment integration:

• Docker and Docker Compose support [README]
• Kubernetes native — connect services across clusters without complex ingress [README]
• Helm charts available [website]
• REST API for programmatic management [merged profile]

SDK and tunneler options:

• Language SDKs: Go, C, JVM, Swift, NodeJS, C# — embed zero-trust directly into applications [README][4]
• Tunnelers for existing apps with no code changes [README]
• Ziti Console — web UI for managing the network [5]

Notable use cases supported out of the box:

• VPN replacement with least-privilege access [1]
• Dark APIs (internal services with zero public exposure) [README]
• IoT and non-human identity management [README]
• Agentic AI secure connectivity — MCP servers and tool endpoints can be made dark, with no public URLs [README]
• Kubernetes cross-cluster service access [README]
• Home lab access without open router ports [README]

Enterprise features (via NetFoundry commercial platform):

• Full mesh, HA, load balancing and auto-scaling across 100+ PoPs [2]
• FIPS-compliant encryption option [2]
• On-premises and air-gapped deployment [2]
• Identity provider integration (OAuth, OIDC) [2]
• SOC 2 Type II compliance — NetFoundry’s managed cloud [3]
• Session-level telemetry and SIEM integration [2]

---

Pricing: SaaS vs self-hosted math

This is where the review hits a hard wall: NetFoundry does not publish pricing for its commercial tiers. The website offers three paths — Managed SaaS, Self-Hosted with NetFoundry support, and Community Self-Hosted — but lists no numbers for the first two. A “Free 30 Day Trial” button leads to a contact form [2]. Enterprise networking infrastructure pricing is almost never posted publicly, and OpenZiti’s commercial layer is no exception.

What you actually know:

Community Self-Hosted (what this review covers):

• Software: $0 (Apache 2.0)
• Infrastructure: whatever a VPS costs you. OpenZiti’s control plane (the Ziti Controller) is lightweight — a $5–10/mo VPS runs it fine for small deployments. Edge routers add cost if you need geographic distribution.
• Support: community forum (Discourse) and GitHub issues
• Compliance: none included — you own the infrastructure and the responsibility

NetFoundry Managed SaaS:

• Contact sales
• Targets enterprises, regulated environments, teams needing SLAs and 24×7 support [2]

Self-hosted with NetFoundry support:

• Contact sales
• For regulated environments where you need infrastructure control plus commercial backing [2]

If you’re a non-technical founder evaluating cost-saving potential against a commercial zero-trust product — think Cloudflare Access ($7/user/month on their Zero Trust plan) or Twingate (starts around $5/user/month) — the self-hosted OpenZiti math is favorable in pure licensing cost. But the honest answer is: this only saves you money if you have the engineering capacity to deploy and operate it. If you don’t, you’re trading a SaaS bill for an engineering bill that’s harder to see.

---

Deployment reality check

The FerretDB blog [5] shows the Docker Compose path, which is probably the most accessible entry point. A minimal OpenZiti deployment needs:

• Ziti Controller: manages identities, policies, and the network fabric. This is the brain.
• Ziti Edge Router(s): handle encrypted traffic between identities and services. You need at least one, more for redundancy or geographic distribution.
• Ziti Console: optional web UI for managing the network.
• Enrolled identities: every client and service needs a certificate issued by the controller.

The rough sequence: stand up the controller, stand up at least one edge router, create service definitions, create identity objects, issue enrollment tokens to clients, configure policies that say which identities can reach which services.

This is not a “docker pull, visit localhost:8080, click through wizard” experience. The OpenZiti quickstart documentation walks through the process, but you’re interacting with a CLI (ziti edge list edge-routers, zitiLogin, enrollment commands) before anything works [5].

Realistic time estimates:

• Engineer who has deployed self-hosted tools before, following docs carefully: 2–4 hours to a working proof of concept.
• Non-technical founder without Linux/Docker background: this is genuinely not the right starting point. The Startupik review is direct about it: “It becomes less attractive when legacy apps require full LAN-style discovery, broadcast traffic, or deep network-layer assumptions” and when the team lacks time for architecture changes [1].

What can go wrong:

• Certificate enrollment is the most common friction point. Tokens expire. Mismatched identities won’t connect and the error messages aren’t always helpful.
• Edge router placement matters for performance. One router with all traffic through it creates a bottleneck.
• The split between open-source community support and commercial NetFoundry support isn’t fully documented. Some issues land in GitHub limbo.

---

Pros and cons

Pros

• Apache 2.0 license. No “Fair-code” restrictions, no commercial use limitations. You can embed OpenZiti in a product you sell [README].
• Genuinely dark services. Zero listening ports is a fundamentally stronger posture than firewall rules. You can’t probe what you can’t reach [README][1].
• Identity works for everything. Non-human identity is first-class — IoT devices, workloads, and AI agents get the same cryptographic identity model as humans [README][1].
• SDK depth. Six language SDKs means you can embed zero-trust directly into applications, not just wrap them with a tunneler [README][4].
• Works across any infrastructure. Cloud, on-prem, edge, Kubernetes, bare metal, mixed environments — the overlay doesn’t care [README][1].
• NetFoundry backing. Commercial sponsorship means the project has real funding, real customers, and an enterprise support path if you need it [README][2].
• Active development. The README reflects ongoing investment in new use cases including agentic AI connectivity [README].

Cons

• Steep learning curve. Zero-trust networking is a discipline, not a product category with a single install path. Expect to spend real time understanding the model before you can deploy confidently [1].
• No published pricing for commercial tiers. If you outgrow community self-hosting, you’re entering a sales process with no floor or ceiling visible from the outside [2].
• 3,924 GitHub stars is modest. Tailscale, WireGuard, and Cloudflare’s tools all have larger communities and more third-party documentation. OpenZiti’s community is smaller, which means fewer Stack Overflow answers when you’re stuck.
• Web console is functional, not polished. The Ziti Console exists [5], but the primary management interface is the CLI. Non-technical team members won’t be managing identities through a friendly UI.
• Commercial features are opaque. The NetFoundry platform adds HA, FIPS encryption, air-gapped deployment, and enterprise IdP integration — but the line between what the open-source project provides and what NetFoundry commercializes isn’t clearly drawn in the public documentation [2].
• Not for simple home-lab access. If you want to reach your Nextcloud from outside without opening a port, Tailscale or Cloudflare Tunnel solve that in under 30 minutes. OpenZiti solves a harder problem at significantly more setup cost [1].

---

Who should use this / who shouldn’t

Use OpenZiti if:

• You’re building a B2B SaaS platform and need to give customers secure access to your control plane without exposing it publicly.
• You’re managing IoT or edge devices and need per-device cryptographic identity and revocation.
• You have engineering capacity to deploy and maintain infrastructure, and you want an Apache-licensed zero-trust layer you can embed in your own product.
• You’re running multi-cloud infrastructure and want one consistent identity-based access layer across environments.
• Your security requirements include “services not reachable from the internet” — and you mean it, not just “services behind a firewall.”

Skip it and use Tailscale or Headscale if:

• You want secure access to self-hosted services from outside your network and you need to be running in under an hour.
• Your team is non-technical and won’t maintain PKI or enrollment tokens.
• You need a mesh VPN, not an application-layer overlay.

Skip it and use Cloudflare Tunnel if:

• You want to expose a specific service publicly without opening a port, and you’re comfortable with Cloudflare as the trust anchor.

Skip it and use Teleport or HashiCorp Boundary if:

• Your use case is primarily SSH, Kubernetes, and database access for developer teams, and you want an audit trail and session recording as first-class features.

---

Alternatives worth considering

• Tailscale — WireGuard-based mesh network, vastly easier to set up, commercial SaaS with a generous free tier. Not open-source at the control plane. Right for most small-team remote access cases.
• Headscale — Open-source Tailscale control server. Self-hostable, community-maintained. Same WireGuard simplicity, less enterprise feature set than OpenZiti.
• Cloudflare Tunnel (WARP/Access) — Exposes services through Cloudflare’s network without open ports. No self-hosting the control plane. Cloudflare becomes the trust anchor.
• Teleport — Access management for SSH, Kubernetes, databases. Better fit for developer access control than application-to-application zero trust.
• HashiCorp Boundary — Open-source, identity-based access proxy. More focused on human access to infrastructure resources. Similar philosophy, different feature set.
• WireGuard — The underlying protocol many of these tools build on. Extremely fast, minimal attack surface, but you build your own access policies and identity management on top.

For a non-technical founder doing a quick cost comparison, the realistic shortlist is Tailscale vs OpenZiti. Tailscale if you want something running today. OpenZiti if you need application-layer identity, dark services, or the ability to embed zero-trust into your own product.

---

Bottom line

OpenZiti solves a real and increasingly important problem: as infrastructure spreads across clouds, edge devices, and contractor laptops, IP-based network security stops working. The “dark services” model — services with zero listening ports, invisible to unauthorized clients — is meaningfully stronger than firewall rules, and the identity-for-everything model scales to IoT and AI agents in ways that traditional VPN can’t. The Apache 2.0 license means you can build on it commercially.

The honest caveat: this is an infrastructure project built by and for people who think in terms of PKI, overlay networks, and zero-trust policy. If you’re a non-technical founder looking to escape a SaaS bill, OpenZiti is not your first stop. If you’re an engineering team building a product where secure, identity-bound connectivity is a core requirement — B2B SaaS, IoT, multi-cloud workloads, agentic AI infrastructure — OpenZiti is worth the investment.

If the infrastructure complexity is the blocker, that’s exactly what upready.dev helps clients navigate. One engagement to architect and deploy it, then you own the stack.

---

Sources

1. Startupik — “When Should You Use OpenZiti?” https://startupik.com/when-should-you-use-openziti/
2. NetFoundry — “NetFoundry Cloud for OpenZiti | Fully Managed Zero Trust” https://netfoundry.io/products/netfoundry-platform/netfoundry-cloud-for-openziti/
3. NetFoundry — “NetFoundry SOC 2 Compliance Report” https://netfoundry.io/netfoundry-soc-2-compliance-report/
4. facts.dev — “ZOT OCI Registry project details” (references OpenZiti SDK ecosystem) https://www.facts.dev/p/zot-oci-registry/
5. FerretDB Blog — “Run FerretDB Securely Using OpenZiti” https://blog.ferretdb.io/run-ferretdb-securely-using-openziti/

Primary sources:

• GitHub repository and README: https://github.com/openziti/ziti (3,924 stars, Apache 2.0 license)
• Official website and documentation: https://openziti.io/
• NetFoundry platform page: https://netfoundry.io/products/netfoundry-platform/netfoundry-cloud-for-openziti/