Local setup.
Use Node 24, as recorded in .node-version, and the committed npm lockfile. Run these commands from the project checkout.
npm ci
npm run dev
# Visual development: http://localhost:4321The Astro development server renders the website. Use the Pages runtime when testing form persistence:
npm run build
npm run db:local
npm run preview
# Full Pages runtime: http://localhost:8789db:local applies schema migrations to local storage. The Pages preview uses that local database; it does not write to production D1. Local state is held in ignored .wrangler/ files.
Validate before publishing.
npm run check
npm run build
npx playwright install chromium
npm testnpm run check runs Astro diagnostics and TypeScript checks for Pages Functions. The test suite starts a local Pages server and checks API behavior, persistence, deletion, responsive layouts, themes and accessibility.
For an existing Chromium installation, set PLAYWRIGHT_EXECUTABLE_PATH. Test setup applies local migrations and clears local rate counters so runs are repeatable. Test fixtures use only the local database.
Automated accessibility checks are one part of validation. Keyboard use, motion preferences, reading order and the actual page composition also need review.
Publish to Cloudflare Pages.
The project uses direct upload to the Pages project afterbuy, on the production branch main. The build output is dist/. Pages Functions are bundled from functions/ during deployment.
# Confirm the intended Cloudflare account first.
npx wrangler whoami
# Set CLOUDFLARE_ACCOUNT_ID in your deployment environment.
npm run db:remote
npm run deploywrangler.jsonc declares the Pages output directory, runtime compatibility date and D1 binding. The account is selected through the authenticated Wrangler session or CLOUDFLARE_ACCOUNT_ID; Pages does not accept an account_id field in that config.
Apply required database migrations before deploying handlers that depend on them. Run npx wrangler types after changing bindings. Use the repository’s pinned Wrangler version.
Set SITE_URL at build time to change the canonical website origin. Add a confirmed custom domain to the Pages project separately; changing metadata does not configure DNS or a domain binding.
Operate the boundary you deployed.
Remote previews need a separate D1 database if they will write test data. This project’s production binding should not be reused as a disposable test database. No automatic CI pipeline is configured by this repository.
Use Pages deployment history to identify a release. Rolling back website code does not undo database writes or migrations. Schema changes should remain compatible with any release you may need to restore.
After deployment, verify public routes and same-origin API behavior. When using a synthetic signup to check persistence, remove that test record afterward. Never expose a subscriber list to prove a deployment worked.
Platform references: Pages configuration, direct upload and D1 migrations.