A small pilot.
A fleet when it works.

Set up your workspace.

Choose Start a test. On a fresh installation, create the owner account with your name, workspace name, email and a unique password. If your workspace is already set up, sign in to continue. This pilot supports one owner account; your email is a sign-in identifier and no email is sent.

1. Connect the website.

In Websites, enter the starting URL and exact allowed origins for the app, sign-in and task API. Enable form submissions if the task changes data. Set the locale, time zone, default task and a precise final-state check. Navigation spacing applies to browser page/frame loads, not every fetch or XHR. If a navigation would exceed the short browser command window, the worker stops with a rate-limit result instead of sending it early. Include both bare and www hostnames when the journey uses both.

The built-in demos cover a shop, task board and booking form. Use your staging app and test accounts for your real product journey. Private enterprise applications require an exact operator-approved origin on the coordinator and each worker, plus network access. Approval is empty by default; link-local and metadata endpoints remain blocked. See the private-site setup below.

2. Add test-account sessions.

Open Websites, choose Access settings to configure domains, locale, timezone and account assignment, then choose Add account state to import a dedicated test account’s storageState file.

Import Playwright storage-state JSON files, or run this from the Wayglint app directory:

python3 population_login.py --site-id SITE_ID --account-label qa-01

The helper opens a headed browser for manual sign-in, then saves and imports its session after you press Enter. Cookies and proxy credentials live in private files. Account-state files grant access to the account; keep them private. Saved session states do not create new accounts or prove account uniqueness.

3. Preflight, then run a pilot.

Run the website preflight in the studio. It opens a real read-only browser and checks reachability, visible controls, login/challenge signals and whether success is already true. Settings changes invalidate the check. It establishes readiness to try a task, not task completion.

Create a campaign for 2–5 participants. Start it, inspect actions and verify that the final-state check matches the intended outcome. Correct failures before creating a two-million-participant run.

4. Connect browser workers.

The local worker runs automatically when a local campaign starts. Download the worker bundle for another macOS/Linux machine. It contains source, dependency versions and setup instructions; it excludes keys, accounts and model weights. Remote machines need its Python/Node dependencies, a Playwright Chromium installation and an installed browser reasoning model. The current development model is qwen3-coder:30b; each host needs enough memory for its model plus browsers.

Generate a worker key in Workers & IPs, save it in a private file with permissions 0600, then run on the worker host:

export POPULATION_OLLAMA_URL=http://127.0.0.1:11434
export POPULATION_BROWSER_MODEL=qwen3-coder:30b
python3 population_worker.py \
  --coordinator https://YOUR-PRIVATE-COORDINATOR \
  --token-file /private/path/worker.key \
  --name worker-01 --concurrency 1

Use a trusted private connection or HTTPS. Workers receive task account state and proxy configuration. Scope their keys to the intended website where appropriate. The local coordinator binds to loopback by default; this page does not provision a fleet or publish the service.

5. Decide how traffic leaves the worker.

Direct mode uses that host's actual network connection. Separate browser contexts on the same host normally share its public IP. A configured proxy profile routes the browser through your proxy; the studio stores credentials privately and can measure that route's public egress.

The IP probe runs on the coordinator. Remote workers may have different direct egress; measure from each host or its configured route when that distinction matters. Wayglint does not provide residential IPs, buy proxies, create an IP per persona or bypass website challenges.

6. Give two million journeys real capacity.

Create a campaign with 2,000,000 participants, remote dispatch, a sensible session start rate and a trace budget. Campaigns start paused. Enable the worker fleet, start execution and follow real throughput. With 100 concurrent slots averaging 20 seconds per journey, simple planning arithmetic is about 111 hours, before rate limits and retries.

Accounts, model latency, machine memory, website capacity and retry rates determine actual completion time. A local hardware concurrency limit protects this machine; it does not limit the campaign's participant count. Native apps and universal human-level behavior remain outside this browser implementation.

Private enterprise websites

The coordinator and every worker must be able to reach the application through your approved network. Operators can explicitly allow exact private origins using POPULATION_APPROVED_PRIVATE_ORIGINS, a JSON array of scheme, host and optional port. The site profile must independently include each origin in Allowed app origins.

export POPULATION_APPROVED_PRIVATE_ORIGINS='["https://staging.internal.example:8443"]'

Set this before starting the coordinator and each worker. There are no wildcard or CIDR approvals and no automatic VPN, SSO or network provisioning. Loopback expansion, link-local addresses and metadata endpoints stay blocked. These application checks do not replace a restricted worker network or provide DNS-rebinding isolation.

Use a dedicated test environment and start with a verified pilot. The app does not guarantee compatibility with every website, CAPTCHA, interactive identity provider or native application.