Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.opslane.com/llms.txt

Use this file to discover all available pages before exploring further.

Opslane operates as a three-phase pipeline that runs automatically on every pull request: Connect, Verify, and Ship. When a PR opens, a GitHub App event triggers the pipeline. An ephemeral sandbox spins up, a real browser crawls your app and exercises its flows, and then the results are posted back to the PR as a comment. The whole process requires no test scripts and no CI configuration from you.

​
Phase 1: Connect — GitHub App watches for PR events

When you install the Opslane GitHub App on a repository, it registers a webhook that fires on pull request events. Every time a PR is opened or a new commit is pushed to an existing PR, the webhook sends an event to Opslane. Opslane receives the event and reads the metadata: the branch name, the base branch, the repository, and the deployment URL associated with the PR. If your repository uses preview deployments (for example, via Vercel, Netlify, or a custom CI pipeline), Opslane detects the preview URL from the PR status checks. If no preview URL is present, you can configure a static URL pattern in the Opslane dashboard.
You do not need to add any steps to your existing CI workflow. The GitHub App handles the trigger entirely through webhooks.

​
Phase 2: Verify — ephemeral sandbox and real browser crawl

Once Opslane has the deployment URL for the PR, it provisions a fresh ephemeral sandbox — an isolated environment created specifically for this run and destroyed when it finishes. Inside the sandbox, Opslane launches a real Chromium browser (not a headless simulation) and navigates to your app. It then runs the crawl-and-verify process:

​
What “crawling flows” means

Instead of executing a test script, Opslane explores your app the way a user would. It identifies interactive elements — buttons, forms, links, navigation items — and constructs a map of the flows that exist in your application. This map is built automatically from your live app, not from code you wrote. On subsequent runs, Opslane re-exercises the same flows and compares the results against the baseline captured from your main branch. If a flow behaves differently — a button that no longer appears, a form that returns an error, a page that fails to load — Opslane records it as a regression.
Opslane detects functional regressions: flows that worked before the PR and no longer work after it. This includes broken navigation, failed form submissions, missing UI elements, JavaScript errors that prevent interaction, and pages that return errors or fail to render.
Opslane focuses on critical flows — the paths a user is most likely to take through your app. The crawler prioritizes depth over breadth, exercising complete flows rather than clicking every link. As Opslane learns your app over multiple runs, its understanding of your flows improves.
Opslane supports testing flows that require authentication. You can provide test credentials in the Opslane dashboard and configure which flows should run with those credentials. The credentials are stored encrypted and are only used inside the ephemeral sandbox.

​
Ephemeral sandboxes and your code

The sandbox that Opslane uses is created fresh for each run and deleted immediately after. Opslane never stores or retains your application source code. The browser session interacts with your deployed app over the network, exactly as an end user would. Nothing from your codebase is copied into the sandbox.
Opslane tests your deployed preview environment, not a local build. Make sure your PR has a live deployment before the Opslane check runs, or configure a deployment URL in the dashboard.

​
Phase 3: Ship — results posted to the PR

After the browser session completes, Opslane processes the results and posts a comment on the pull request. The comment includes:
  • Pass/fail status for each flow that was tested
  • Screenshots taken at key steps during the session, so you can see exactly what the browser saw
  • A video recording of the full browser run, letting you replay the session and identify where a regression occurred
Opslane also sets a GitHub check status on the PR:
  • If all flows pass, the check is marked successful and the PR can be merged normally.
  • If a regression is detected, the check is marked failing, which blocks the merge automatically through GitHub’s branch protection rules.
If you believe a failing check is a false positive, a team member with write access to the repository can manually override the check in GitHub and proceed with the merge.

​
Pipeline summary

​
Next steps

Quickstart

Connect your first repository and run your first PR test in two minutes.

Introduction

Learn how Opslane compares to writing tests with Playwright or Cypress.