OpenZiti (a.k.a. "Ziti") provides secure network backhaul for `zrok` public and private shares. You need a Ziti Controller and a Ziti Router. You can run everything on the same Linux VPS.
1. Install the Ziti Router package by following [the Linux router deployment guide](https://openziti.io/docs/category/deployments).
1. Ensure your answer file (`/opt/openziti/etc/router/bootstrap.env`) has the FQDN of your Linux server for both controller and router addresses and the enrollment token from the previous step.
1. Ensure your firewall allows the router port from the answer file.
1. Start the router service (`ziti-router.service`) and check the status.
Follow [the Linux installation guide](/guides/install/linux.mdx) to install the `zrok` package from the repository or manually install the binary for your platform.
Create a `zrok` controller configuration file in `etc/ctrl.yml`. The controller can terminate TLS or you may front the server with a reverse proxy that continually renews the necessary wildcard certificate (e.g., Caddy w/ a DNS provider plugin). This example will expose the non-TLS listener for the controller.
The `admin` section defines privileged administrative credentials and must be set in the `ZROK_ADMIN_TOKEN` environment variable in shells where you want to run `zrok admin`.
The `ziti` section defines how the `zrok` controller should communicate with your OpenZiti installation. When using the OpenZiti quickstart, an administrative password will be generated; the `password` in the `ziti` stanza should reflect this password.
Be sure to see the [reference configuration at `etc/ctrl.yml`](../../../../etc/ctrl.yml) for the complete documentation of the current configuration file format for the `zrok` controller and service instance components.
See the separate guides on [configuring metrics](/guides/self-hosting/metrics-and-limits/configuring-metrics.md) and [configuring limits](/guides/self-hosting/metrics-and-limits/configuring-limits.md) for details about both of these specialized areas of service instance configuration.
The `zrok` binaries are configured to work with the global `zrok.io` service, and default to using `api.zrok.io` as the endpoint for communicating with the service.
To work with a self-hosted `zrok` deployment, you'll need to set the `ZROK_API_ENDPOINT` environment variable to point to the address where your `zrok` controller will be listening, according to `endpoint` in the configuration file above.
With your OpenZiti network running and your configuration saved to a local file (I refer to mine as `etc/ctrl.yml` in these examples), you're ready to bootstrap the Ziti network.
[ 0.120] WARNING zrok/controller.Bootstrap: missing public frontend for ziti id 'sqJRAINSiB'; please use 'zrok admin create frontend sqJRAINSiB public https://{token}.your.dns.name' to create a frontend instance
The `zrok admin bootstrap` command configures the `zrok` database, the necessary OpenZiti identities, and all of the OpenZiti policies required to run a `zrok` service.
[ 0.120] WARNING zrok/controller.Bootstrap: missing public frontend for ziti id 'sqJRAINSiB'; please use 'zrok admin create frontend sqJRAINSiB public https://{token}.your.dns.name' to create a frontend instance
If you find it necessary to re-run the `zrok admin bootstrap` command, you may need to add the `--skip-frontend` flag to avoid re-creating the default `public` frontend's Ziti identity and router policy.
The `zrok` bootstrap process wants us to create a "public frontend" for our service. `zrok` uses public frontends to allow users to specify where they would like public traffic to ingress from.
The `zrok admin create frontend` command requires a running `zrok` controller, so let's start that up first:
The id of the frontend was emitted earlier in by the `zrok` controller when we ran the bootstrap command. If you don't have that log message the you can find the id again with the `ziti` CLI like this:
This frontend config file has a `host_match` pattern that represents the DNS zone you're using with this instance of `zrok`. Incoming HTTP requests with a matching `Host` header will be handled by this frontend. You may also specify the interface address where the frontend will listen for public access requests.
The frontend does not provide server TLS, but you may front the server with a reverse proxy. The reverse proxy must forward the `Host` header supplied by the viewer. This example will expose the non-TLS listener for the frontend.
You can also specify an `oauth` configuration in this file, full details of are found in [OAuth Public Frontend Configuration](/guides/self-hosting/oauth/configuring-oauth.md#configuring-your-public-frontend).
The `zrok` frontend uses the `public` identity created during the bootstrap process to securely access zrok backends. to provide public access for the `zrok` deployment. It is expected that the configured listener for this frontend corresponds to the DNS template specified when creating the public frontend record above.
## Create a User Account
With our `ZROK_ADMIN_TOKEN` and `ZROK_API_ENDPOINT` environment variables set, we can create our first user account.
On another device that can reach your Linux server by FQDN, configure the API endpoint and enable the environment with the account token you received when you created the first user account.
```bash
export ZROK_API_ENDPOINT=https://zrok.quigley.com
# or
zrok config set apiEndpoint https://zrok.quigley.com
