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.
ModeWhen to use itWhat QLane does
Test a URLYou already have a staging or production URL the agent can reach.Hits the URL directly. No build, no sandbox.
Single repoOne repo, one Node.js app.Clones, builds, and runs it in an isolated sandbox on every PR.
Docker ComposeMulti-service stack (web + API + worker + database).Brings the whole stack up from a Compose file.
Existing previewsYou already deploy per-PR with Vercel, Netlify, or Cloudflare.Waits for your preview, then tests on top — no QLane compute.

​
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.