How WordPress runs inside a Worker

HostlessWP uses php-wasm from WordPress Playground: PHP 8.3 compiled to WebAssembly, the same build that runs WordPress in the browser. Inside a Worker it boots once per instance and then serves requests one after another.

• Code is packed into zip bundles. WordPress, your theme, plugins and translations are bundled at deploy time. They are mounted into PHP's in-memory file system lazily: a file is only unpacked when PHP first reads it. A request reads around 2,000 of a site's 16,000 files, and every unpacked file costs memory.
• OPcache works. php-wasm's OPcache does not start by default, because its server API is not on OPcache's list. The build patches that and keeps compiled scripts in shared memory.
• Scripts are precompiled. During deploy, hostlesswp renders a few pages locally against your database and packs the OPcache files, so a new instance does not compile 1,700 scripts before its first page.

PHP in WebAssembly cannot open network sockets, so it cannot talk to MySQL itself. A db.php drop-in replaces WordPress's database class and sends every query to the Worker, which runs it through Cloudflare Hyperdrive. A userland mysqli covers plugins that skip $wpdb.

Hyperdrive pools connections, which means two statements in a row can run on different server connections. WordPress and its plugins assume one connection, so the bridge carries session state with each statement:

• Session settings are attached to every query as SET_VAR optimizer hints.
• SELECT @@variable is answered from SHOW VARIABLES.
• SQL_CALC_FOUND_ROWS paging runs as a parallel COUNT, which brought the REST posts list from 2.5 s to 1.6 s in our tests.

Hyperdrive's query cache is turned off, because WordPress reads its own writes right away. A database that is not reachable from the internet is connected through a Cloudflare Tunnel run from your server.

Starting PHP on a fresh instance takes seconds, so pages for visitors who are not logged in are kept in Workers KV and answered without starting PHP.

• Never cached: logged-in users, commenters, password-protected posts, shoppers with a cart, searches, previews, the admin, the login page, the REST API, and any response that sets a cookie or that a plugin marks as not cacheable (WooCommerce cart, checkout and account pages).
• Kept fresh: publishing, editing, approving comments, changing menus, widgets, the theme, plugins, settings or stock marks every cached page as outdated, as does each deploy. The next visitor still gets the cached copy while the page renders again in the background. No page is served older than 8 hours.
• Visible: every response carries x-hostlesswp-cache (hit, stale, miss, bypass, skip). Turn the cache off with --no-page-cache.

A Worker has no lasting disk, so wp-content/uploads lives in an S3-compatible bucket: Cloudflare R2, AWS S3, Backblaze B2, MinIO or any other service with the S3 API.

• Every deploy copies new files from your site's uploads folder to the bucket. Nothing is ever deleted there.
• PHP writes uploads to memory as usual; after the request the Worker copies them to the bucket. Unique file names are checked against the bucket, originals are fetched when you edit an image, and deleting an attachment deletes its files.
• Media URLs stay /wp-content/uploads/... and are served from the bucket, cached at the edge, without starting PHP. The bucket can stay private; give it a public or CDN address and new media links point there directly.