Add a Cloudflare-hosted Playground runtime backend

[chubes4]

Goal

Run the existing WP Codebox WordPress runtime contract on Cloudflare Workers, using WordPress Playground for PHP/WordPress execution and preserving Codebox ownership of recipes, commands, snapshots, restore, diagnostics, and artifact envelopes.

Architecture

• Playground owns PHP-WASM and low-level WordPress runtime primitives.
• WP Codebox owns runtime boot, command routing, snapshots, restore, diagnostics, and artifact contracts.
• Cloudflare Workers provides compute; Durable Objects serialize site mutation; R2 stores durable state artifacts.
• Markdown Database Integration can provide canonical file-backed WordPress state in a later slice.

Staged acceptance gates

1. Boot WordPress through a Codebox runtime backend on Cloudflare and return a deterministic WordPress/PHP health envelope.
2. Preserve Codebox command and artifact contracts without caller-visible Cloudflare semantics in runtime-core.
3. Serialize one site through a Durable Object.
4. Persist and restore a complete runtime-state artifact through R2.
5. Prove mutation, cold restoration, and concurrent request behavior end to end.

Evidence

The lower-level PHP feasibility gate has passed in the maintained Playground fork: PHP 8.5.8 executed on Cloudflare Workers with the 21,019,221-byte Asyncify Wasm module under the 128 MB isolate limit. Working PR: chubes4/wordpress-playground#1

Related upstream tracker: WordPress/wordpress-playground#69

Compatibility

This should be an additive backend/integration. Existing Codebox runtime contracts, browser callers, recipes, and Playground behavior must remain compatible.

[chubes4]

Remote Cloudflare gate result

The merged Worker from #1856 and CPU-budget follow-up #1857 was deployed from accepted merge commits to https://wp-codebox-cloudflare-runtime.chubes.workers.dev.

Observed deployment evidence:

• bundle: 21,313.72 KiB uncompressed / 7,950.82 KiB gzip
• Worker startup: 16-17 ms
• PHP-only feasibility had already passed under the paid 128 MB isolate limit
• full WordPress requests return Cloudflare 1102
• the result persists with limits.cpu_ms: 300000, Cloudflare's supported paid-plan maximum

Cloudflare documents 1102 as CPU or memory resource exhaustion. Because the failure returns in about two seconds with the five-minute CPU ceiling configured, the full WordPress Worker gate remains blocked at the fixed runtime resource boundary. The Worker remains useful as a coordination and storage tier, but GitHub Actions should own Playground compute.

Successor work:

• Add durable stateful Playground execution for GitHub Actions #1862: generic durable stateful Playground execution for GitHub Actions
• Persist Worker WordPress state with MDI, R2, and Durable Objects #1863: Durable Object and R2 single-writer state coordination

Reproduction from a fresh checkout of merge commit 0ecc975ebbc67fa839a1029694fe8970869eff36:

1. Run npm ci.
2. Run npm run test:cloudflare-runtime.
3. Run npm run cloudflare:dry-run.
4. Run npm exec -- wrangler deploy --config packages/runtime-cloudflare/wrangler.jsonc against a paid Workers account.
5. Request the deployed Worker URL and observe Cloudflare 1102 during full WordPress initialization.

Cloudflare limits reference: https://developers.cloudflare.com/workers/platform/limits/#cpu-time

[chubes4]

The Cloudflare boot boundary is now isolated and the upstream archive defects are tracked.

Remote findings

• PHP-WASM alone returns HTTP 200 with PHP 8.5.8.
• PHP-WASM plus the complete 31,435,175-byte WordPress ZIP resident in JS returns HTTP 200, so fetch plus PHP is below 128 MB.
• Playground's existing extraction path fails because it materializes File -> ArrayBuffer -> MEMFS ZIP before expanding the 85,570,923-byte WordPress tree.
• Streaming only server-side WordPress files succeeds remotely: 1,807 files / 22,591,887 bytes, WordPress 7.0.2 detected.
• Streaming those files plus SQLite integration preparation also succeeds remotely.
• Running the installer after full-stream decoding exceeds the practical request budget; local workerd completes the same installation.

Remote probe: https://wp-codebox-cloudflare-runtime.chubes.workers.dev/?phase=streamed-files&version=cd3b7b9f

Upstream repair

Filtered range extraction is the correct way to avoid decoding the archive's 40.8 MB of JavaScript and other static assets. Investigation found three defects in Playground's decodeRemoteZip() range path: path identity comparison, a dropped byte between central-directory scan chunks, and semaphore release before response-body consumption.

• Issue: decodeRemoteZip drops range-filtered entries due to path identity comparison WordPress/wordpress-playground#4109
• PR: Fix range-filtered remote ZIP decoding WordPress/wordpress-playground#4110

The repaired package deterministically emits all 1,492 PHP files / 20,812,704 bytes from the current WordPress archive in Node. Its range path currently emits zero selected entries under workerd, so the next owning-layer step is a workerd compatibility test/fix before WP Codebox adopts the filtered range API. The WP Codebox worktree remains on the reproducible published full-stream implementation; it does not vendor the upstream patch.

[chubes4]

The PR stack and remote boundary are now explicit:

• Playground filtered Range repair: Fix range-filtered remote ZIP decoding WordPress/wordpress-playground#4110
• Playground deployed workerd gate: Add Cloudflare Worker PHP-WASM and remote ZIP gates WordPress/wordpress-playground#4111
• WP Codebox consumer draft: Run WordPress within Cloudflare Worker memory limits #1872

New verified evidence

The deployed Playground Worker now returns HTTP 200 for both PHP-WASM and filtered remote ZIP decoding. The range gate traverses all 4,401 WordPress archive entries and emits exactly wordpress/wp-includes/version.php.

WP Codebox now:

• Materializes 1,807 server-required files / 22,591,887 bytes through filtered ranges.
• Completes SQLite integration preparation remotely with HTTP 200.
• Hydrates a valid 368 KB installed SQLite seed with 22 WordPress tables.
• Skips wp_install(), installer checks, pseudo-cron, external HTTP, and updates.
• Executes the seeded wp-load.php gate locally with HTTP 200 and WordPress 7.0.2.

The seeded wp-load.php request still exceeds 300 seconds remotely. This isolates the remaining blocker to full WordPress bootstrap execution under the Cloudflare production isolate, not archive fetch, extraction, SQLite preparation, installation, cron, or outbound HTTP.

Cloudflare R2 is also account-blocked: bucket APIs return code 10042 until R2 is enabled once in the Dashboard. The bundled database is explicitly disposable machinery; MDI/R2 remains the canonical-state design.