docs: clarify Cloudflare Access setup in populate-cache comment#1267
Merged
Conversation
The previous comment said simply that 'the Application at open-next-cache-populate.<account>.workers.dev should have a policy'. That wording was reused verbatim in the v1.19.10 changelog entry and turned out to be ambiguous: several users read it as 'create a new Access application for that hostname' and ended up with an upload-blocking setup (see #1171). Restate the comment to reflect what actually works — attach the Service Auth policy to the existing Access application that already covers the hostname, typically the workers.dev wildcard — and link out to the docs section that covers the full procedure.
|
commit: |
james-elicx
approved these changes
May 15, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
packages/cloudflare/src/cli/commands/populate-cache.tsthat documents how theCLOUDFLARE_ACCESS_CLIENT_ID/CLOUDFLARE_ACCESS_CLIENT_SECRETenv vars are used.Why
The original comment (introduced in #1261) was reused verbatim in the v1.19.10 changelog and turned out to be ambiguous:
Multiple users in #1171 read this as "create a new Access application for that hostname" and ended up with a setup that blocks the upload. The user that eventually got it working in #1171 (comment) reported that the Service Auth policy needs to be attached to the existing Access application that already covers the hostname (typically the
*.<account>.workers.devwildcard). Creating a separate application for the helper-worker hostname was observed to block the upload even alongside the wildcard app.This PR restates the comment so the next maintainer who reads it (or copies it into a future changeset) reflects the working setup, and links out to the new docs section.
Notes
AGENTS.md(doc tweak — exempt).pnpm code:checksandpnpm --filter cloudflare test populate-cacheboth pass locally.