Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

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

Open
  • Is something wrong?
#619 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
48/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
typescript
Domain
devops

Research direction

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.

Written by the indexing model from the issue text.

Description

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:

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).

Dominant language
TypeScript
Stars
580
Forks
56
Avg merge
11h 32m
Merged PRs (30d)
158

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from voidzero-dev/void

All issues in voidzero-dev/void

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.