How zrok's Private Sharing and Zero-Trust Tunneling Work

Updated

zrok's private sharing keeps a resource off the public internet entirely: the sharer and the person accessing it both connect through zrok clients, and traffic moves between them over the OpenZiti zero-trust overlay network rather than through a public endpoint. Public sharing is the opposite mode — the resource is reachable through a public endpoint. Both modes run on the same OpenZiti foundation, which is where the "zero trust" part comes from.

Private vs. public sharing

The distinction is about who can reach the resource and over what path, not about how the tunnel is set up.

Private sharing Public sharing
Exposure Not exposed to any public endpoints Reachable via a public endpoint
Who can connect Other zrok users Anyone who can reach the public endpoint
Traffic path Between zrok clients, over the OpenZiti overlay Through the public endpoint
Typical use Internal apps, files, repos you want to keep closed Demos, webhooks, content you intend to publish

The site is explicit that in private scenarios "your private resources are not exposed to any public endpoints, and all communication is securely and privately transported between zrok clients." That is the core promise: the resource never gets a public address.

Where zero trust comes from

zrok is built on OpenZiti, NetFoundry's open-source zero-trust networking platform. The overlay network handles identity and secure transport, so zrok doesn't have to invent its own security layer — it inherits the overlay's model. Practically, this means access is tied to identities on the network rather than to network location or an open port. The site describes the tunneling as "secured effortlessly by using a Zero Trust overlay network provided by OpenZiti."

One consequence worth knowing: the security properties are a property of the overlay, so self-hosted deployments need a Ziti network underneath. The site says the single zrok binary contains what you need to operate zrok environments, and you "just add a Ziti network."

Beyond HTTP proxies

Traditional tunneling tools mostly proxy HTTP endpoints. zrok is positioned as broader: it also shares files and web content, and the site describes a framework for peer-to-peer resource sharing that can be extended to other kinds of decentralized resources — files, repositories, video among the examples given. If your need is strictly "expose a local web server," a conventional HTTP tunnel may be simpler; if you want private, identity-based sharing of non-HTTP resources, that is where zrok's model differs.

Getting to a share in three steps

The site's own quickstart is three commands:

  1. Invite — download the binary for your platform, then run zrok2 invite to create an account with the service.
  2. Enable — run zrok2 enable to enable your shell environment for sharing.
  3. Share — run zrok2 share to share resources.

Expected result: after enable, your shell is configured for the service, and share creates the share. Note that invite creates an account with the service — for the hosted instance that means NetFoundry's public service; self-hosted setups follow a different path built around your own Ziti network.

Choosing between hosted and self-hosted

zrok.io is a public service instance operated by NetFoundry using the same code base available for self-hosting. The site says it scales up to very large service instances and down to very small ones — a Raspberry Pi running OpenZiti with zrok on top is given as an example. So the choice is roughly: use the hosted instance to start quickly, or self-host if you need to control the network and the service instance yourself. Pricing and account terms are on the site's pricing page; check there before assuming what the hosted tier includes.