ngrok vs. zrok: The Zero-Trust, Peer-to-Peer Alternative for Modern Ingress Tunneling

For close to a decade, when a developer needed to instantly expose a local application or an internal webhook to the public internet, they typed a single command into their terminal: ngrok http 8080.

For years, that was enough. But the modern DevOps and security landscape has shifted. With growing emphasis on data sovereignty, compliance, and enterprise perimeter defense, routing sensitive internal APIs, local datasets, or microservices through a third-party centralized cloud proxy is now a real compliance concern for regulated teams. Add to that ngrok’s February 2026 pricing and quota changes — which meaningfully tightened the free tier — and it’s no surprise developers are looking harder at alternatives.

Enter zrok. Built on top of the open-source OpenZiti framework by NetFoundry, zrok is a peer-to-peer (P2P) sharing and zero-trust tunneling platform. It fully supports the traditional “public URL” workflow, but it also flips the ingress paradigm by offering private, peer-to-peer tunnels that never touch the public internet.

This guide breaks down the architectural, financial, and philosophical differences between ngrok and zrok — and updates a few claims that no longer hold in 2026.

The Core Architectural Divergence

Traditional Cloud Proxying (ngrok)

Traditional tunneling relies on a centralized client-server relay model. When you start a session, a persistent outbound connection is made to a public relay node. The vendor provides a public-facing domain, and any inbound traffic sent to that URL hits the vendor’s cloud servers, gets inspected and routed there, and is then channeled down to your machine.

This architecture has three well-known tradeoffs:

• Data sovereignty: your payload — an auth request, a raw DB query, proprietary customer data — passes through a third-party relay.
• Central point of failure: if the vendor’s cloud region has an outage, your external endpoints go down regardless of your own machine’s uptime.
• Latency penalties: traffic takes a multi-hop round trip to a centralized gateway and back.

Zero-Trust, Overlay Mesh Networking (zrok)

zrok is a “ziti-native” application — it provisions an identity-based overlay network using OpenZiti rather than a simple relay tunnel. Every service, endpoint, and device needs a verified, cryptographically signed identity before a connection can be requested. By default, zrok eliminates inbound ports on your local machine, using outbound-only connections to stitch nodes together.

Public Sharing vs. Private Peer-to-Peer Tunnels

The Public Paradigm (Both Tools)

Both tools let you spin up a public URL to share your localhost with the internet. Running zrok share public http://localhost:8080 provisions a public URL through zrok’s frontdoor proxy, with automatic TLS and defenses against oversized payloads and SQL injection against the shared app.

One correction worth making here: zrok is not immune to the friction ngrok is often criticized for. Unverified free zrok accounts also see an anti-phishing interstitial page on first visit to a public share — the same mechanism ngrok uses. Verifying your zrok account with a credit card (no charge) removes it, just as upgrading an ngrok plan does.

The Private Peer-to-Peer Paradigm (zrok Exclusive)

For sensitive corporate microservices, internal staging databases, or classified AI training data, exposing even an authenticated public URL is often an unacceptable risk. This is where zrok’s private sharing changes the equation — it creates an encrypted tunnel that never touches or registers on the public internet.

