From cce365b4e35abda50c558981839505247667ccb9 Mon Sep 17 00:00:00 2001 From: Pete Bacon Darwin Date: Fri, 22 May 2026 15:38:50 +0100 Subject: [PATCH 01/19] [Workers] Document Access Service Auth setup for remote bindings --- .../workers/development-testing/index.mdx | 46 ++++++++++++++++++- .../wrangler/system-environment-variables.mdx | 4 +- 2 files changed, 47 insertions(+), 3 deletions(-) diff --git a/src/content/docs/workers/development-testing/index.mdx b/src/content/docs/workers/development-testing/index.mdx index d818b1cbe1a..38aaaf457b3 100644 --- a/src/content/docs/workers/development-testing/index.mdx +++ b/src/content/docs/workers/development-testing/index.mdx @@ -18,6 +18,7 @@ import { InlineBadge, CardGrid, Card, + Steps, Type, TypeScriptExample, } from "~/components"; @@ -306,7 +307,50 @@ There are two recommended patterns for this: - **Network latency**: Expect network latency for operations on these remotely connected bindings, as they involve communication over the internet. -- **CI and non-interactive environments**: If your worker uses [Cloudflare Access](/cloudflare-one/), Wrangler must authenticate with Access when connecting to remote bindings. In non-interactive environments such as CI/CD pipelines, set the `CLOUDFLARE_ACCESS_CLIENT_ID` and `CLOUDFLARE_ACCESS_CLIENT_SECRET` [system environment variables](/workers/wrangler/system-environment-variables/) to authenticate using an [Access Service Token](/cloudflare-one/access-controls/service-credentials/service-tokens/). Without these variables, Wrangler throws an error instead of launching the interactive `cloudflared access login` flow. +- **Cloudflare Access**: If your Worker is protected by [Cloudflare Access](/cloudflare-one/), Wrangler must authenticate with Access when connecting to remote bindings. See [Connecting to Access-protected Workers](#connecting-to-access-protected-workers). + +### Connecting to Access-protected Workers + +If your Worker is deployed behind a [Cloudflare Access](/cloudflare-one/) application — for example, if the `*.workers.dev` subdomain on your account is protected by Access, or if you have placed an Access policy on the Worker's custom route — Wrangler must authenticate with Access when connecting to your remote bindings. + +There are two ways Wrangler authenticates against Access: + +- **Interactive login** (local development): When you run a command that uses remote bindings on your own machine, Wrangler launches the interactive `cloudflared access login` flow in your browser. No additional setup is required beyond being signed in to the correct account. + +- **Service token** (CI / non-interactive environments): In CI/CD pipelines and other non-interactive contexts there is no browser available, so Wrangler authenticates with a [Cloudflare Access service token](/cloudflare-one/access-controls/service-credentials/service-tokens/) instead. If you do not configure a service token in a non-interactive environment, Wrangler will throw an error rather than attempting the interactive flow. + +To set up service token authentication: + + + +1. **Add a Service Auth policy to the Access application that protects your Worker.** + + Open the _existing_ Access application that already covers the Worker's hostname — typically the wildcard application for `*..workers.dev`, or the application that protects your custom domain — and attach a new policy with: + - **Action**: Service Auth + - **Include**: "Any Access Service Token", or a specific service token + + :::caution + Do not create a _separate_ Access application scoped only to the Worker's hostname. Doing so has been observed to block requests even when the existing wildcard application is left in place — see [opennextjs-cloudflare#1171](https://github.com/opennextjs/opennextjs-cloudflare/issues/1171). Attach the Service Auth policy to the existing application that already protects the hostname. + ::: + +2. **Create a service token.** + + In the Cloudflare dashboard, go to **Zero Trust** → **Access** → **Service Auth** → **Service Tokens** and create a new token. See [Service tokens](/cloudflare-one/access-controls/service-credentials/service-tokens/) for the full reference. You will be shown a Client ID and a Client Secret — save them somewhere safe, as the secret is not shown again. + +3. **Expose the credentials to Wrangler.** + + Set the `CLOUDFLARE_ACCESS_CLIENT_ID` and `CLOUDFLARE_ACCESS_CLIENT_SECRET` [system environment variables](/workers/wrangler/system-environment-variables/) in the environment that runs Wrangler: + + ```sh + export CLOUDFLARE_ACCESS_CLIENT_ID= + export CLOUDFLARE_ACCESS_CLIENT_SECRET= + ``` + + In CI, store the values as secrets and expose them as environment variables to the step that runs Wrangler. + + + +When both environment variables are set, Wrangler uses them to authenticate against Access regardless of the rest of the application's policies — including Access applications configured to only accept Service Auth tokens. ### API diff --git a/src/content/docs/workers/wrangler/system-environment-variables.mdx b/src/content/docs/workers/wrangler/system-environment-variables.mdx index 43282327c7b..eb2f07fbd38 100644 --- a/src/content/docs/workers/wrangler/system-environment-variables.mdx +++ b/src/content/docs/workers/wrangler/system-environment-variables.mdx @@ -50,10 +50,10 @@ Wrangler supports the following environment variables: - The email address associated with your Cloudflare account, usually used for older authentication method with `CLOUDFLARE_API_KEY=`. - `CLOUDFLARE_ACCESS_CLIENT_ID` - - The Client ID of a [Cloudflare Access Service Token](/cloudflare-one/access-controls/service-credentials/service-tokens/), used to authenticate with Access-protected domains in non-interactive environments such as CI/CD pipelines. Must be set together with `CLOUDFLARE_ACCESS_CLIENT_SECRET`. When both variables are set, Wrangler authenticates using the service token instead of launching `cloudflared access login`. + - The Client ID of a [Cloudflare Access Service Token](/cloudflare-one/access-controls/service-credentials/service-tokens/), used to authenticate with Access-protected domains in non-interactive environments such as CI/CD pipelines. Must be set together with `CLOUDFLARE_ACCESS_CLIENT_SECRET`. When both variables are set, Wrangler authenticates using the service token instead of launching `cloudflared access login`. For the full Access policy and service token setup, see [Connecting to Access-protected Workers](/workers/development-testing/#connecting-to-access-protected-workers). - `CLOUDFLARE_ACCESS_CLIENT_SECRET` - - The Client Secret of a [Cloudflare Access Service Token](/cloudflare-one/access-controls/service-credentials/service-tokens/), used together with `CLOUDFLARE_ACCESS_CLIENT_ID` to authenticate with Access-protected domains in non-interactive environments. + - The Client Secret of a [Cloudflare Access Service Token](/cloudflare-one/access-controls/service-credentials/service-tokens/), used together with `CLOUDFLARE_ACCESS_CLIENT_ID` to authenticate with Access-protected domains in non-interactive environments. For the full Access policy and service token setup, see [Connecting to Access-protected Workers](/workers/development-testing/#connecting-to-access-protected-workers). - `CLOUDFLARE_ENV` - The [environment](/workers/wrangler/environments/) to use for Wrangler commands. This allows you to select an environment without using the `--env` flag. For example, `CLOUDFLARE_ENV=production wrangler deploy` will deploy to the `production` environment. The `--env` command line argument takes precedence over this environment variable. From bd215e2a6640a4607dffb93b1b1b02c40c3d226a Mon Sep 17 00:00:00 2001 From: Pete Bacon Darwin Date: Fri, 22 May 2026 16:27:35 +0100 Subject: [PATCH 02/19] Update src/content/docs/workers/development-testing/index.mdx Co-authored-by: ask-bonk[bot] <249159057+ask-bonk[bot]@users.noreply.github.com> --- src/content/docs/workers/development-testing/index.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/content/docs/workers/development-testing/index.mdx b/src/content/docs/workers/development-testing/index.mdx index 38aaaf457b3..a55a3979dd1 100644 --- a/src/content/docs/workers/development-testing/index.mdx +++ b/src/content/docs/workers/development-testing/index.mdx @@ -311,7 +311,7 @@ There are two recommended patterns for this: ### Connecting to Access-protected Workers -If your Worker is deployed behind a [Cloudflare Access](/cloudflare-one/) application — for example, if the `*.workers.dev` subdomain on your account is protected by Access, or if you have placed an Access policy on the Worker's custom route — Wrangler must authenticate with Access when connecting to your remote bindings. +If your Worker is deployed behind a [Cloudflare Access](/cloudflare-one/) application — for example, if the *.workers.dev subdomain on your account is protected by Access, or if you have placed an Access policy on the custom route of the Worker — Wrangler must authenticate with Access when connecting to your remote bindings. There are two ways Wrangler authenticates against Access: From b4840f1a6dd23c1c5b06c08fe3389fa338c32691 Mon Sep 17 00:00:00 2001 From: Pete Bacon Darwin Date: Fri, 22 May 2026 16:27:52 +0100 Subject: [PATCH 03/19] Update src/content/docs/workers/development-testing/index.mdx Co-authored-by: ask-bonk[bot] <249159057+ask-bonk[bot]@users.noreply.github.com> --- src/content/docs/workers/development-testing/index.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/content/docs/workers/development-testing/index.mdx b/src/content/docs/workers/development-testing/index.mdx index a55a3979dd1..367e68a5123 100644 --- a/src/content/docs/workers/development-testing/index.mdx +++ b/src/content/docs/workers/development-testing/index.mdx @@ -325,7 +325,7 @@ To set up service token authentication: 1. **Add a Service Auth policy to the Access application that protects your Worker.** - Open the _existing_ Access application that already covers the Worker's hostname — typically the wildcard application for `*..workers.dev`, or the application that protects your custom domain — and attach a new policy with: + Open the _existing_ Access application that already covers the hostname of the Worker — typically the wildcard application for `*..workers.dev`, or the application that protects your custom domain — and attach a new policy with: - **Action**: Service Auth - **Include**: "Any Access Service Token", or a specific service token From 1fdc1cc088e8f1f4d9b404dc5a7451e99e81aee7 Mon Sep 17 00:00:00 2001 From: Pete Bacon Darwin Date: Fri, 22 May 2026 16:28:07 +0100 Subject: [PATCH 04/19] Update src/content/docs/workers/development-testing/index.mdx Co-authored-by: ask-bonk[bot] <249159057+ask-bonk[bot]@users.noreply.github.com> --- src/content/docs/workers/development-testing/index.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/content/docs/workers/development-testing/index.mdx b/src/content/docs/workers/development-testing/index.mdx index 367e68a5123..63767ee74c2 100644 --- a/src/content/docs/workers/development-testing/index.mdx +++ b/src/content/docs/workers/development-testing/index.mdx @@ -335,7 +335,7 @@ To set up service token authentication: 2. **Create a service token.** - In the Cloudflare dashboard, go to **Zero Trust** → **Access** → **Service Auth** → **Service Tokens** and create a new token. See [Service tokens](/cloudflare-one/access-controls/service-credentials/service-tokens/) for the full reference. You will be shown a Client ID and a Client Secret — save them somewhere safe, as the secret is not shown again. + In the Cloudflare dashboard, go to **Zero Trust** > **Access** > **Service Auth** > **Service Tokens** and create a new token. See [Service tokens](/cloudflare-one/access-controls/service-credentials/service-tokens/) for the full reference. You will be shown a Client ID and a Client Secret — save them somewhere safe, as the secret is not shown again. 3. **Expose the credentials to Wrangler.** From e1fe684540c93a81108a3471874db7644fb79002 Mon Sep 17 00:00:00 2001 From: Pete Bacon Darwin Date: Fri, 22 May 2026 16:28:27 +0100 Subject: [PATCH 05/19] Update src/content/docs/workers/development-testing/index.mdx Co-authored-by: ask-bonk[bot] <249159057+ask-bonk[bot]@users.noreply.github.com> --- src/content/docs/workers/development-testing/index.mdx | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/content/docs/workers/development-testing/index.mdx b/src/content/docs/workers/development-testing/index.mdx index 63767ee74c2..14b778aa642 100644 --- a/src/content/docs/workers/development-testing/index.mdx +++ b/src/content/docs/workers/development-testing/index.mdx @@ -342,8 +342,8 @@ To set up service token authentication: Set the `CLOUDFLARE_ACCESS_CLIENT_ID` and `CLOUDFLARE_ACCESS_CLIENT_SECRET` [system environment variables](/workers/wrangler/system-environment-variables/) in the environment that runs Wrangler: ```sh - export CLOUDFLARE_ACCESS_CLIENT_ID= - export CLOUDFLARE_ACCESS_CLIENT_SECRET= + export CLOUDFLARE_ACCESS_CLIENT_ID= + export CLOUDFLARE_ACCESS_CLIENT_SECRET= ``` In CI, store the values as secrets and expose them as environment variables to the step that runs Wrangler. From 89991014d22f9b82524031dccb3f13958ca7a243 Mon Sep 17 00:00:00 2001 From: Pete Bacon Darwin Date: Fri, 22 May 2026 17:16:11 +0100 Subject: [PATCH 06/19] Update src/content/docs/workers/development-testing/index.mdx Co-authored-by: emily-shen <69125074+emily-shen@users.noreply.github.com> --- src/content/docs/workers/development-testing/index.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/content/docs/workers/development-testing/index.mdx b/src/content/docs/workers/development-testing/index.mdx index 14b778aa642..d34ed0a8b36 100644 --- a/src/content/docs/workers/development-testing/index.mdx +++ b/src/content/docs/workers/development-testing/index.mdx @@ -313,7 +313,7 @@ There are two recommended patterns for this: If your Worker is deployed behind a [Cloudflare Access](/cloudflare-one/) application — for example, if the *.workers.dev subdomain on your account is protected by Access, or if you have placed an Access policy on the custom route of the Worker — Wrangler must authenticate with Access when connecting to your remote bindings. -There are two ways Wrangler authenticates against Access: +There are two ways you can authenticate against Access: - **Interactive login** (local development): When you run a command that uses remote bindings on your own machine, Wrangler launches the interactive `cloudflared access login` flow in your browser. No additional setup is required beyond being signed in to the correct account. From fdc040d62b9034042b34c1cd69685d2fc3dd5146 Mon Sep 17 00:00:00 2001 From: Pete Bacon Darwin Date: Fri, 22 May 2026 17:18:12 +0100 Subject: [PATCH 07/19] Update src/content/docs/workers/development-testing/index.mdx Co-authored-by: devin-ai-integration[bot] <158243242+devin-ai-integration[bot]@users.noreply.github.com> --- src/content/docs/workers/development-testing/index.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/content/docs/workers/development-testing/index.mdx b/src/content/docs/workers/development-testing/index.mdx index d34ed0a8b36..84ccce78f97 100644 --- a/src/content/docs/workers/development-testing/index.mdx +++ b/src/content/docs/workers/development-testing/index.mdx @@ -311,7 +311,7 @@ There are two recommended patterns for this: ### Connecting to Access-protected Workers -If your Worker is deployed behind a [Cloudflare Access](/cloudflare-one/) application — for example, if the *.workers.dev subdomain on your account is protected by Access, or if you have placed an Access policy on the custom route of the Worker — Wrangler must authenticate with Access when connecting to your remote bindings. +If your Worker is deployed behind a [Cloudflare Access](/cloudflare-one/) application — for example, if the `*.workers.dev` subdomain on your account is protected by Access, or if you have placed an Access policy on the custom route of the Worker — Wrangler must authenticate with Access when connecting to your remote bindings. There are two ways you can authenticate against Access: From 69a948226c8f857f8794ad932fe3647346a5755b Mon Sep 17 00:00:00 2001 From: Pete Bacon Darwin Date: Fri, 22 May 2026 17:19:14 +0100 Subject: [PATCH 08/19] Do not use Gerund style headings --- src/content/docs/workers/development-testing/index.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/content/docs/workers/development-testing/index.mdx b/src/content/docs/workers/development-testing/index.mdx index 84ccce78f97..86023a42967 100644 --- a/src/content/docs/workers/development-testing/index.mdx +++ b/src/content/docs/workers/development-testing/index.mdx @@ -309,7 +309,7 @@ There are two recommended patterns for this: - **Cloudflare Access**: If your Worker is protected by [Cloudflare Access](/cloudflare-one/), Wrangler must authenticate with Access when connecting to remote bindings. See [Connecting to Access-protected Workers](#connecting-to-access-protected-workers). -### Connecting to Access-protected Workers +### Connect to Access-protected Workers If your Worker is deployed behind a [Cloudflare Access](/cloudflare-one/) application — for example, if the `*.workers.dev` subdomain on your account is protected by Access, or if you have placed an Access policy on the custom route of the Worker — Wrangler must authenticate with Access when connecting to your remote bindings. From f15cb381d3ee4a154de970981fc1e716f12b7fe3 Mon Sep 17 00:00:00 2001 From: Pete Bacon Darwin Date: Fri, 22 May 2026 17:23:21 +0100 Subject: [PATCH 09/19] fixup access steps --- .../docs/workers/development-testing/index.mdx | 14 ++++++-------- 1 file changed, 6 insertions(+), 8 deletions(-) diff --git a/src/content/docs/workers/development-testing/index.mdx b/src/content/docs/workers/development-testing/index.mdx index 86023a42967..59a38306660 100644 --- a/src/content/docs/workers/development-testing/index.mdx +++ b/src/content/docs/workers/development-testing/index.mdx @@ -323,20 +323,20 @@ To set up service token authentication: -1. **Add a Service Auth policy to the Access application that protects your Worker.** +1. **Create a service token.** + + In the Cloudflare dashboard, go to **Zero Trust** > **Access** > **Service Auth** > **Service Tokens** and create a new token. See [Service tokens](/cloudflare-one/access-controls/service-credentials/service-tokens/) for the full reference. You will be shown a Client ID and a Client Secret — save them somewhere safe, as the secret is not shown again. + +2. **Add a Service Auth policy to the Access application that protects your Worker.** Open the _existing_ Access application that already covers the hostname of the Worker — typically the wildcard application for `*..workers.dev`, or the application that protects your custom domain — and attach a new policy with: - **Action**: Service Auth - - **Include**: "Any Access Service Token", or a specific service token + - **Include**: The service token generated above, or "Any Access Service Token" if you want to allow any service token to access the Worker. :::caution Do not create a _separate_ Access application scoped only to the Worker's hostname. Doing so has been observed to block requests even when the existing wildcard application is left in place — see [opennextjs-cloudflare#1171](https://github.com/opennextjs/opennextjs-cloudflare/issues/1171). Attach the Service Auth policy to the existing application that already protects the hostname. ::: -2. **Create a service token.** - - In the Cloudflare dashboard, go to **Zero Trust** > **Access** > **Service Auth** > **Service Tokens** and create a new token. See [Service tokens](/cloudflare-one/access-controls/service-credentials/service-tokens/) for the full reference. You will be shown a Client ID and a Client Secret — save them somewhere safe, as the secret is not shown again. - 3. **Expose the credentials to Wrangler.** Set the `CLOUDFLARE_ACCESS_CLIENT_ID` and `CLOUDFLARE_ACCESS_CLIENT_SECRET` [system environment variables](/workers/wrangler/system-environment-variables/) in the environment that runs Wrangler: @@ -350,8 +350,6 @@ To set up service token authentication: -When both environment variables are set, Wrangler uses them to authenticate against Access regardless of the rest of the application's policies — including Access applications configured to only accept Service Auth tokens. - ### API Wrangler provides programmatic utilities to help tooling authors support remote binding connections when running Workers code with [Miniflare](/workers/testing/miniflare/). From 7c46b420db338fa7b77e106d715a5687a37ca7d6 Mon Sep 17 00:00:00 2001 From: Pete Bacon Darwin Date: Fri, 22 May 2026 17:25:01 +0100 Subject: [PATCH 10/19] fix internal link --- src/content/docs/workers/development-testing/index.mdx | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/content/docs/workers/development-testing/index.mdx b/src/content/docs/workers/development-testing/index.mdx index 59a38306660..f3058f4bd55 100644 --- a/src/content/docs/workers/development-testing/index.mdx +++ b/src/content/docs/workers/development-testing/index.mdx @@ -301,14 +301,14 @@ There are two recommended patterns for this: ### Important Considerations +- **Cloudflare Access**: If your Worker is protected by [Cloudflare Access](/cloudflare-one/), Wrangler must authenticate with Access when connecting to remote bindings. See [Connecting to Access-protected Workers](#connect-to-access-protected-workers). + - **Data modification**: Operations (writes, deletes, updates) on bindings connected remotely will affect your actual data in the targeted Cloudflare resource (be it preview or production). - **Billing**: Interactions with remote Cloudflare services through these connections will incur standard operational costs for those services (such as KV operations, R2 storage/operations, AI requests, D1 usage). - **Network latency**: Expect network latency for operations on these remotely connected bindings, as they involve communication over the internet. -- **Cloudflare Access**: If your Worker is protected by [Cloudflare Access](/cloudflare-one/), Wrangler must authenticate with Access when connecting to remote bindings. See [Connecting to Access-protected Workers](#connecting-to-access-protected-workers). - ### Connect to Access-protected Workers If your Worker is deployed behind a [Cloudflare Access](/cloudflare-one/) application — for example, if the `*.workers.dev` subdomain on your account is protected by Access, or if you have placed an Access policy on the custom route of the Worker — Wrangler must authenticate with Access when connecting to your remote bindings. From 605b78e88d6f33bd70e086245baed8be70c8acde Mon Sep 17 00:00:00 2001 From: Pete Bacon Darwin Date: Fri, 22 May 2026 17:25:52 +0100 Subject: [PATCH 11/19] fix cross page link --- .../docs/workers/wrangler/system-environment-variables.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/content/docs/workers/wrangler/system-environment-variables.mdx b/src/content/docs/workers/wrangler/system-environment-variables.mdx index eb2f07fbd38..e4a0e83f702 100644 --- a/src/content/docs/workers/wrangler/system-environment-variables.mdx +++ b/src/content/docs/workers/wrangler/system-environment-variables.mdx @@ -50,7 +50,7 @@ Wrangler supports the following environment variables: - The email address associated with your Cloudflare account, usually used for older authentication method with `CLOUDFLARE_API_KEY=`. - `CLOUDFLARE_ACCESS_CLIENT_ID` - - The Client ID of a [Cloudflare Access Service Token](/cloudflare-one/access-controls/service-credentials/service-tokens/), used to authenticate with Access-protected domains in non-interactive environments such as CI/CD pipelines. Must be set together with `CLOUDFLARE_ACCESS_CLIENT_SECRET`. When both variables are set, Wrangler authenticates using the service token instead of launching `cloudflared access login`. For the full Access policy and service token setup, see [Connecting to Access-protected Workers](/workers/development-testing/#connecting-to-access-protected-workers). + - The Client ID of a [Cloudflare Access Service Token](/cloudflare-one/access-controls/service-credentials/service-tokens/), used to authenticate with Access-protected domains in non-interactive environments such as CI/CD pipelines. Must be set together with `CLOUDFLARE_ACCESS_CLIENT_SECRET`. When both variables are set, Wrangler authenticates using the service token instead of launching `cloudflared access login`. For the full Access policy and service token setup, see [Connect to Access-protected Workers](/workers/development-testing/#connect-to-access-protected-workers). - `CLOUDFLARE_ACCESS_CLIENT_SECRET` - The Client Secret of a [Cloudflare Access Service Token](/cloudflare-one/access-controls/service-credentials/service-tokens/), used together with `CLOUDFLARE_ACCESS_CLIENT_ID` to authenticate with Access-protected domains in non-interactive environments. For the full Access policy and service token setup, see [Connecting to Access-protected Workers](/workers/development-testing/#connecting-to-access-protected-workers). From 8db952608f03c9d1a1094547ae011bfebebd3559 Mon Sep 17 00:00:00 2001 From: Pete Bacon Darwin Date: Fri, 22 May 2026 17:26:51 +0100 Subject: [PATCH 12/19] and one more --- .../docs/workers/wrangler/system-environment-variables.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/content/docs/workers/wrangler/system-environment-variables.mdx b/src/content/docs/workers/wrangler/system-environment-variables.mdx index e4a0e83f702..f0667da7c8d 100644 --- a/src/content/docs/workers/wrangler/system-environment-variables.mdx +++ b/src/content/docs/workers/wrangler/system-environment-variables.mdx @@ -53,7 +53,7 @@ Wrangler supports the following environment variables: - The Client ID of a [Cloudflare Access Service Token](/cloudflare-one/access-controls/service-credentials/service-tokens/), used to authenticate with Access-protected domains in non-interactive environments such as CI/CD pipelines. Must be set together with `CLOUDFLARE_ACCESS_CLIENT_SECRET`. When both variables are set, Wrangler authenticates using the service token instead of launching `cloudflared access login`. For the full Access policy and service token setup, see [Connect to Access-protected Workers](/workers/development-testing/#connect-to-access-protected-workers). - `CLOUDFLARE_ACCESS_CLIENT_SECRET` - - The Client Secret of a [Cloudflare Access Service Token](/cloudflare-one/access-controls/service-credentials/service-tokens/), used together with `CLOUDFLARE_ACCESS_CLIENT_ID` to authenticate with Access-protected domains in non-interactive environments. For the full Access policy and service token setup, see [Connecting to Access-protected Workers](/workers/development-testing/#connecting-to-access-protected-workers). + - The Client Secret of a [Cloudflare Access Service Token](/cloudflare-one/access-controls/service-credentials/service-tokens/), used together with `CLOUDFLARE_ACCESS_CLIENT_ID` to authenticate with Access-protected domains in non-interactive environments. For the full Access policy and service token setup, see [Connect to Access-protected Workers](/workers/development-testing/#connect-to-access-protected-workers). - `CLOUDFLARE_ENV` - The [environment](/workers/wrangler/environments/) to use for Wrangler commands. This allows you to select an environment without using the `--env` flag. For example, `CLOUDFLARE_ENV=production wrangler deploy` will deploy to the `production` environment. The `--env` command line argument takes precedence over this environment variable. From 1bf33c07a8fdee5890f0f5a08c865392ea09d158 Mon Sep 17 00:00:00 2001 From: Pete Bacon Darwin Date: Fri, 22 May 2026 17:34:55 +0100 Subject: [PATCH 13/19] clarified two modes of Access auth --- src/content/docs/workers/development-testing/index.mdx | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/content/docs/workers/development-testing/index.mdx b/src/content/docs/workers/development-testing/index.mdx index f3058f4bd55..38d07bb24f1 100644 --- a/src/content/docs/workers/development-testing/index.mdx +++ b/src/content/docs/workers/development-testing/index.mdx @@ -315,9 +315,9 @@ If your Worker is deployed behind a [Cloudflare Access](/cloudflare-one/) applic There are two ways you can authenticate against Access: -- **Interactive login** (local development): When you run a command that uses remote bindings on your own machine, Wrangler launches the interactive `cloudflared access login` flow in your browser. No additional setup is required beyond being signed in to the correct account. +- **Interactive login** (local development): If you have a policy defined that accepts user login, then Wrangler launches the interactive `cloudflared access login` flow in your browser. No additional setup is required beyond being signed in to the correct account. If the policy only allows service token authentication, Wrangler will skip the interactive flow and throw an error indicating that service token credentials are required. -- **Service token** (CI / non-interactive environments): In CI/CD pipelines and other non-interactive contexts there is no browser available, so Wrangler authenticates with a [Cloudflare Access service token](/cloudflare-one/access-controls/service-credentials/service-tokens/) instead. If you do not configure a service token in a non-interactive environment, Wrangler will throw an error rather than attempting the interactive flow. +- **Service token** (CI / non-interactive environments): In CI/CD pipelines and other non-interactive contexts, or where the policy only allows service token authentication, Wrangler cannot trigger the interactive flow via the browser. Authentication must be via a [Cloudflare Access service token](/cloudflare-one/access-controls/service-credentials/service-tokens/) instead. If you do not configure a service token in a non-interactive environment, Wrangler will throw an error rather than attempting the interactive flow. To set up service token authentication: From c3a67ec353b2a62a850e253f985ce5dbed12c016 Mon Sep 17 00:00:00 2001 From: Pete Bacon Darwin Date: Fri, 22 May 2026 17:35:53 +0100 Subject: [PATCH 14/19] Update src/content/docs/workers/wrangler/system-environment-variables.mdx Co-authored-by: devin-ai-integration[bot] <158243242+devin-ai-integration[bot]@users.noreply.github.com> --- .../docs/workers/wrangler/system-environment-variables.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/content/docs/workers/wrangler/system-environment-variables.mdx b/src/content/docs/workers/wrangler/system-environment-variables.mdx index f0667da7c8d..ba3757cad47 100644 --- a/src/content/docs/workers/wrangler/system-environment-variables.mdx +++ b/src/content/docs/workers/wrangler/system-environment-variables.mdx @@ -53,7 +53,7 @@ Wrangler supports the following environment variables: - The Client ID of a [Cloudflare Access Service Token](/cloudflare-one/access-controls/service-credentials/service-tokens/), used to authenticate with Access-protected domains in non-interactive environments such as CI/CD pipelines. Must be set together with `CLOUDFLARE_ACCESS_CLIENT_SECRET`. When both variables are set, Wrangler authenticates using the service token instead of launching `cloudflared access login`. For the full Access policy and service token setup, see [Connect to Access-protected Workers](/workers/development-testing/#connect-to-access-protected-workers). - `CLOUDFLARE_ACCESS_CLIENT_SECRET` - - The Client Secret of a [Cloudflare Access Service Token](/cloudflare-one/access-controls/service-credentials/service-tokens/), used together with `CLOUDFLARE_ACCESS_CLIENT_ID` to authenticate with Access-protected domains in non-interactive environments. For the full Access policy and service token setup, see [Connect to Access-protected Workers](/workers/development-testing/#connect-to-access-protected-workers). + - The Client Secret of a [Cloudflare Access Service Token](/cloudflare-one/access-controls/service-credentials/service-tokens/), used together with `CLOUDFLARE_ACCESS_CLIENT_ID` to authenticate with Access-protected domains in non-interactive environments. For the full Access policy and service token setup, refer to [Connect to Access-protected Workers](/workers/development-testing/#connect-to-access-protected-workers). - `CLOUDFLARE_ENV` - The [environment](/workers/wrangler/environments/) to use for Wrangler commands. This allows you to select an environment without using the `--env` flag. For example, `CLOUDFLARE_ENV=production wrangler deploy` will deploy to the `production` environment. The `--env` command line argument takes precedence over this environment variable. From cea8df0a2182cf616815a0e84ac8bd25ead33dfc Mon Sep 17 00:00:00 2001 From: Pete Bacon Darwin Date: Fri, 22 May 2026 17:36:19 +0100 Subject: [PATCH 15/19] Update src/content/docs/workers/development-testing/index.mdx Co-authored-by: devin-ai-integration[bot] <158243242+devin-ai-integration[bot]@users.noreply.github.com> --- src/content/docs/workers/development-testing/index.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/content/docs/workers/development-testing/index.mdx b/src/content/docs/workers/development-testing/index.mdx index 38d07bb24f1..a8d8f2cf9ac 100644 --- a/src/content/docs/workers/development-testing/index.mdx +++ b/src/content/docs/workers/development-testing/index.mdx @@ -301,7 +301,7 @@ There are two recommended patterns for this: ### Important Considerations -- **Cloudflare Access**: If your Worker is protected by [Cloudflare Access](/cloudflare-one/), Wrangler must authenticate with Access when connecting to remote bindings. See [Connecting to Access-protected Workers](#connect-to-access-protected-workers). +- **Cloudflare Access**: If your Worker is protected by [Cloudflare Access](/cloudflare-one/), Wrangler must authenticate with Access when connecting to remote bindings. Refer to [Connect to Access-protected Workers](#connect-to-access-protected-workers). - **Data modification**: Operations (writes, deletes, updates) on bindings connected remotely will affect your actual data in the targeted Cloudflare resource (be it preview or production). From 65a071d41209a0048cec1707fa95a3b9c35bc0ee Mon Sep 17 00:00:00 2001 From: Pete Bacon Darwin Date: Fri, 22 May 2026 17:39:14 +0100 Subject: [PATCH 16/19] Update src/content/docs/workers/development-testing/index.mdx Co-authored-by: devin-ai-integration[bot] <158243242+devin-ai-integration[bot]@users.noreply.github.com> --- src/content/docs/workers/development-testing/index.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/content/docs/workers/development-testing/index.mdx b/src/content/docs/workers/development-testing/index.mdx index a8d8f2cf9ac..06055d10077 100644 --- a/src/content/docs/workers/development-testing/index.mdx +++ b/src/content/docs/workers/development-testing/index.mdx @@ -325,7 +325,7 @@ To set up service token authentication: 1. **Create a service token.** - In the Cloudflare dashboard, go to **Zero Trust** > **Access** > **Service Auth** > **Service Tokens** and create a new token. See [Service tokens](/cloudflare-one/access-controls/service-credentials/service-tokens/) for the full reference. You will be shown a Client ID and a Client Secret — save them somewhere safe, as the secret is not shown again. + In the Cloudflare dashboard, go to **Zero Trust** > **Access** > **Service Auth** > **Service Tokens** and create a new token. Refer to [Service tokens](/cloudflare-one/access-controls/service-credentials/service-tokens/) for the full reference. You will be shown a Client ID and a Client Secret — save them somewhere safe, as the secret is not shown again. 2. **Add a Service Auth policy to the Access application that protects your Worker.** From 1a2263f672008003484bac5425a7e704bfa57dec Mon Sep 17 00:00:00 2001 From: Pete Bacon Darwin Date: Fri, 22 May 2026 17:39:34 +0100 Subject: [PATCH 17/19] Update src/content/docs/workers/wrangler/system-environment-variables.mdx Co-authored-by: devin-ai-integration[bot] <158243242+devin-ai-integration[bot]@users.noreply.github.com> --- .../docs/workers/wrangler/system-environment-variables.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/content/docs/workers/wrangler/system-environment-variables.mdx b/src/content/docs/workers/wrangler/system-environment-variables.mdx index ba3757cad47..303abfa91ab 100644 --- a/src/content/docs/workers/wrangler/system-environment-variables.mdx +++ b/src/content/docs/workers/wrangler/system-environment-variables.mdx @@ -50,7 +50,7 @@ Wrangler supports the following environment variables: - The email address associated with your Cloudflare account, usually used for older authentication method with `CLOUDFLARE_API_KEY=`. - `CLOUDFLARE_ACCESS_CLIENT_ID` - - The Client ID of a [Cloudflare Access Service Token](/cloudflare-one/access-controls/service-credentials/service-tokens/), used to authenticate with Access-protected domains in non-interactive environments such as CI/CD pipelines. Must be set together with `CLOUDFLARE_ACCESS_CLIENT_SECRET`. When both variables are set, Wrangler authenticates using the service token instead of launching `cloudflared access login`. For the full Access policy and service token setup, see [Connect to Access-protected Workers](/workers/development-testing/#connect-to-access-protected-workers). + - The Client ID of a [Cloudflare Access Service Token](/cloudflare-one/access-controls/service-credentials/service-tokens/), used to authenticate with Access-protected domains in non-interactive environments such as CI/CD pipelines. Must be set together with `CLOUDFLARE_ACCESS_CLIENT_SECRET`. When both variables are set, Wrangler authenticates using the service token instead of launching `cloudflared access login`. For the full Access policy and service token setup, refer to [Connect to Access-protected Workers](/workers/development-testing/#connect-to-access-protected-workers). - `CLOUDFLARE_ACCESS_CLIENT_SECRET` - The Client Secret of a [Cloudflare Access Service Token](/cloudflare-one/access-controls/service-credentials/service-tokens/), used together with `CLOUDFLARE_ACCESS_CLIENT_ID` to authenticate with Access-protected domains in non-interactive environments. For the full Access policy and service token setup, refer to [Connect to Access-protected Workers](/workers/development-testing/#connect-to-access-protected-workers). From b0bb9d199bbfcfd0ae336379a363c1b03f3370a0 Mon Sep 17 00:00:00 2001 From: Pete Bacon Darwin Date: Fri, 22 May 2026 17:39:56 +0100 Subject: [PATCH 18/19] Update src/content/docs/workers/development-testing/index.mdx Co-authored-by: devin-ai-integration[bot] <158243242+devin-ai-integration[bot]@users.noreply.github.com> --- src/content/docs/workers/development-testing/index.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/content/docs/workers/development-testing/index.mdx b/src/content/docs/workers/development-testing/index.mdx index 06055d10077..4b0dde2cf19 100644 --- a/src/content/docs/workers/development-testing/index.mdx +++ b/src/content/docs/workers/development-testing/index.mdx @@ -331,7 +331,7 @@ To set up service token authentication: Open the _existing_ Access application that already covers the hostname of the Worker — typically the wildcard application for `*..workers.dev`, or the application that protects your custom domain — and attach a new policy with: - **Action**: Service Auth - - **Include**: The service token generated above, or "Any Access Service Token" if you want to allow any service token to access the Worker. + - **Include**: The service token you created, or "Any Access Service Token" if you want to allow any service token to access the Worker. :::caution Do not create a _separate_ Access application scoped only to the Worker's hostname. Doing so has been observed to block requests even when the existing wildcard application is left in place — see [opennextjs-cloudflare#1171](https://github.com/opennextjs/opennextjs-cloudflare/issues/1171). Attach the Service Auth policy to the existing application that already protects the hostname. From 5822d4e3f936f187148123fbb05a3b444be3d834 Mon Sep 17 00:00:00 2001 From: Pete Bacon Darwin Date: Fri, 22 May 2026 18:02:42 +0100 Subject: [PATCH 19/19] Update src/content/docs/workers/development-testing/index.mdx Co-authored-by: devin-ai-integration[bot] <158243242+devin-ai-integration[bot]@users.noreply.github.com> --- src/content/docs/workers/development-testing/index.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/content/docs/workers/development-testing/index.mdx b/src/content/docs/workers/development-testing/index.mdx index 4b0dde2cf19..04bea8d1ca9 100644 --- a/src/content/docs/workers/development-testing/index.mdx +++ b/src/content/docs/workers/development-testing/index.mdx @@ -334,7 +334,7 @@ To set up service token authentication: - **Include**: The service token you created, or "Any Access Service Token" if you want to allow any service token to access the Worker. :::caution - Do not create a _separate_ Access application scoped only to the Worker's hostname. Doing so has been observed to block requests even when the existing wildcard application is left in place — see [opennextjs-cloudflare#1171](https://github.com/opennextjs/opennextjs-cloudflare/issues/1171). Attach the Service Auth policy to the existing application that already protects the hostname. + Do not create a _separate_ Access application scoped only to the Worker's hostname. Doing so has been observed to block requests even when the existing wildcard application is left in place — refer to [opennextjs-cloudflare#1171](https://github.com/opennextjs/opennextjs-cloudflare/issues/1171). Attach the Service Auth policy to the existing application that already protects the hostname. ::: 3. **Expose the credentials to Wrangler.**