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.

Every pull request you open is a potential regression. Opslane eliminates the manual work of writing and running tests by automatically launching a full browser test run the moment a PR is created or updated. You get pass/fail feedback directly in the PR — no CI configuration, no test scripts, no waiting.

​
How the trigger works

Opslane installs as a GitHub App on your repository. When you grant access, the app subscribes to pull request events from GitHub’s webhook system. Any time a PR is opened, synchronized (new commits pushed), or reopened, Opslane receives the event and kicks off a new test run immediately.
1

PR is opened or updated

A developer pushes commits and opens a pull request, or pushes new commits to an existing PR. GitHub fires a webhook event to Opslane.
2

Opslane detects the preview URL

Opslane reads the PR’s deployment status to find the live preview URL for the branch — the same URL a reviewer would open in their browser.
3

A browser run is launched

Opslane spins up an ephemeral Chromium browser, navigates to the preview URL, and begins crawling and testing the app. See Browser runs for details on what happens inside the run.
4

Results are posted to the PR

When the run finishes, Opslane posts a comment on the PR with a pass/fail verdict, screenshots, and a video recording. The GitHub status check is updated accordingly.
Opslane requires a live preview deployment for the PR branch — for example, a Vercel preview, a Netlify deploy preview, or any URL that becomes available when the branch is deployed. Opslane does not build or deploy your app itself.

​
What gets tested

Opslane does not rely on test scripts that you write. Instead, it crawls the deployed preview of your PR branch, discovers pages and interactive flows, and verifies that they behave correctly. The test scope is determined automatically based on what Opslane finds in the running app. This means:
  • You never write or maintain test files.
  • Coverage grows as your app grows — new pages and flows are discovered on subsequent runs.
  • Opslane checks the same app that your users will interact with, not a mocked or headless version.
If your app requires authentication, you can configure login credentials so Opslane can reach protected pages. Refer to the setup guide for details.

​
How regressions are detected

Opslane compares the behavior of the PR branch against the baseline established from your main branch. A regression is flagged when the PR branch exhibits a failure that wasn’t present on the baseline — for example, a page that previously loaded now returns an error, a button that was clickable is now broken, or a form that submitted successfully now fails.
  • The GitHub status check on the PR is set to failed.
  • The PR is blocked from merging (if branch protection rules require the Opslane check to pass).
  • Opslane posts a comment identifying which flows failed, with screenshots and a video of the failure.
Merge blocking requires that you configure Opslane’s status check as a required check in your repository’s branch protection rules. Without this, Opslane will still report results but cannot block merges automatically.

​
The difference from writing your own tests

Most test frameworks require you to write scripts that describe exactly what to click, what to fill, and what to assert. This takes time to author and becomes a maintenance burden as your UI changes.

Traditional test scripts

You define every step manually. Tests break when the UI changes, even if the app is working correctly. Keeping tests up to date requires ongoing engineering effort.

Opslane PR testing

Opslane determines what to test by exploring your live app. No scripts to write or maintain. The run adapts as your app evolves.
This approach is complementary to unit tests and integration tests you already have. Opslane focuses on what actually runs in the browser — the end-to-end behavior that users experience.