DOCUMENTATION

Know what runs where — and what never leaves your network.

TestPilot Works separates orchestration from execution. These docs explain the deployment model, private runner boundary, CI credentials, release gate and privacy defaults.

01 · ARCHITECTURE

Control plane outside. Execution plane close to the product.

TestPilot Works separates project orchestration, run state, reporting and audit metadata from browser/API execution. The recommended deployment is hybrid-first: TestPilot Works hosts the control plane while a private runner executes tests inside the customer environment.

TestPilot Works control plane Projects · Runs · Reports · RBAC · Audit | | outbound HTTPS polling v Customer Private Runner Playwright · k6 · local secrets | v Customer staging / test system

Deployment modes

  • Private Runner: execution stays inside the customer network.
  • Hybrid Runner: managed orchestration plus customer-local execution; this is the preferred default.
  • Cloud Runner: suitable only for approved public or allow-listed test systems.
Tenant boundary: runner credentials resolve to one tenant and project scope. Test configuration, jobs, users, roles and audit metadata remain tenant-isolated.
02 · PRIVATE RUNNER

Target URLs and credentials stay runner-local.

The control plane does not need to store the real customer staging or internal endpoint. It stores an environment label such as staging or uat; the real BASE_URL, API_BASE_URL, credentials and allowlist remain on the private runner.

RUNNER_ENVIRONMENT=staging BASE_URL=https://staging.customer.internal API_BASE_URL=https://api.staging.customer.internal RUNNER_ALLOWED_HOSTS=staging.customer.internal,api.staging.customer.internal

A runner may claim a job only when tenant, project, supported suite and environment match. Teams with staging and UAT normally deploy separate runner instances with separate local endpoint configuration.

Customer-specific test packs

Private Playwright suites can live outside the platform core in a customer-controlled repository or filesystem. The runner chooses the local test root; the control plane cannot override it.

03 · CI INTEGRATION

Trigger tests without exposing a human dashboard credential.

CI credentials are project-scoped, revocable, expiring and limited by explicit suite and environment allowlists. Raw credentials are shown once and stored only as hashes.

POST /ci/trigger Authorization: Bearer tpw_ci_<secret> Content-Type: application/json { "suite": "smoke", "environment": "staging" }

Supported CI-triggered suites are smoke, api and regression. Performance smoke is intentionally excluded from CI credentials and remains a customer-controlled runner action.

Pipeline helper

export CONTROL_PLANE_URL="https://app.testpilotworks.com" export TESTPILOT_CI_TOKEN="<secret>" npm run ci:trigger -- \ --suite smoke \ --environment staging \ --timeout-seconds 900
04 · RELEASE READINESS

A small release gate built from fresh QA evidence.

The gate evaluates the latest completed Smoke, API and Regression result for a project and environment. Evidence older than 24 hours is treated as stale.

STATEMEANING
READYAll required suites passed and the evidence is fresh.
BLOCKEDAt least one latest required suite failed.
STALERequired suites passed, but at least one result is older than 24 hours.
NO_DATAAt least one required suite has no completed result.

Flaky tests do not automatically block a release, but they raise a READY release from LOW to MEDIUM risk.

npm run ci:gate -- --environment staging 0 = READY 1 = BLOCKED / integration error 2 = STALE / NO_DATA / required run active
05 · PRIVACY-SAFE REPORTING

Useful QA signal without shipping test-level customer data.

The runner aggregates Playwright results locally and uploads only five counters for this reporting path:

total passed failed skipped flaky

Test names, page URLs, assertion messages, screenshots, traces, request bodies and response bodies are not part of the aggregate reporting contract. CI also validates the summary schema so new telemetry cannot be added silently.

06 · SECURITY DEFAULTS

Least privilege is the default operating model.

  • Use staging and test environments by default.
  • Use least-privilege test identities and customer-controlled secret stores.
  • Never hard-code credentials or write them into logs.
  • Keep screenshots, video and traces disabled unless explicitly required.
  • Redact authorization headers, cookies, tokens, passwords, API keys and session data before logs leave the runner.
  • Use short retention and failure-only artifacts when artifacts are enabled.
Core principle: the hosted control plane should know enough to orchestrate and report a release signal, but not enough to become a copy of the customer's application data or secrets.