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

# How QLane fits your app

> Compare the four ways to connect QLane to your app: testing a URL, a single repo, a Docker Compose stack, or an existing PR preview deployment.

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.

| Mode                                                | When to use it                                                    | What QLane does                                                 |
| --------------------------------------------------- | ----------------------------------------------------------------- | --------------------------------------------------------------- |
| [**Test a URL**](/connect/test-a-url)               | You already have a staging or production URL the agent can reach. | Hits the URL directly. No build, no sandbox.                    |
| [**Single repo**](/connect/single-repo)             | One repo, one Node.js app.                                        | Clones, builds, and runs it in an isolated sandbox on every PR. |
| [**Docker Compose**](/connect/docker-compose)       | Multi-service stack (web + API + worker + database).              | Brings the whole stack up from a Compose file.                  |
| [**Existing previews**](/connect/existing-previews) | You 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.