Cloudflare Workers Static Assets

Decision date: 2026-10-05. Status: superseded on 2026-10-05 by decision 007, following the owner-selected handbook Pages guide.

The remaining sections preserve the earlier Workers Static Assets decision and its rationale. They are historical, including the Workers Free/Billing Read and active-zone prerequisites; use the current Pages runbook for publication. Original Workers audit receipts remain unchanged under docs/website/audit/cloudflare/.

Context

The owner selected Cloudflare Workers Static Assets on the Free plan for the static documentation site, with target https://resilience-gate.devsatym.xyz and URL base /. The authoring repository remains private on GitHub. Astro + Starlight already produces prerendered HTML, static assets, a reviewed evidence gallery, and Pagefind search; serving those files requires no application backend.

The earlier GitHub Pages target and project-base hosting selection in decision 005 are superseded. Its centralized path handling and need to rebuild links/assets/search together remain valid. Historical audit evidence and the supplied brief retain their original configuration and outcomes.

Considered alternatives

GitHub Pages was the previous configured target, but private-repository eligibility had not been verified. Cloudflare Pages could also serve static output. Adding Astro SSR, a Worker request handler, KV/R2/D1, or an origin service would introduce capabilities and operational dependencies unnecessary for this publication. The owner’s selected deployment is Workers Static Assets with no application entrypoint or service bindings.

Decision

Serve the built site/dist/ tree through an assets-only Wrangler configuration. Set the public origin to https://resilience-gate.devsatym.xyz and default base to /, retain trailing-slash directory-index routes and native 404 behavior, and disable workers.dev and preview URLs. Keep Astro fully static and keep Pagefind in the output. Cloudflare documents this static-site serving model.

Keep GitHub Actions validation-only for PRs, main pushes, and manual checks. Publish solely through an explicit local guarded npm run deploy command. Separate local artifact/configuration checks, local asset preview, deployment dry run, authenticated account/ownership preflight, live upload, and strict HTTPS verification. No automatic push deploy, login, plan upgrade, nameserver migration, or replacement of unrelated DNS/domain/Worker ownership is authorized by this configuration.

Use the Workers Free plan and enforce static asset limits before upload. The configuration has no legacy usage_model key; actual account subscription state is checked read-only. Cloudflare’s asset billing and Free-plan limits establish the serving and size constraints, not proof that a particular account has been inspected.

Require an existing active, owner-controlled Cloudflare zone before binding the Custom Domain. The read-only inspection found the apex delegated to Spaceship and the target hostname absent. An owner-approved full-zone migration preserving existing records is a separate prerequisite; this task performs no DNS or nameserver migration. Cloudflare’s Custom Domain guidance defines the active-zone requirement and domain-managed DNS/certificate behavior.

Consequences

The publication remains static and can be reproduced without platform credentials or lab access. A private source repository does not make the website private. Updating root origin/base requires rebuilding canonical metadata, links, assets, and search together.

Account credentials, Free-plan verification, an active zone, and unused or correctly owned deployment resources are real prerequisites. A missing token, expired OAuth session, unsupported subscription state, incomplete inspection, or ownership collision blocks deployment rather than triggering automated repair. The owner completes login or separate zone preparation themselves.

Configuration is not deployment evidence. Actual local outcomes belong to docs/website/audit/cloudflare/local-checks.json; deployment and HTTPS verification status belong to publication-status.json in that directory. Previous monorepo and repository-separation receipts remain historical. The publication runbook records the executable sequence, owner actions, and stop conditions.