Skip to content

Provision editable Cloudflare WordPress sites from static artifacts #1970

Description

@chubes4

Goal

Expose a remote API that accepts a bounded static website artifact, provisions an isolated Cloudflare WordPress site, materializes it as editable Gutenberg content through Static Site Importer, persists canonical state through MDI/D1/R2, publishes immutable routes, and returns a durable operation receipt plus site URL.

Architecture

  • one shared Worker with hostname-derived site identity
  • shared D1 registry/coordinator with strict site_id isolation
  • shared R2 bucket with sites/{siteId}/... namespaces
  • Static Site Importer owns artifact validation, Blocks Engine compilation, WordPress site-plan materialization, and import reports
  • WP Codebox owns authentication, bounded artifact transport, coordinator leases, canonical persistence, publication, and lifecycle receipts

Tracked slices

Dependency order

  1. Finish lossless D1 activation (Fence Cloudflare mutations for lossless D1 cutover #1976).
  2. Prove SSI import in the existing single-site transaction (Import a pinned static website artifact into the Cloudflare runtime #1975).
  3. Generalize all state and caches by site identity (Scope Cloudflare WordPress state by site identity #1972).
  4. Add durable resumable lifecycle records (Add a durable Cloudflare site registry and operation lifecycle #1973).
  5. Expose the authenticated provisioning API (Expose an authenticated idempotent Cloudflare site provisioning API #1971).
  6. Prove producer interoperability and acceptance (Prove WP Build and Studio artifacts through remote site provisioning #1974).

Acceptance

A remote POST /v1/sites with a digest-verified WP Build/SSI website artifact returns 202, progresses through a durable operation, and produces an isolated hostname whose pages are editable Gutenberg blocks, survive cold restart, publish through R2, and support subsequent canonical N+1 edits. Repeated idempotency keys create nothing twice; concurrent sites cannot read or mutate one another. Generated-site acceptance requires zero fallback blocks and exact visual parity.

Existing foundations

This parent issue tracks the complete program; implementation remains split into independently reviewable child issues.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions