Cloudflare R2, D1, and Pages

Notes on using Cloudflare's storage, database, and frontend hosting pieces as a lightweight personal-site platform.

## Shape of the stack

Cloudflare Pages is useful for static or mostly static frontend deployment. R2 fits object storage, especially images and archives. D1 can hold relational metadata when the project does not justify a heavier database.

For this site, the natural split is:

- Pages for the public React frontend.
- R2 for long-lived media objects.
- D1 for small metadata indexes, publish state, and lookup tables.

## What to be careful about

The hard part is not making each service work once. The hard part is keeping deployment, credentials, cache invalidation, and migration paths simple enough that the site remains maintainable.

This connects directly to [[photography-archive-system]] because photo metadata and image delivery should not depend on fragile local folder structure forever. It also needs to fit the broader [[personal-website-as-operating-system|personal website operating system]] idea instead of becoming a separate infrastructure island.

## Next useful experiment

Build a tiny read-only index backed by D1, with image assets served from R2 and cached behind stable public URLs.

One missing note to create later: [[future-edge-cache-playbook|edge cache playbook]].

## Update Log
<!-- garden-auto:daily-maintenance 2026-06-18 -->
- 2026-06-18: Maintenance note added by Daily Garden Automation. Reasons: 1 missing link(s). Evidence: garden index 2026-06-18; public note cloudflare-r2-d1-pages.

Open this garden note