+-----------------------+                    +-----------------------+
|  Host (Your Machine)  |                    | Guest (Your Peer)     |
|                       |                    |                       |
|  [Local App: 8080]    |                    |  [Local Proxy: 9090]  |
|          ^            |                    |          ^            |
|          |            |                    |          |            |
|   (zrok share private)|                    |   (zrok access private|
+----------+------------+                    +----------+------------+
           |                                            |
           v                                            v
     [OpenZiti Identity] <====================> [OpenZiti Identity]
                         End-to-End Encrypted Tunnel

The workflow:

1. Host the private resource — the host runs zrok share private http://localhost:8080. Instead of a public URL, zrok returns a unique, ephemeral access token.
2. Send the token out-of-band — over an encrypted chat or internal secrets manager, never over the public share channel itself.
3. Bind the client — the recipient runs zrok access private <token>.
4. Access via local loopback — zrok spins up a local proxy on the recipient’s machine, e.g. http://localhost:9090.

Because no public DNS record or public edge routing node is ever created, the data stream stays dark to scanners and automated bots.

Detailed Feature-by-Feature Comparison

Feature Dimension	ngrok	zrok
License model	Proprietary / commercial, closed-source	Open-source (Apache 2.0), same for the underlying OpenZiti fabric
Core architecture	Centralized HTTP/TCP cloud proxy relay	Distributed, identity-based zero-trust overlay
Self-hosting	Not possible — locked to ngrok’s cloud	Fully supported — Docker, Linux binary, “Raspberry Pi to enterprise scale” per the project’s own description
Private sharing	Not available — all endpoints are inherently public	Native P2P private sharing, no public endpoint ever created
Persistent free URL	Yes, since 2023 — every free account gets one static “dev domain” that survives restarts	Yes, via reserved/named shares
Free-tier caps	1 GB/month data transfer, 3 online endpoints, 20,000 requests/month, 5,000 TCP connections/month	5 GB/day data transfer, 25 environments, 50 share backends, 50 private access frontends
First-visit interstitial (unverified free account)	Yes	Yes
Extra utilities	Webhook inspection, request replay, OAuth	Built-in file/drive sharing, HTTP/TCP/UDP tunnels, WebDAV network drives

Pricing, Bandwidth, and a Correction on ngrok’s Free Tier

The original draft repeated some older folklore about ngrok’s free tier — that tunnels “frequently time out” and that URLs “rotate on every initialization.” Neither is accurate anymore, and it’s worth being precise about what actually changed and when.

What’s no longer true: ngrok’s own documentation is explicit that the free tier “does NOT have timeouts on endpoints” — you can run a free endpoint as a background service indefinitely. And since ngrok rolled out free static “dev domains” (a change originally introduced in 2023 and reinforced when pricing was restructured in 2026), every free account gets one persistent subdomain like your-name.ngrok-free.dev that does not change when the agent restarts. The classic pain point of webhook URLs breaking every time you restart ngrok is gone for the default free workflow.

What is true, and is the actual 2026 pain point: ngrok tightened free-tier quotas considerably in February 2026. The current free plan caps you at 1 GB of data transfer per month, 20,000 HTTP requests per month, 5,000 TCP connections per month, and just 3 concurrent online endpoints — with no wildcard or custom domains, and no TLS endpoints at all on free. For a solo developer doing occasional webhook testing this is plenty; for anything with real traffic, teams are pushed toward the Hobbyist ($8–10/month) or Pay-as-you-go ($20/month plus usage) tiers fairly quickly.

The Open-Source Freedom of zrok

Because zrok (and the OpenZiti fabric underneath it) is Apache 2.0 licensed, developers keep full control over their ingress path. NetFoundry’s managed free tier at zrok.io currently includes:

• 5 GB of daily data transfer
• Up to 25 environments (a user or service enabled on a device)
• 50 share backends (ephemeral or reserved)
• 50 private access frontends
• The first-visit interstitial removed once you verify your account with a credit card (no charge)

For regulated environments — HIPAA, GDPR, SOC 2 Type II — zrok’s single self-contained binary means you can run the entire control plane on your own VPS or private cloud infrastructure, retaining ownership of transmission paths, metrics, and identity stores.

zrok v2.0: What Changed in March 2026

zrok shipped a major v2.0 release in March 2026, and it’s worth flagging since a lot of existing tutorials (including parts of the original draft this article is based on) still reference v1 command syntax:

• The binary is now zrok2, not zrok. The two can run side-by-side on the same machine — v2 uses its own environment directory (~/.zrok2), its own env var prefix (ZROK2_*), and its own systemd units, so upgrading doesn’t disturb an existing v1 setup.
• Reserved sharing was replaced by a namespace/names model. The old zrok reserve / zrok release / zrok share reserved commands are gone; zrok2 create share and zrok2 delete share now pre-allocate and manage both public and private shares, and zrok2 modify name -r can promote an ephemeral share to a persistent one on the fly instead of requiring a teardown and recreate.
• VPN backend mode has been removed. The host-to-host VPN capability referenced in older zrok documentation and in the original draft was pulled in v2 because the underlying TUN device libraries created dependency conflicts that blocked updates elsewhere in the stack. If your workflow depended on zrok share private --backend-mode vpn, that path is gone for now — the project’s VPN removal guide covers migration alternatives.

New in 2026: Zero-Trust Plumbing for AI Agent Infrastructure

This is worth calling out specifically for teams already thinking about MCP traffic and agent-facing infrastructure, since it’s a natural extension of the ingress-tunneling conversation:

• openziti/mcp-gateway aggregates multiple MCP backends — local stdio servers and remote zrok shares — into a single, namespaced connection for an AI client, with per-tool allow/deny filtering and per-client session isolation (no shared state between clients hitting the same gateway).
• ziti-mcp-server wraps the entire Ziti Management API — 209 tools covering identities, services, edge routers, policies, and fabric operations — as an MCP server, so an agent in Claude Desktop, Cursor, or similar clients can manage an OpenZiti network conversationally instead of through the console or raw REST calls.
• openziti/llm-gateway is an OpenAI-compatible proxy that does semantic routing across OpenAI, Anthropic, Azure OpenAI, AWS Bedrock, Google Vertex AI, and Ollama, with the routing and inference traffic itself carried over the zero-trust overlay rather than the open internet.

All three are open-source and NetFoundry-sponsored, and they lean on the same private-sharing primitives described above — an MCP tool endpoint can be shared exactly the way a private HTTP backend is, with no listening port and no public URL, which is the same “dark by default” argument this article makes for tunneling in general.

The Verdict: When to Use Which?

Choose ngrok if: - You’re building a quick, non-sensitive hobby project and want an established, well-documented platform. - Your workflow is already tied into ngrok’s dashboard, traffic inspection, or request-replay features. - Your usage comfortably fits inside 1 GB/month and 20,000 requests/month, or you’re fine paying for Hobbyist/Pay-as-you-go once it doesn’t.

Choose zrok if: - Security and privacy are paramount — you need to share internal APIs or metrics without ever exposing a public endpoint. - You need data sovereignty — an open-source tool your team can fully self-host inside a private VPC. - You want a genuinely generous free tier — 5 GB/day and no forced timeouts. - You want built-in file/drive sharing or are experimenting with zero-trust MCP/agent infrastructure alongside your tunneling needs.

By shifting from centralized cloud proxies to identity-verified, zero-trust tunnels, zrok gives engineering teams a self-hostable, compliance-friendly approach to ingress connectivity — with the caveat that, like any actively developed open-source project, its command surface and feature set (see: the VPN removal in v2.0) can and does shift under you.

---

Changelog

Corrected: - Removed the claim that ngrok free-tier tunnels “frequently time out” — ngrok’s own docs confirm the free plan has no endpoint timeouts. - Removed the claim that ngrok free URLs “rotate on every initialization” — every ngrok account (free included) has gotten a persistent static “dev domain” since 2023; this was outdated folklore, not a current pain point. - Replaced vague free-tier language with ngrok’s actual published limits (1 GB/month transfer, 3 endpoints, 20,000 requests/month, 5,000 TCP connections/month), sourced from ngrok’s pricing-limits documentation. - Flagged that zrok also shows a first-visit interstitial page on unverified free accounts — the original draft implied this was an ngrok-only friction point. - Noted that zrok’s VPN backend mode, mentioned in the original draft’s utility list, was removed in the March 2026 v2.0 release due to dependency conflicts.

Added: - A “zrok v2.0” section covering the zrok2 binary rename, the namespace/names model replacing reserved sharing, and the VPN removal — since several tutorials still reference v1 syntax. - A new section on 2026 zero-trust infrastructure for AI agents: openziti/mcp-gateway, ziti-mcp-server (209 Ziti Management API tools exposed via MCP), and openziti/llm-gateway. - Confirmed and retained the free-tier numbers for zrok (5 GB/day, 25 environments, 50 share backends, 50 private access frontends) directly against zrok’s current pricing page — these were accurate in the original draft.

Removed: - Marketing-toned framing (“ultimate,” “Enter zrok”) was toned down where it overstated certainty. - Stray formatting artifacts from the source draft (run-together headings/bullets from the original scrape).

Sources checked: ngrok pricing-limits documentation (ngrok.com/docs), ngrok free static domains blog post, zrok pricing page (zrok.io/pricing), OpenZiti Tech Blog (“Introducing zrok v2.0,” “zrok VPN”), zrok CHANGELOG and GitHub releases, openziti/mcp-gateway and ziti-mcp-server project pages, Better Stack Community zrok guide.