Coding agents and access

Cloudflare Zero Trust integration

TesterArmy tests staging sites behind Cloudflare Zero Trust by sending saved bypass headers on every request to the host.

START TESTING FOR FREE READ THE SETUP DOCS

[01] Access

What the agents send

The Site Protection card holds the Cloudflare Access client ID and secret, and TesterArmy sends both headers on every request to the deployment host so runs load the app.

Site Protection · Cloudflare Zero Trust

Cloudflare Zero TrustHeaders saved

CF-Access-Client-Id: ••••••••••••
CF-Access-Client-Secret: ••••••••••••
Sent on: Every request to the deployment host
Saved in: Project Settings, Integrations, Site Protection
Result: Runs load the app instead of the Access login screen

Service token
The recommended route is a service token from Zero Trust with a Service Auth policy that includes it.
Bypass policy
The alternative is a Bypass policy on an HTTP header such as X-Tester-Army-Bypass, saved as a custom header.
Not for logins
HTTP Basic Auth has its own Site Protection card, and app login forms use Test Credentials instead.

[02] Setup

How it works

Setup is the Cloudflare Zero Trust card under Project Settings, Integrations, Site Protection. Cloudflare admits the headers once the Access application has a Service Auth or Bypass policy matching them.

Create a service token

Create a service token under Access, Service Auth in Cloudflare Zero Trust and copy both values, since the Client Secret is shown only once.

Add the Access policy

On the Access application that protects the site, add a policy with action Service Auth and an Include rule of type Service Token matching that token.

Save the headers in TesterArmy

Save the Client ID and Client Secret on the Cloudflare Zero Trust card under Site Protection, and every run sends both headers to the deployment host.

Read the setup docsThe docs show how to spot an Access block, set up either bypass method and save the headers.

See it on your own app

START TESTING FOR FREE

[03] Related

Works with

Vercel previews use their own Protection Bypass for Automation token, GitLab CI review apps and other CI deploys must be reachable, and GitHub pull request runs test each preview deployment.

VercelPreview deployments from one selected Vercel project are tested on every pull request.GitLab CIA signed group webhook runs a test group after GitLab CI deploys.CI webhooksJenkins, Buildkite, CircleCI or a shell script triggers a group with one request.GitHubThe GitHub App posts checks and comments on every pull request preview.

[04] FAQ

Questions

TesterArmy tests sites behind Cloudflare Access once a service token pair or a bypass header is saved under Site Protection, and sends those headers on every request to the deployment host.

A service token with a Service Auth policy is the recommended route. A Bypass policy on a custom header such as X-Tester-Army-Bypass suits teams that cannot create a token, and either method works with TesterArmy.

Cloudflare Access blocks the browser at the edge before the app loads, and these headers solve that. HTTP Basic Auth has its own Site Protection card, and an app's own login form uses Test Credentials.

Site Protection is a project-level setting, and the Cloudflare headers go out on every request to the deployment host, so a regression run started by GitLab CI or a webhook reaches a protected review app.

[05] Start behind Cloudflare

Test staging behind Cloudflare Zero Trust

Create a service token and its Access policy, save both headers under Site Protection, and the next run loads the app.