Skip to content
Prooflane
Sign inStart testing

Ship faster. Know what actually works.

AI testing, code review, and reproducible evidence for every release.

Test your appExplore the demo
Sample projectFixture Shop · run #1 · TC-2
Fixture Shop cart showing a total of $12.96 for two $12.00 mugs; the expected total is $25.92
1

Cart total should equal subtotal × 1.08

expected 25.92 ± 0.01 · observed 12.96 · reproduced on 2 of 2 attempts

The sample run shown is real: 7 cases against our seeded Fixture Shop found 5 failing behaviours, each reproduced on retry, and one case left inconclusive because no visual baseline was approved yet.

Point it at a staging environment you control.

Describe what matters in plain language. A planner proposes cases with explicit assertions; you approve what runs.

Nothing runs anonymously. After you create an account you verify that you control the host, and only that host is tested; third-party requests are blocked.

From a requirement to a fix you can verify.

One evidence chain connects every step, so a release decision can point at what was observed rather than at a green icon.

Sample project · real data from run #1

AC-2.1 · The cart total equals the subtotal plus 8% sales tax.

Requirements and acceptance criteria are the source of truth. The planner proposes cases that cite them, states its assumptions (“sales tax is a flat 8%”), and lists ambiguities instead of guessing. Nothing runs until a person approves the plan.

What works today, and what does not yet.

Status comes straight from the capability registry the product itself uses. Nothing here is a roadmap dressed as a feature.

Web applications

Approved cases run in isolated Chromium sessions with semantic locators, explicit assertions and per-step evidence.

  • Web functional & E2E testing (Chromium)Available
  • Firefox and WebKit executionNot available yet
  • Bounded discovery crawl (same-origin, GET only, signed-in pass)Available
  • Screenshots, traces, console/network logs, DOM snapshotsAvailable

Visual and accessibility

Pixel comparison against baselines a person approved, and named axe-core rules with their version recorded.

  • Deterministic screenshot comparison with approved baselinesAvailable
  • Automated axe-core rules, keyboard and reflow checks, guided WCAG 2.2 A/AA reviewAvailable

Performance

Response-time thresholds on the requests a journey actually makes, versioned with the case.

  • Response-time thresholds on observed requestsAvailable
  • k6 load, spike, stress and soak profilesPreview

AI providers

OpenAI and Anthropic behind one gateway, with routing, fallbacks, budgets and kill switches under admin control.

  • OpenAI provider adapterAvailable
  • Anthropic Claude provider adapterNeeds your API key
  • Deterministic fixture provider (development only)Available
  • Admin AI Control Center (keys, catalogue, routing, budgets, kill switches)Available
  • Dual-provider independent review of high-risk findingsNot available yet
  • AI-application evaluationsPreview
  • AI fix prompts for coding agentsAvailable
  • Plan trials and bounded repair before reviewPreview
  • Organization AI routing overridesAvailable
  • AI run summaries in reportsAvailable

APIs, code and mobile

Designed into the data model and shown honestly as not yet available.

  • OpenAPI / Postman import and contract testsNot available yet
  • Android on local emulators (adb + uiautomator)Available
  • iOS simulator on macOS device workersPreview
  • Flutter source-based tests (Patrol / integration_test)Not available yet
  • Build upload and inspection (APK, simulator .app)Available
  • Device clouds (BrowserStack and similar)Not available yet
  • GitHub PR ingestion and AI code reviewPreview
  • Semgrep, secrets, dependency and IaC scanner adaptersPreview
  • Rate limits shared across API replicas (Redis)Available
  • gVisor/Kata/microVM worker isolationNot available yet

Reports and CI

Exports you can keep and a release gate that never turns a blocked run green.

  • HTML, Markdown, JSON, JUnit and SARIF reportsAvailable
  • Portable Playwright test exportAvailable
  • Deterministic release gate and CLI exit codesAvailable
  • Change-impact test selectionAvailable
  • GitHub App checks and PR commentsPreview
  • Signed outbound webhooksAvailable
  • Jira and Linear issues from findingsPreview
  • Slack notificationsPreview
  • Email notificationsPreview
  • MCP serverAvailable

Built so you can check our work.

Portable tests

Every approved case exports as a runnable Playwright project with its revision id and hash. Our sample bundle runs outside the platform with npm install and npx playwright test.

Inspectable evidence

Screenshots, traces, console and network logs are stored with SHA-256 hashes and linked from every finding. Missing evidence is shown as missing.

Controlled maintenance

Approved cases are immutable revisions. Edits create a new revision; a running run keeps the one it pinned. Automated locator repair is planned and will never be allowed to weaken an assertion.

Budgets you set

Browser time and AI usage are reserved before work starts and settled after, per organization and project. Unknown model prices show as unknown, never as free.

Private execution

Workers reach only the host you verified through an egress proxy that blocks private, loopback and cloud-metadata addresses, including after redirects and DNS changes.

Honest outcomes

Passed, failed, blocked, inconclusive, not run, flaky and infrastructure errors stay distinct. A blocked required case can never produce a green gate.

The product, not a picture of one.

Screenshots from the implemented app running the sample project.

Run evidence screen (sample project)Sample project

Run evidence

Film strip of cases, steps at their real duration, the screenshot with numbered indications.

