Readiness probe can't pass Access on a Custom-Domain-only Worker

Start in packages/deploy-cloudflare/src/version.ts at the readiness probe and guardedReadinessHeaders locations cited in the issue; compare the staged custom-route and first-deploy bootstrap paths with the existing test that prevents credentials from leaking to custom routes. Decide how the probe can authenticate safely for a Custom-Domain-only Worker, then add coverage for that behavior. Done means staged deploys can verify readiness with the intended Access setup while preserving the existing credential-scope protections.

Thanks for Void! I ran into what looks like a gap in the staged deploy flow.

Summary

If a Worker is served only on a Custom Domain behind Cloudflare Access (workers_dev: false, preview_urls: false), a staged void deploy can't pass the readiness probe. Access credentials are only sent to workers.dev hosts, so Access blocks the probe and the deploy rolls back. The error suggests setting CF_ACCESS_CLIENT_ID / CF_ACCESS_CLIENT_SECRET, but on this path they aren't sent.

Use case

I'm deploying an internal dashboard that only staff should reach. All our internal tools live under *.internal.example.com, and one wildcard Access application in front of that hostname applies the same SSO policy to every tool. The app also checks the Access JWT's audience, so it only trusts that one application.

I turned off workers_dev and preview_urls so the Worker has exactly one way in. A workers.dev URL is outside the wildcard. It would need its own Access application, with a second policy to keep in sync and a different audience for the app to accept. Without one, the app is public. Cloudflare recommends a route or Custom Domain over workers.dev for production Workers, so this seemed like the expected setup.

Repro

// void.config.ts
export default defineConfig({
  cloudflare: {
    routes: [{ pattern: 'dashboard.internal.example.com', custom_domain: true }],
    workers_dev: false,
    preview_urls: false,
  },
})

1. Protect *.internal.example.com with an Access application whose policy admits a service token.
2. Set CF_ACCESS_CLIENT_ID and CF_ACCESS_CLIENT_SECRET to that token.
3. Run void deploy --platform cloudflare on a Worker that already has a deployed version.

deploy: Cloudflare Access blocked the uploaded Worker Version readiness probe.
For CI, set CF_ACCESS_CLIENT_ID and CF_ACCESS_CLIENT_SECRET to an admitted service token.

The same credentials work when sent manually:

curl -H "CF-Access-Client-Id: $CF_ACCESS_CLIENT_ID" \
     -H "CF-Access-Client-Secret: $CF_ACCESS_CLIENT_SECRET" \
     https://dashboard.internal.example.com/__void/ready
# {"ready":true,"versionId":"..."}

What I found

With no preview URL, activateCloudflareVersion stages the new version at 0% and probes the custom route with Cloudflare-Workers-Version-Overrides, but leaves the Access headers off:

• version.ts#L1340: readinessUsesCustomRoute ? undefined : options.readinessHeaders
• version.ts#L2492: guardedReadinessHeaders only accepts <worker>.<subdomain>.workers.dev
• The first-deploy bootstrap path does the same: version.ts#L2126

This looks intentional. 6ea0b4699 added a test asserting the headers are not sent to a custom route ('must-not-leak'), which makes sense, since a route hostname isn't guaranteed to reach this Worker. The side effect is that a Custom-Domain-only Worker has no hostname where the probe can authenticate.

Workaround: --atomic (or deploy.cloudflare.mode: "atomic"). It deploys, but skips the pre-traffic check and exits with "the atomic Worker deployment is live, but /__void/ready could not be verified".

Possible directions

Not sure which fits Void's security model best, so here are the options I could see:

1. Opt-in origin. Let the user name one origin that may receive the readiness credentials, similar to how VOID_ACCESS_ORIGIN scopes platform credentials. With nothing set, the current behavior stays the same.
2. Custom Domains automatically. Send the headers when the probe host comes from a custom_domain: true route. One caveat: per Cloudflare's docs, a Route on the same hostname takes precedence over a Custom Domain, so this may need a route check first.
3. Error message only. For a custom-route probe, point to --atomic instead of CF_ACCESS_CLIENT_*.

Happy to put together a PR if one of these sounds right.

void 1.2.1, @void/deploy-cloudflare 1.2.1. The same code is still on main (246e186, after v1.3.0).