QA.pro
docs

From zero to a nightly run.

Ten minutes. On Cloud you need a site you can prove is yours; on your own runner, a machine with docker (a GPU makes it fast, a CPU works).

Try it on one machine no account

curl -fsSL https://qa.pro/local.sh | sh

Checks docker, python 3 and git, fetches the open-source repository, starts ollama (installs it if missing), pulls the vision model, builds the browser image and opens the panel on http://localhost:8080. The model uses the GPU when ollama finds one, the CPU otherwise.

Options go after sh -s --. Windows: run it inside WSL2. Until the public repository opens, set QAPRO_REPO_URL to your copy.

Quick start with a team

Four steps, then it runs on its own every night.

  1. 1

    Create an account

    Sign up, then add your first sites under Sites. New sites use the team's default tests.

  2. 2

    Verify, or connect a runner

    On Cloud, prove a site is yours once: a file, a meta tag or a DNS record. Testing a private staging? Paste the one-line command from Runners instead; your runner takes precedence.

  3. 3

    Run the tests

    Press Run all sites. Watch the live frames on the run page; read verdicts, screenshots and reasons when it ends.

  4. 4

    Make it nightly

    Settings: pick an hour (UTC, your local time shown beside it) and add an email or a Slack webhook. You hear from QA.pro only when something changes.

Tests

  • The shop pack ships 19 tests. Ten visitor-level ones are on by default.
  • Nine that write (account, cart, checkout in test mode) need a test account on the site's page.
  • A discovery run looks at what each site offers and leaves out the tests it cannot use ("not on this site").
  • Write your own in one line; the steps and proof questions are drafted for you to review.
  • Each site can have its own set and its own test account.

Devices

  • Desktop, laptop, iPad, iPhone 15, Galaxy S24, Galaxy Z Fold closed and open.
  • Every test runs once per device you tick on the site.
  • Phone profiles emulate touch, pixel density and a phone user agent.
  • Devices per site depend on the plan (1 on Free, up to 7).

API + CI

  • Create a key under Settings (Team plan and up).
  • POST /api/v1/runs with a list of URLs starts a run on a preview deployment.
  • Hosted runners take it when the preview host is under a verified domain of yours; your own runner otherwise. Sites that need your own runner go into a second run, listed as also_queued.
  • A ready-made GitHub Actions workflow polls and fails the job on red.

Connect a runner

A runner is the engine on a machine you control. It pulls runs from here and uploads results; test accounts and screenshots stay on that machine until you look at them.

QAPRO_ENROLL=<token> sh -c "$(curl -fsSL https://qa.pro/install.sh)" -- --server https://qa.pro

The token travels in the environment, so it never lands in your shell history. The Runners page prints this line with your token filled in.

Windows: irm https://qa.pro/install.ps1 | iex; Install-QAproRunner -Server … -Enroll … · from a checkout: python3 ee/runner/qapro_runner.py --server <url> --enroll <token>

Reference

Team APIGET /api/v1/sites · GET /api/v1/checks · POST /api/v1/runs {urls?, site_ids?, checks?} · GET /api/v1/runs?limit=&before= · GET /api/v1/runs/{id} · POST /api/v1/runs/{id}/cancel
Test accountSELENA_TEST_EMAIL SELENA_TEST_PASSWORD SELENA_TEST_USERNAME SELENA_TEST_FIRST_NAME SELENA_TEST_LAST_NAME set on the site's page
Self-hostingPostgres + uvicorn qapro.main:app behind a TLS proxy · alembic upgrade head on updates · mail via QAPRO_SMTP_* · full notes in ee/README.md
Open sourceThe single-server panel needs no control plane: one box, six copy-paste steps, see ONE-SERVER.txt in the repository.