> ## Documentation Index
> Fetch the complete documentation index at: https://docs.qlane.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Existing previews

> Test the per-PR preview deployments you already build with Vercel, Netlify, or Cloudflare Pages — no extra sandbox compute, faster turnaround.

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](/connect/single-repo) or [Docker Compose](/connect/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](/connect/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.