Should You Use the zrok.io SaaS Service or Self-Host zrok?

Updated

Use the hosted zrok.io service if you want to start sharing in minutes and don't want to run network infrastructure. Self-host zrok if you need full control over the service instance, your data path, or your own OpenZiti network. Both run the same code base, so the sharing commands and behavior are the same — the difference is who operates the service and how much setup you take on.

The Core Difference

zrok is an open-source, zero-trust peer-to-peer tunneling and ingress tool built on OpenZiti. It is available two ways:

  • SaaS: zrok.io is a public service instance operated by NetFoundry.
  • Self-hosted: you run your own zrok environment on top of your own OpenZiti network.

Because NetFoundry operates the public instance with the same code that is released for self-hosting, you are not choosing between two different products. You are choosing who runs the service.

Side-by-Side Comparison

Dimension zrok.io (SaaS) Self-hosted zrok
Who operates it NetFoundry You
Setup effort Minutes: download the binary, then zrok2 invite, zrok2 enable, zrok2 share Stand up an OpenZiti network, then layer zrok on top
Code base Same as self-hosted Same as the public instance
Scale Public instance designed for very large service instances Scales down to very small deployments, e.g. a Raspberry Pi
Control over the service instance NetFoundry's Yours
Components you manage Your client only The zrok binary plus the Ziti network

When the SaaS Service Fits

Choose zrok.io when your priority is getting a secure tunnel working quickly and you are comfortable with NetFoundry operating the service instance. The documented path is three steps:

  1. Download the binary for your platform.
  2. Run zrok2 invite to create an account with the service.
  3. Run zrok2 enable to enable your shell environment, then zrok2 share to share a resource.

This is the lowest-effort route and matches the "sharing in minutes" flow described on the site. It suits individual developers, quick demos, and teams that don't want to own network operations.

When Self-Hosting Fits

Choose self-hosting when you need to operate the service instance yourself — for example, to keep the environment inside your own infrastructure or to run a very small deployment. The site notes that the single zrok binary contains everything needed to operate zrok environments and host your own service instances; you add a Ziti network and you're running.

The trade-off is real: self-hosting means you take on the OpenZiti network as a prerequisite, plus ongoing operation of the instance. In exchange you get control that the public instance does not give you.

What Stays the Same Either Way

Several capabilities are properties of zrok itself, not of the hosting choice:

  • Private sharing: resources are not exposed to public endpoints, and traffic moves between zrok clients over the zero-trust overlay.
  • Beyond HTTP: zrok can share files and web content, not just proxy HTTP endpoints, and is built to extend to other kinds of decentralized resource sharing.
  • Public or private ingress: zrok provides private or public, instant, secure tunneling of applications.

A Practical Way to Decide

Start with the SaaS instance to confirm zrok does what you need with your workloads. Move to self-hosting when a concrete requirement appears — you must operate the instance yourself, or you want a deliberately small deployment on hardware like a Raspberry Pi. Since the code base is the same, that migration is a change in operations, not a rewrite of how you share.

Check the pricing page before committing to the hosted route, and review the docs for the current invite and enable flow on your platform.