Ops rollout guide

What is live now, what is protected, and what still needs setup for the Pinewave portal stack.

The portal and payment workflow are now built into the Worker as a real D1 + Stripe foundation. This page explains the remaining setup steps so the protected client/admin system can be turned on cleanly in Cloudflare without risking the public site.

What is live now

  • Website-based inquiry forms and client updates
  • Attachment support through the contact flow
  • Reference IDs for cleaner follow-up
  • Protected portal routes and Stripe workflow foundation in code

Phase 1

D1 binding and bootstrap admin

Attach the Worker to a real D1 database and set the bootstrap admin secrets so the protected admin login can create the first live account.

Phase 2

Protected records and file storage

Use D1 for users, projects, pricing, inventory, and payment requests, then add R2 when client files or inventory media need their own protected storage layer.

Phase 3

Stripe and admin workflow

Attach Stripe secrets and the webhook so the admin dashboard can generate hosted payment links and keep status updates tied to the right project record.

Step-by-step setup

  1. Create a Cloudflare D1 database and bind it to the Worker as DB.
  2. Add ADMIN_BOOTSTRAP_EMAIL, ADMIN_BOOTSTRAP_PASSWORD, and optionally ADMIN_BOOTSTRAP_NAME to the Worker.
  3. Add STRIPE_SECRET_KEY and STRIPE_WEBHOOK_SECRET to the Worker.
  4. Create a Stripe webhook pointed at /api/stripe/webhook and subscribe to checkout session events.
  5. Log into admin-login.html with the bootstrap account, then create client accounts, projects, and payment links.
  6. Add R2 later if you want protected file storage beyond the existing contact-form attachment flow.

What this unlocks

  • Client dashboard with project status and payment links
  • Admin dashboard for pricing edits, inventory, and project setup
  • Stripe checkout sessions tied to project payment requests
  • A cleaner handoff between quoting, active work, and deposits

Need it live now?

The right move is usually to keep the current website intake stable, then stage the protected portal as a separate build so there is no risk to the public site or the working contact flow.