Context
In #120 (Astro 6 upgrade), we dropped `@astrojs/cloudflare` instead of bumping to v13. The reason: v13 of the adapter removes Cloudflare Pages support entirely (Workers-only), and since this project is `output: 'static'` and deploys via git → Pages, the adapter was effectively vestigial — no `Astro.locals.runtime`, no KV/R2/D1, no bindings.
Why revisit later
Cloudflare's investment direction is Workers (with Static Assets) over Pages. Migrating would let us:
- Add SSR routes (e.g. a contact-form endpoint) without re-adding a build-time adapter.
- Use server-side image transformation via the `cloudflare-binding` image service.
- Use bindings (KV, D1, R2) if any future feature needs them.
- Get dev-server runtime parity via `workerd`.
Cost
- Add a `wrangler.jsonc` to the repo.
- Re-add `@astrojs/cloudflare` (v13+).
- Move the deploy from Pages → Workers (custom-domain route to `cadamsmith.dev`, env vars on the Workers side, build pipeline change).
When to do this
When there's a concrete feature that needs SSR or a Cloudflare binding. Until then, the static-on-Pages setup is simpler and the equivalent UX for visitors.
Context
In #120 (Astro 6 upgrade), we dropped `@astrojs/cloudflare` instead of bumping to v13. The reason: v13 of the adapter removes Cloudflare Pages support entirely (Workers-only), and since this project is `output: 'static'` and deploys via git → Pages, the adapter was effectively vestigial — no `Astro.locals.runtime`, no KV/R2/D1, no bindings.
Why revisit later
Cloudflare's investment direction is Workers (with Static Assets) over Pages. Migrating would let us:
Cost
When to do this
When there's a concrete feature that needs SSR or a Cloudflare binding. Until then, the static-on-Pages setup is simpler and the equivalent UX for visitors.