Finding detail screen (sample project)Sample project

Finding detail

Expected and observed side by side, reproduction, evidence hashes and a fix bundle.

Test Studio screen (sample project)Sample project

Test Studio

Readable steps and assertions, immutable revisions and plan approval.

Fits the pipeline you already have.

A REST API with an OpenAPI contract, a typed TypeScript client, a single-binary CLI and an MCP server. Exit codes tell CI exactly what happened.

CLI exit codes
0Release gate passed
1Tests failed
2Blocked or incomplete (never treated as a pass)
3Infrastructure or API error
4Usage, configuration or authentication error

An MCP server for coding agents

prooflane mcp serves Prooflane to an MCP client over stdio, or over Streamable HTTP with --listen, where every request carries its own bearer API token. Each tool is a REST call made with that token, so scopes, roles, budgets and tenant checks apply exactly as they do for the API. Agents can draft and start work; approving a plan stays a person's action in the web app.

  • create_test_plan
  • review_plan
  • start_run
  • get_run
  • cancel_run
  • list_findings
  • get_finding_evidence
  • export_tests
  • propose_fix
  • list_projects
  • list_environments
# .github/workflows/verify.yml (step)
- run: |
    prooflane run --suite "$SUITE_ID" \
      --commit "$GITHUB_SHA" --wait --junit results.xml
  env:
    PROOFLANE_TOKEN: ${{ secrets.PROOFLANE_TOKEN }}
    PROOFLANE_ORG: ${{ vars.PROOFLANE_ORG }}
    PROOFLANE_PROJECT: ${{ vars.PROOFLANE_PROJECT }}
# MCP client configuration (stdio)
{"command": "prooflane", "args": ["mcp"],
 "env": {"PROOFLANE_TOKEN": "pla_..."}}

# Or Streamable HTTP at http://127.0.0.1:8790/mcp;
# send "Authorization: Bearer pla_..." on every request
prooflane mcp --listen 127.0.0.1:8790
curl -X POST "$API/v1/orgs/$ORG/projects/$PROJECT/runs" \
  -H "Authorization: Bearer $PROOFLANE_TOKEN" \
  -H "Idempotency-Key: $GITHUB_RUN_ID" \
  -d '{"environment_id":"…","suite_id":"…","commit_sha":"'$GITHUB_SHA'"}'
# 202 {"run": {...}, "status_url": "/v1/orgs/…/runs/…"}

How your data and targets are protected.

What the system does today, stated plainly. We hold no third-party security certification yet and display none.

Tenant isolation in the database
Every tenant row is guarded by PostgreSQL row-level security under a non-owner application role, plus composite keys that stop cross-tenant links. Tests cover pooled connections.
Secrets are write-only
Test credentials and provider keys are envelope-encrypted, never returned by the API, and injected only into the worker that needs them for one attempt.
Scoped, short-lived worker credentials
Workers hold a token for one attempt and a fencing number; a superseded worker's writes are rejected.
Controlled egress
Browsers reach only verified hosts through a proxy that validates DNS answers and dials the checked address. Private targets need an explicit allowlist.
Isolation boundary, honestly
Local development runs workers as containers or processes. That is not a hostile-tenant boundary; production guidance requires gVisor, Kata or microVM sandboxes.
Model providers
Organizations choose which providers may receive page text, screenshots or source code. A disallowed fallback is dropped, never used silently.

Pay for what runs.

Usage is metered in browser minutes and AI tokens, with included allowances per plan. Infrastructure failures are credited, not billed.

Illustrative figures for evaluation only. These are not commercial terms.

MeterHow it is measuredIllustrative rateIncluded (illustrative)
Browser timeWall-clock seconds per attempt, Chromium$0.002 per minuteDeveloper budget default: $25/month
AI usageTokens by type at the provider's versioned pricePassed through at costDeveloper budget default: $25/month
Your own provider keysBilled by the provider to your account—Planned

Questions teams ask first

Can you test environments that are not public?

Yes, through an explicit private-target allowlist per organization; in this release that allowlist is a deployment setting. A tenant-scoped connector is planned. Workers never get general access to your network.

Do you need access to our code?

No. Browser testing needs only a verified staging URL. Repository review is planned for a later release and will use a least-privilege GitHub App.

How are test credentials handled?

They are encrypted on write and never shown again. A worker fetches them once per attempt over an authenticated internal call, keeps them in memory, and strips them from logs and traces.

Do you test on real phones?

Not yet. Android apps run on emulators and iOS apps on the iOS Simulator (no taps or typing on iOS yet), and every result names the device type. Web runs use desktop Chromium with an emulated viewport, labelled that way. Real phones through device clouds are planned.

How accurate is it?

On our seeded Fixture Shop, the sample plan catches each seeded defect that has an explicit assertion. That is a controlled fixture, not a claim about your application. AI-proposed cases are reviewed before they run, and failures always come with evidence.

Can we leave and take our tests?

Yes. Export any run's cases as a Playwright project and its results as HTML, Markdown, JSON or JUnit.

What are the limitations?

Chromium only; no mobile, API contract or code review yet; automated accessibility checks are not a WCAG conformance claim; live OpenAI and Anthropic routes need your keys before they are verified.

See what your green checks are missing.

Start with a staging URL and one sentence about what matters.

Test your appExplore the demo