Skip to main content
Whatever your codebase looks like, QLane gives the agent a real, running version of your app to drive. You pick which of the four modes matches your setup; you can mix them across environments in the same project.

​
What stays the same across modes

The agent’s job doesn’t change:
  • It opens a real browser against the running app.
  • It runs your active test cases plus any drafts triggered by the PR diff.
  • It captures per-bug screenshots, DOM snapshots, and reproduction steps.
  • It posts a GitHub review — silent on pass, structured on fail.
What changes between modes is only how the app comes alive in front of the agent.

​
Choosing a mode

A simple rule of thumb:
  • You don’t want QLane to build your code: use Test a URL or Existing previews.
  • You do want QLane to build your code, and your app is one repo: use Single repo.
  • Your app needs a database or other services to even start: use Docker Compose.
If you outgrow one mode you can switch — environments are configuration, not infrastructure, and the rest of your project (test cases, history, coverage) carries over.

​
Multiple environments per project

A project can hold more than one environment. Common patterns:
  • Staging URL + PR sandbox. Smoke the staging environment on a schedule, and spin up a fresh sandbox on every PR.
  • Preview + Compose. Use the Vercel preview for frontend PRs, fall back to a Compose stack for backend changes.
You wire which environment a PR triggers from the project’s PR testing settings.