Access control

Find the Team domain

If this Cloudflare account has never used Zero Trust, Cloudflare shows a short first-time setup before the normal Access screens:

1. On the Welcome to Cloudflare Zero Trust page, select Get started
2. On Choose a plan, select Zero Trust Free unless you deliberately need a paid plan
3. On Activate Zero Trust Free, review the order summary, authorize the plan terms, then select Activate

Cloudflare may ask for or confirm a payment method even when the plan is free; keep the plan on Zero Trust Free unless your organization requires otherwise. You only see this first-time setup once.

After activation, open Zero Trust > Settings, then:

Copy the Team domain.

The installer stores it in wrangler.toml during npm run setup:

[vars]
CF_ACCESS_TEAM_DOMAIN = "vanityurls.cloudflareaccess.com"

This value is not a secret, but it must match the Cloudflare account that owns the Access application.

Choose the identity provider

For phase 1, use one-time PIN unless you already have a provider ready. For provider strategy, read Choosing an Identity Provider.

If you enable multiple providers, users choose one on the Cloudflare Access login page. The policy succeeds when the selected provider returns an identity that matches the policy.

Create the Access application

In Cloudflare, open Zero Trust > Access Controls > Applications, then:

1. Create an application
2. Select Self-hosted and private
3. Continue with Self-hosted and private

Use one Access application for the private vanityURLs operations. Public redirect paths should stay outside Access so visitors can follow short links without logging in.

Recommended settings:

Configure these destinations with your short domain:

Cloudflare Access supports wildcards in the path field. The */_stats entries cover localized dashboard paths such as /en/_stats/ and /fr/_stats/ while leaving ordinary public short links outside Access.

Create the Access policy

Start with a simple allow policy:

Use the policy tester before saving. Test one allowed email address and one address that should be denied.

For a larger team, prefer a maintained group or IdP selector over a long list of individual email addresses.

Store the Access audience

After the application is created, open Additional settings and copy the Application Audience (AUD) Tag.

Store it as a Worker secret:

npx wrangler secret put CF_ACCESS_AUD --config wrangler.toml

Validate the protection

Before release:

1. Use the Cloudflare policy tester to confirm an allowed identity succeeds
2. Use the policy tester to confirm a denied identity fails
3. Visit /en/_stats/ from a signed-out or private browser profile
4. Visit one other localized stats path, for example /fr/_stats/
5. Visit /_tests from a signed-out or private browser profile
6. Confirm Cloudflare Access appears before the dashboard or test page
7. Sign in with an allowed identity and confirm the page loads

Run the local checks before pushing configuration changes:

npm run check

After deployment, repeat the signed-out browser test against the real short domain.

For your information: Cloudflare Access is not the only layer that limits operational file access. For the complete guard table, read Runtime security. For ongoing review, read Operating Cloudflare Access for a short-link domain.

Keep controlled access on localized stats paths such as /en/_stats/ and /fr/_stats/, plus /_tests, the _headers runtime-file entries, and the Worker runtime-file guard enabled unless you have a deliberate public-disclosure reason. This is a design note, not a separate setup activity.