Onboarding walkthrough
A step-by-step tour of the first-run setup wizard, from creating the admin to launching your first worker.
The first-run wizard configures a fresh control plane end to end. It creates the admin, names the cluster and its hostnames, sets up TLS, adds your first worker, and renders the live load-balancer config. This page walks through every step so you know what each field does and how to pick the right options.
Overview
The wizard appears automatically on any control plane with an empty database or an unconfigured cluster. It is the only thing the UI serves until an admin exists and the cluster has been rendered at least once.
You can reach and complete most of the wizard over plain http://<ip> before any DNS
exists, which is the intended bootstrap path. You only need a hostname and TLS once you
want clients to connect over wss://…/launch. See Installation
for how to get the container running first.
Bootstrap order
Open the manager at http://<ip>/, walk through the wizard, and switch to a real
hostname plus TLS at the TLS step once your DNS record points here. There is no need
to configure DNS before you start.
Step 1: Create admin
The first screen creates the initial admin account. It requires a one-time setup token that the container generates on first boot.
Find the token in either place:
- The
install.shoutput prints it directly at the end of a fresh install. - The container logs via
docker logs <container>.
Paste the token, then choose an admin username and password. On success a session is minted immediately, so you stay logged in and move straight to the next step.
Step 2: Cluster basics
Name the cluster and set its hostnames:
- Cluster name is a label for this control plane.
- Main hostname serves both the console (UI + API) and client connections at
wss://<host>/launchon a single domain. This is the address your automation connects to. - Release hostname (optional) is a second domain for browser and profile bundle downloads, needed when you run workers on other servers.
- Advanced: split subdomains separates the console, launch, and release origins onto distinct subdomains instead of sharing one.
- IP-only evaluation is an opt-out that skips the hostname and TLS entirely so you can
try the cluster over
http://<ip>. It is fine for a quick evaluation. Switch to a hostname and TLS before production, sincewss://…/launcheffectively requires HTTPS.
Step 3: TLS
Traffic to the end user is always HTTPS. This step decides where TLS is terminated and what the origin presents. Pick the mode that matches how requests reach this host:
| Mode | Choose it when |
|---|---|
| Cloudflare | Your domain is proxied through Cloudflare (the orange cloud) |
| Bring your own certificate | You already hold a PEM certificate and key |
| Automatic HTTPS (Let's Encrypt) | DNS points straight at this host, with ports 80 and 443 open |
Each mode's sub-options, the origin lock that keeps non-Cloudflare traffic out, and the troubleshooting steps for failed certificate issuance are covered in Edge security & TLS. You can change the mode later from Settings without re-running the wizard.
Step 4: Add a worker
Workers run the actual browsers. Add your first one:
- Add local worker provisions a worker on this same host with one click (it requires the Docker socket mount from the install step).
- Copy-paste
docker runis for a remote or bring-your-own host. Copy the generateddocker runsnippet and run it on that machine. This is today's model for anything not on the manager's own box.
Step 5: Review & launch
The final step summarizes your choices. Click Render & Reload to write the real load-balancer config and reload OpenResty, then the wizard runs an automatic health check on the cluster.
When it finishes, point your automation at the connect URL:
wss://<public-hostname>/launchRoadmap / Coming soon
Richer worker provisioning is planned but not available yet. These are future direction, not current features:
- Remote worker over SSH: the manager would SSH into a remote server and install the
worker there for you, replacing the manual
docker runstep. - Cloud deployments: provision workers directly on providers such as AWS and Hetzner from the console, without touching a server yourself.
For now, add remote workers with the copy-paste docker run snippet from Step 4.