zrok is an open-source, Apache-2.0 licensed secure sharing tool written in Go that lets developers, operators, and self-hosters expose web services, folders, and TCP or UDP resources over the internet or to specific users without firewall changes or port forwarding.

What it is

zrok is a zero-trust sharing utility built on OpenZiti, a programmable zero-trust network overlay. It lives in the Go ecosystem and ships as a single binary containing everything needed to run a share or a complete zrok service instance. The client uses identity-based access rather than IP allowlists, establishes peer-to-peer connections where possible, and encrypts traffic end to end so that even the zrok servers do not see plaintext. Public sharing, private sharing, HTTP/HTTPS, TCP, UDP, and file sharing are all handled by the same tool, and the same codebase powers both the free hosted service at zrok.io and any self-hosted deployment.

The concrete problem it solves is inbound reachability. Local web apps, folders, and network services normally require a public IP address, a firewall rule, a port-forward, and a reverse proxy before anyone outside the local network can reach them — and each of those steps widens the attack surface. zrok replaces that port-forwarding and public-exposure workflow by making an outbound connection from the machine running the share, so no inbound connectivity is required at all. A folder becomes a shareable network drive, and a service on localhost becomes reachable without the host ever accepting an inbound connection.

Key capabilities

• Public web sharing with zrok share public localhost:8080, which exposes a local service over the internet without router or firewall configuration.
• File and directory sharing with zrok share public --backend-mode drive ~/Documents, which turns any folder into a network drive that can be mounted in a file manager.
• Private sharing with zrok share private localhost:3000, which limits access to other zrok users and avoids public internet exposure entirely.
• Multiple transport protocols: HTTP/HTTPS, TCP, UDP, and file sharing over a single interface.
• Zero-trust security model inherited from OpenZiti, including end-to-end encryption, identity-based access, and peer-to-peer connections where a direct path exists.
• Cross-platform clients for Windows, macOS, Linux, and Raspberry Pi.
• A Go SDK for embedding sharing into applications, using sdk.CreateShare, sdk.ShareRequest, sdk.TcpTunnelBackendMode, sdk.PrivateShareMode, and sdk.NewListener.

Who uses it and how

• Developers who need to demo a web app running on localhost to a client or teammate without deploying it or opening a port.
• Teams that need to hand a folder to a remote colleague as a mounted network drive instead of copying it through a third-party service.
• Operators sharing TCP or UDP services privately with named zrok users, keeping the service off the public internet.
• Self-hosters running their own zrok service instance, from a single Raspberry Pi up to enterprise scale, using the same codebase as the public zrok.io service.
• Application developers embedding sharing directly into their own products through the Go SDK rather than shelling out to the CLI.

Getting started

Install zrok for the target platform, obtain an account with zrok invite, then run zrok enable to activate sharing on that machine; the README describes this as a setup that takes under two minutes. The free hosted zrok.io service can be used for the account, or a self-hosted service instance can be deployed following the self-hosting guide.

How it compares

The facts provided name no paid products that zrok replaces, and the only other project referenced is OpenZiti, which is the zero-trust overlay zrok is built on rather than a competing tool. On the evidence available, zrok stands alone in this registry.

When to use it — and when not to

Self-hosting means operating a zrok service instance yourself, and while the single binary keeps that tractable, the README does not spell out what else a deployment depends on. Anyone who wants no operational responsibility at all should use the hosted zrok.io service instead. The project also carries 125 open issues at the time of writing, and the README offers no release history or versioning detail, so teams that need a documented support relationship and a formal release cadence should weigh that before standardising on it.

# Share a web service publicly
$ zrok share public localhost:8080

# Share files as a network drive  
$ zrok share public --backend-mode drive ~/Documents

# Share privately with other zrok users
$ zrok share private localhost:3000

zrok share public localhost:8080

zrok share public --backend-mode drive ~/Repos/zrok

// Create a share
shr, err := sdk.CreateShare(root, &sdk.ShareRequest{
    BackendMode: sdk.TcpTunnelBackendMode,
    ShareMode:   sdk.PrivateShareMode,
})

// Accept connections
listener, err := sdk.NewListener(shr.Token, root)