[wrangler] Add enabled and previews_enabled options for custom domains#13222
Conversation
🦋 Changeset detectedLatest commit: 55ea49b The changes in this PR will be included in the next version bump. Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
create-cloudflare
@cloudflare/kv-asset-handler
miniflare
@cloudflare/pages-shared
@cloudflare/unenv-preset
@cloudflare/vite-plugin
@cloudflare/vitest-pool-workers
@cloudflare/workers-editor-shared
wrangler
commit: |
…stom domains Add support for configuring production_enabled and previews_enabled on custom domain routes, allowing users to control whether a custom domain serves production and/or preview traffic. These optional boolean fields can be set on any route with custom_domain: true and are passed through to the custom domains API origins payload during deploy.
maxwellpeterson
force-pushed
the
mpeterson/custom-domain-preview-production-settings
branch
from
0760be1 to
b44d762
Compare
workers-devprod
requested review from
a team and
penalosa
and removed request for
a team
|
Codeowners approval required for this PR:
Show detailed file reviewers
|
![devin-ai-integration[bot]](https://avatars.githubusercontent.com/in/811515?s=60&v=4){kind=small}
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
The refactored isValidRouteValue logic accepted { pattern, zone_id,
zone_name } because both keys were recognized and the count matched.
Add an explicit mutual exclusion check to restore the previous behavior
where this combination was correctly rejected.
| custom_domain?: boolean; | ||
| }; | ||
| export type CustomDomainRoute = { pattern: string; custom_domain: boolean }; | ||
| export type CustomDomainRoute = { |
There was a problem hiding this comment.
Is putting this in the custom domain route type set in stone? Long term I think something like the following would be clearer and would get away from locking us in to these config shapes just because we've previously had them:
routes: [{
type: "preview",
pattern: "*.example.com"
},{
type: "custom_domain",
pattern: "example.com"
}]In the meantime, what about:
routes: [{
preview: true,
pattern: "*.example.com"
},{
custom_domain: true,
pattern: "example.com"
}]There was a problem hiding this comment.
Previews are only supported for custom domains. I don't really see us adding them to regular routes in the future, since routes can already contain wildcards and there isn't a clear domain hierarchy to differentiate previews.
It's a little confusing to me to have separate "types" for custom_domain and previews, when they are actually the exact same thing at the API level. @1000hz has proposed a simplified domains API that would lend itself to this config shape:
{
"domains": ["app.example.com", "my-app.cloudflare.app"],
"preview_domains": ["previews.example.com", "my-app.cloudflare.app"]
{which feels a lot simpler since users don't need to be aware of the different underlying route types. Regardless, do we want to make this config shape change now?
As-is adopting previews for existing users is as simple as adding "previews_enabled": true to their domain config. The wildcard syntax would be a Wrangler-only construct and isn't something users would be familiar with from any other touchpoint (dash, API, Terraform, etc.). The only place you would see it is in the actual DNS record that is created, which we're trying to abstract over here.
The API field was renamed from production_enabled to enabled. Update all type definitions, validation, config mapping, deploy logic, and tests to match.
maxwellpeterson
changed the title
4 participants
Fixes IAC-402
Add support for configuring enabled and previews_enabled on custom domain routes, allowing users to control whether a custom domain serves production and/or preview traffic. These optional boolean fields can be set on any route with
custom_domain: trueand are passed through to the custom domains API during deploy. When omitted, the API defaults to production-only for backwards compatibility. Users must explicitly opt-in to preview routing by settingpreviews_enabled: true.Examples
Production-only
The default when both
enabledandpreviews_enabledare omitted. Only requests to example.com will be routed to the Worker.{ "pattern": "example.com", "custom_domain": true } // OR { "pattern": "example.com", "custom_domain": true, "enabled": true } // OR { "pattern": "example.com", "custom_domain": true, "previews_enabled": false } // OR { "pattern": "example.com", "custom_domain": true, "enabled": true, "previews_enabled": false }Previews-only
Requests to example.com will not be routed to the Worker. Requests to subdomains of example.com (e.g. my-feature.example.com) will be routed to the corresponding preview if one exists.
{ "pattern": "example.com", "custom_domain": true, "enabled": false, "previews_enabled": true }Production and previews
Requests to example.com will be routed to the Worker. Requests to subdomains of example.com (e.g. my-feature.example.com) will be routed to the corresponding preview if one exists.
{ "pattern": "example.com", "custom_domain": true, "previews_enabled": true } // OR { "pattern": "example.com", "custom_domain": true, "enabled": true, "previews_enabled": true }Invalid (API returns validation error)
At least one of production or previews must be enabled.
{ "pattern": "example.com", "custom_domain": true, "enabled": false } // OR { "pattern": "example.com", "custom_domain": true, "enabled": false, "previews_enabled": false }A picture of a cute animal (not mandatory, but encouraged)