zrok
Expose local services securely
TLDR
Request an invitation to use the public zrok service (run this first)
Enable the zrok environment with the token from an invitation email
Create a publicly accessible URL for a local web server
Create a secure share accessible only with a unique token
Access a private share created by another user
Serve the contents of a local directory as a simple website
Display the status of the zrok environment and active shares
SYNOPSIS
zrok [global-options] command [command-options] [arguments]
PARAMETERS
--zrok-url
Specifies the URL of the zrok controller. Defaults to 'https://api.zrok.io'.
--api-key
Provides the API key for authentication with the zrok controller.
--verbose
Enables verbose logging output for detailed operation insights.
--output
Sets the output format (e.g., 'json') for command results.
--insecure
Allows insecure SSL connections when connecting to the zrok controller (use with caution).
(Subcommand-specific options)
Many zrok commands (e.g., 'share', 'access', 'reserve') have their own specific options. For example, the 'share' command includes options like '--unique-name', '--backend-mode', and '--auth-scheme' to configure the sharing behavior.
DESCRIPTION
zrok is an open-source command-line tool that enables secure, private, and programmable sharing of local services and resources, leveraging the underlying OpenZiti zero-trust network platform. It allows users to expose local web servers, SSH, databases, or any TCP service to the internet without requiring firewall modifications, port forwarding, or VPNs.
The tool supports various sharing modes, including public, private (password-protected), and reserved shares for persistent endpoints. It emphasizes security by establishing an outbound-only connection to the zrok service, making the exposed service invisible on the public internet until accessed via the designated zrok URL. This zero-trust approach ensures that only authorized users or services can access the shared resource, significantly enhancing security for development, demonstrations, or internal tool exposure.
CAVEATS
zrok requires an active zrok controller and frontend service, either hosted by OpenZiti (zrok.io) or self-hosted. Network performance and reliability depend on the underlying OpenZiti network and the specific zrok service infrastructure. Security of shared services relies heavily on proper configuration, especially for public shares using authentication schemes. Users should be mindful of exposing sensitive services and properly configure access controls.
CORE CONCEPTS: SHARING MODES
zrok offers several modes for sharing:
Public Shares: Accessible via a unique URL. Can be protected with basic authentication.
Private Shares: Require a zrok 'access' command to establish a secure client-side connection.
Reserved Shares: Provide a persistent, unchanging zrok URL, ideal for services that need a stable endpoint.
Backend Proxy Shares: Used for internal service mesh integration, providing a programmatic way for services to access other services securely.
OPENZITI INTEGRATION
At its core, zrok leverages the OpenZiti overlay network. When you share a service with zrok, it initiates an outbound-only connection to the zrok infrastructure, which is built on OpenZiti. This creates a secure, dark network path for your service, making it inaccessible from the public internet unless explicitly routed through the zrok and OpenZiti fabric, enforcing zero-trust principles.
HISTORY
zrok was developed by OpenZiti (a project by NetFoundry) and first introduced in late 2022 / early 2023. It was designed to provide a secure and flexible way to share services, building upon the foundational zero-trust networking principles of the OpenZiti platform. Its development aimed to offer a more secure and programmable alternative to traditional port-forwarding or basic tunnel services.


