Skip to main content
If your team already builds a preview deployment for every pull request, you don’t need QLane to build it again. QLane waits for your preview to be ready and runs the agent against it.

When to use this mode

  • You already have per-PR preview deployments on Vercel, Netlify, Cloudflare Pages, or similar.
  • You want faster turnaround — no QLane build means tests start sooner.
  • You want to save sandbox credits — preview-mode sessions don’t consume sandbox compute.
  • You want QLane to test the exact artifact your team reviews in the preview.
If you don’t have previews already, or your stack needs services that aren’t in the preview (a real database, a worker), use Single repo or Docker Compose instead.

Set it up

From the project page, open Environments → New environment and choose Existing previews.
  1. Provider — Vercel, Netlify, Cloudflare Pages, or “Other (URL template)” for everything else.
  2. Repository — the GitHub repo whose previews you’re testing.
  3. URL template (only when “Other”) — for example, https://{branch}.preview.example.com. QLane fills {branch}, {commit}, or {pr} from the PR.
  4. Test credentials — same as Test a URL. Encrypted at rest.
  5. Linked repo — read-only code access for the agent. Defaults to the same repo.
Save.

How QLane discovers your preview

For first-party integrations, QLane reads the provider’s deployment_status webhook — the same signal your team uses to find the preview in your PR. When the deployment goes “ready”, QLane starts the session. For URL-template setups, QLane interpolates the template using PR metadata and polls the URL until it responds.

Triggering runs

Like other PR-bound modes, sessions fire automatically when a PR is opened or updated and PR testing is enabled for the project. You can also trigger a session manually for any commit on the dashboard.

What you don’t get

Preview mode is browser-only. The agent has no shell, no logs, no database — just the running app at the URL.
  • No shell access. If you need the agent to inspect files or run commands, link a repo (read-only code access) or move to a sandbox mode.
  • No log inspection. Server logs on Vercel/Netlify/etc. aren’t reachable from the sandbox.
  • No deep-testing mode. The agent can’t add temporary logging and re-run; it can only drive the UI.
These limits aren’t blocking for most teams — most PR regressions are visible in the browser. But if your bugs hide in server-only paths, pair this with a Compose environment for the harder ones.

Common gotchas

  • Preview takes ages to build. QLane waits patiently, but the user-visible turnaround is dominated by your provider’s build, not QLane. If preview builds are slow, consider a sandbox mode for the parts you need fast feedback on.
  • Preview auth. If your preview requires a password (Vercel password-protected previews, Netlify password lock), the agent can’t get in. Either disable preview auth, or move to a sandbox mode where the URL is generated by QLane and not protected.
  • Deployment URL changes. Some providers rotate URLs between commits. The webhook-driven flow handles this; URL templates only work if the pattern is stable.