Skip to main content
When a Vercel deployment is protected with a passphrase, Vercel Authentication, or Trusted IPs, QA.tech needs a Protection Bypass for Automation secret to open it. This page shows where that secret goes for pull request previews, for a single project URL, and for a one-off override from CI.
To run QA.tech from CI, see PR Testing and Regression Testing. For Vercel Firewall / WAF rules, see Vercel Firewall.

Overview

Vercel’s Protection Bypass for Automation lets QA.tech open a protected deployment with a secret. The bypass covers:
  • Password Protection
  • Vercel Authentication
  • Trusted IP restrictions
The secret is also stored on the Vercel deployment as VERCEL_AUTOMATION_BYPASS_SECRET. Regenerating it invalidates previous deployments until you redeploy. Do not put the secret in the environment URL. Store it as custom headers so the platform attaches them to matching browser, crawler, and API requests.
The bypass header covers Vercel Password Protection, so you do not need basic auth for Vercel previews. If a preview (or a host it loads) sits behind HTTP basic auth from another proxy, add environment basic auth next to the custom headers, in the same environment or preview defaults.

Enable the bypass in Vercel

1

Open project settings

In the Vercel project, go to Settings → Deployment Protection.
2

Turn on Protection Bypass for Automation

Enable Protection Bypass for Automation. Vercel generates a secret.
3

Copy the secret

Copy the secret. You will paste it into QA.tech in the next section. In GitHub Actions, store the same value as a repository secret if a workflow needs to override it.

Pull request previews

The GitHub App and GitLab create a new preview environment for each deployment URL. Headers on your default environment, and a secret baked into the project URL, are not sent to that URL. Set the secret once on the application. QA.tech copies it onto every preview environment it creates, including the next review of a commit that already has a preview row.
1

Open preview defaults

In QA.tech, go to Settings → Applications & Envs → [application] → Preview Environments. Select Edit on Preview defaults.
2

Add the bypass headers

Add a header rule:
  • Domains: *.vercel.app (or the host pattern your previews use)
  • x-vercel-protection-bypass: the secret from Vercel
  • x-vercel-set-bypass-cookie: true for browser tests
API tests receive x-vercel-protection-bypass only. The platform drops x-vercel-set-bypass-cookie on API requests, because that header loops when there is no cookie jar.
3

Save

Select Save. Optional: set Maximum concurrent tests here to cap every new preview. Leave it empty for no cap.
Do not put the bypass on a device preset. Device preset headers are for a test scenario, and that preset is reused on staging and production.

One static URL

Use this when every run should open one protected deployment, not a per-pull-request URL. Put the headers on that environment. Do not append bypass query parameters to the URL.
1

Open the environment

Go to Settings → Applications & Envs, open the application, and edit the environment.
2

Set the environment URL

Use the clean deployment URL only, for example https://example-vercel-protected.vercel.app.
3

Add a custom header rule

Under Custom headers, add a rule with domain pattern *.vercel.app (or your host pattern) and these headers:Use x-vercel-set-bypass-cookie for browser tests so Vercel sets a bypass cookie for the rest of the session. API tests receive x-vercel-protection-bypass only.
4

Save

Save the environment. Matching hosts receive these headers on browser, crawler, and API requests.
See Environment custom headers for domain patterns.

Override from CI

Pass customHeaders on the environment when the GitHub Action or the Start Run API should use a different secret for that preview. An explicit value replaces the preview-default headers for that preview. Omit the field on create and QA.tech seeds the application’s preview defaults. Omit the field when reusing a preview and the stored headers stay as they are. Pass [] to clear them.
The Test Run Action takes the same customHeaders field. See Environment custom headers and GitHub regression testing.

Header reference