[Access] Protect Workers directly with Access applications#31243
[Access] Protect Workers directly with Access applications#31243kennyj42 wants to merge 4 commits into
Conversation
| - access | ||
| --- | ||
|
|
||
| Access applications now support [Worker destinations](/cloudflare-one/access-controls/applications/http-apps/worker-destinations/), a new way to protect Cloudflare Workers without managing URL-based routing patterns. Instead of matching hostname patterns and keeping Access applications in sync with Workers routes, you select the Worker directly and Access covers every route automatically. |
There was a problem hiding this comment.
This starts assuming you are coming from Access and also know what Access is
But when I think about who this reaches - it’s the person building with Workers - and reaching them and speaking to them well is what means more of them are like “oh Access is awesome”
Suggestion would be to orient around someone who has never heard of Access understanding first that they can protect their Worker, then that this is what Access is, and then that it is now way easier because…
| - A deployed [Cloudflare Worker](/workers/get-started/guide/) | ||
| - An active [Cloudflare One](/cloudflare-one/) plan | ||
|
|
||
| ## 1. Create a self-hosted application with a Worker destination |
There was a problem hiding this comment.
This is why I was asking about the wrangler piece in chat — if the message here is that you can protect Worekrs directly — but the steps towards doing so all hinge on starting within Access — then something feels off?
Seems like the pieces that we are talking about already wrt dash and CLI matter towards making this a really coherent thing that can ship?
|
Hey there, we've marked this pull request as stale because there's no recent activity on it. This label helps us identify PRs that might need updates (or to be closed out by our team if no longer relevant). |
What
Adds documentation for the Worker destinations feature (SHIP-14307), which lets customers protect a Cloudflare Worker behind Access by selecting the Worker directly instead of managing URL-based routing patterns.
Changes
New pages:
worker-destinations.mdx) -- full setup guide covering Dashboard and API flows, filtering, precedence rules, uniqueness constraints, limitations, and a comparison with hostname-based protectionUpdated pages:
choose-application-type.mdx-- expanded the Protecting Workers section with the three destination types and a link to the new how-tohttp-apps/index.mdx-- added Worker destinations to the application type listworkers/configuration/previews.mdx-- cross-reference note pointing to Worker destinations as an alternativeworkers/configuration/routing/workers-dev.mdx-- cross-reference note pointing to Worker destinations as an alternativeRelated