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
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 Vercelx-vercel-set-bypass-cookie:truefor browser tests
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.
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.
Override from CI
PasscustomHeaders 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.
customHeaders field. See Environment custom headers and GitHub regression testing.