Cloudflare Workers · Wrangler · all subjects

advanced configuration

12 notes, read out of this brain and free to use. Each one was extracted from a source and is re-checked against its exam.

Custom Domains definition and purpose

Custom Domains allow you to connect a Worker to a domain or subdomain without making changes to DNS settings or performing certificate management. Cloudflare creates DNS records and issues certificates automatically. The created DNS records point directly to the Worker. Unlike Routes, Custom Domains point all paths of a domain or subdomain to the Worker.

Custom Domains stacking and fetch communication

Custom Domains can stack on top of each other. For example, if Worker A is attached to app.example.com and Worker B is attached to api.example.com, Worker A can call fetch() on api.example.com to invoke Worker B. Custom Domains can also be invoked within the same zone via fetch(), unlike Routes.

Custom Domains certificate generation

Creating a Custom Domain generates an Advanced Certificate on the target zone for the target hostname with default settings. When you delete a Custom Domain, the associated Advanced Certificate is not automatically deleted and must be manually removed from the Cloudflare dashboard under SSL/TLS > Edge Certificates or via the API.

Custom Domains exact hostname matching

Custom Domains require an exact hostname match. A Worker attached to example.com will not receive requests sent to www.example.com, and vice versa. To make both versions work, set up a redirect rule and add a proxied DNS record for the hostname being redirected from.

Custom Domains do not support wildcard DNS

Custom Domains do not support wildcard DNS records. An incoming request must exactly match the domain or subdomain the Custom Domain is registered to. Other parts like path and query parameters are not considered in matching logic.

Custom Domain interaction with Routes

A Worker running on a Custom Domain is treated as an origin. Workers running on routes before the Custom Domain can optionally call the Custom Domain Worker by issuing fetch(request) with the incoming Request object. This allows chaining two Workers in the same request.

Worker to Worker communication on same zone with Custom Domains

On the same zone, if a Worker attempts to communicate with a target Worker running on a Custom Domain rather than a route or workers.dev subdomain, the limitation requiring service bindings is removed. Fetch requests sent from one Worker to another Worker running on a Custom Domain will succeed without a service binding.

Custom Domains prerequisites

To add a Custom Domain, you must have an active Cloudflare zone and a Worker to invoke. You cannot create a Custom Domain on a hostname with an existing CNAME DNS record or on a zone you do not own.

Custom Domains with Cloudflare Access

To require visitors to sign in before accessing a Custom Domain, use Cloudflare Access. You can protect a Custom Domain with hostname-based Access, or protect the Worker itself across its routes, Custom Domains, workers.dev hostname, and previews.

Custom Domains www redirect example

For www to root redirect, add a proxied DNS A record for www pointing to 192.0.2.0, or a proxied AAAA record pointing to 100::. For root to www redirect, add a proxied DNS A record for the root domain pointing to 192.0.2.0, or a proxied AAAA record pointing to 100::. These are reserved placeholder addresses for originless setups.

Migrate route to Custom Domain via Wrangler

To migrate a route example.com/* to a Custom Domain in wrangler.toml: delete the CNAME record for example.com in DNS Records, add { "routes": [ { "pattern": "example.com", "custom_domain": true } ] } to wrangler.toml, run npx wrangler deploy to create the Custom Domain, then delete the old route from Worker settings.

Automatic resource provisioning

Wrangler can automatically provision resources for you when you deploy your Worker without you having to create them ahead of time. This currently works for: KV, R2, D1, Flagship, AI Search, Agent Memory, Dispatch Namespaces and Queues. To use this feature, add bindings to your configuration file without adding resource IDs, or in the case of R2, a bucket name. Resources will be created with the name of your worker as the prefix. When you run wrangler dev, local resources will automatically be created which persist between runs. When you run wrangler deploy, resources will be created for you, and their IDs will be written back to your configuration file.

Give your agent this brain