Cloudflare website builds

Use this guide after mapping the CMS website. These steps apply when Cloudflare hosts the frontend; DynoStatic itself can stay on ordinary PHP hosting. Confirm the actual account, project, repository and branch before changing configuration. Provider screens and limits can change: check the linked official documentation for the account in use.

Connect one publishing path

The intended flow is DynoStatic publication → website webhook → Cloudflare deploy hook → fresh CMS fetch → static build → Worker deployment. Workers Builds needs a connected Git repository and a deploy hook for the intended branch. The hook URL itself grants build access; store it in DynoStatic's website webhook settings, not in source control or a public receipt. A direct Cloudflare deploy hook does not require an additional custom HMAC receiver. See Workers deploy hooks.

Connect the provider's Git integration to the actual repository owner. If the repository moves to an organization, verify installed-app access and the new repository/branch binding, then confirm the next build uses that source. An old Git redirect is not proof that the provider connection has moved. A repository transfer or new hosting account is conditional work, not a prerequisite for CMS use.

DynoStatic's installation Cloudflare cache integration is separate from the frontend's repository/build connection. Creating a website webhook does not provision GitHub access or a Worker. Use the installed administration controls for what they support; complete provider-only settings in the provider dashboard. An interactive credential able to deploy Workers may lack Builds API permission. Report the specific missing permission rather than adding a competing CI system.

Keep build and runtime configuration separate

Cloudflare separates Build Variables and Secrets from runtime Variables & Secrets. A CMS token entered only as a runtime secret is not sufficient for a build-time fetch. Keep the configured build command inclusive of CMS synchronization, for example npm run build when prebuild performs the fetch. Verify the exact root directory and deploy command against the repository. See build configuration.

Pin a Node version compatible with the project's Astro/dependency versions using NODE_VERSION, .node-version or .nvmrc. Without a pin, the provider uses its build-image default, which can change. Node is a frontend build dependency, not a requirement on the PHP CMS host. Do not copy another site's historical version number blindly. See build-image overrides.

Build caching can reuse dependency and framework work. Keep fresh CMS fetching and validation mandatory on every build; cached content is not a fallback when the CMS fetch fails. Record whether caching was actually enabled rather than treating a recommendation as a completed setting. See build caching.

If moving from Pages to Workers

A hosting migration is optional and requires the owner's scope. For an already static Astro site with a few API handlers, Workers Static Assets can retain the static frontend and a native Worker entry. Configure the built directory as assets with an ASSETS binding, preserve the existing API handlers, and replace Pages-specific deployment configuration. An SSR rewrite is not inherently required. See Pages-to-Workers migration.

Route /api/* through the Worker before static assets. Preserve trailing-slash behavior, custom 404s, _headers, _redirects, canonical-host redirects and query strings, checking any rules handled by Worker code separately. Return real API errors rather than serving an HTML fallback for failed API requests. Update the repository's deploy commands and hosting instructions together.

Assets uploaded with the Worker, including optimized CMS photographs downloaded during the build, are served and cached through Cloudflare's network. Remote DynoStatic image URLs remain remote URLs; embedding a gallery alone does not upload its images. See Static Assets.

Verify the workers.dev deployment before switching the live hostname. Existing Pages secrets do not automatically move. Have the owner enter missing runtime secrets through the new Worker's secret controls; never extract them through a public endpoint or disable Turnstile to make a preview succeed.

Pages-managed DNS can conflict with a Worker Custom Domain. Inspect the actual provider mutation result, not just a preview. Where suitable and authorized, a Worker route over existing proxied DNS can serve the site's assets/API while DNS retirement remains pending. Do not remove the proxied record while relying on that route. Keep the working domain until the replacement is verified; old Pages project retirement is a separate cleanup decision. See Worker routes.

Pages Direct Upload and Git-integrated projects have different capabilities. Do not assume a Direct Upload project can be switched to Git integration in place. Retain external CI or arrange an authorized replacement if needed. See Pages Direct Upload.

Enable and verify publishing

Enable the selected website's webhook after bulk import. Subscribe to the content events consumed by the adapter, including translation publications for multilingual forms. Verify timely DynoStatic job execution, the final Cloudflare build result, and the deployed artifact after an authorized real publication.

Keep only one active deployment path for that site. Do not enable an alternative GitHub Actions receiver while the direct provider hook is already the chosen path. If a custom receiver is necessary, verify DynoStatic's signature and website, dispatch only a fixed authorized repository/branch, and make retries safe.

A Git push, accepted webhook or successful local build is not proof of updated public content. Compare a live page or credential-free capture receipt with the new publication. Record any unverified cron schedule, caching toggle, provider access or remaining DNS/Pages cleanup as pending.