Native PHP in Studio: Two Weeks In

Two weeks ago I was staring at a tar.gz on my disk and thinking, “OK, maybe this is a thing.” Inside it was a statically linked PHP binary. Today I have Studio sites running against one of those binaries, WordPress installed via Blueprints, and end-to-end tests passing.

That’s the headline. Here’s the context.

Radical Speed Month

Automattic is running a company-wide experiment from April 22 to May 22 called Radical Speed Month: pair up in two-person teams, remove the usual approval loops and keep decisions inside the two-person team, pick something real, and see what you can ship in thirty days.

My RSM project, with my colleague Fredrik Rombach Ekelund, asks a sharp question about Studio: is it possible to run a real, native PHP binary as an alternative to Playground CLI — and if so, how much faster can it make Studio?

Studio has always run sites on Playground CLI, the WebAssembly PHP runtime that makes Studio feel magical: a real WordPress site with no system dependencies, no Apache, no Docker. The question is whether a native PHP process can give us a meaningful performance boost without giving up what makes Studio easy to use.

Two weeks in, the answer to “is it possible?” is yes — and we have working scaffolding to prove it.

What’s working

Four things had to come together before we could even start measuring anything. By the end of week two, all four are working.

Building the binaries

For PHP itself we’re using static-php-cli, which produces statically linked PHP binaries with a sensible bundle of extensions — pdo_sqlite, intl, opcache, sodium, imagick, and the core pieces WordPress needs for local development. macOS builds are in place; Linux and Windows are next.

Starting the server

For each site, Studio runs PHP’s own built-in development server (php -S) against the static binary. It ships with PHP itself, which keeps the dependency footprint at zero — no Apache, no nginx, no PHP-FPM. The server starts cleanly, serves WordPress, and behaves exactly like you’d hope.

Running blueprints

Studio supports WordPress Blueprints — JSON-defined site setup steps like “install this plugin, set this option, switch to this theme.” We wire blueprint execution into the new runtime via the official blueprints.phar from WordPress/php-toolkit. Site creation, plugin installs, option changes, theme switches: all working through the phar.

E2E tests passing

This is the milestone I care about most. Studio has a real end-to-end test suite that exercises site creation, site management, plugin installs, theme switches — the things that actually matter. With the native PHP runtime turned on, those tests pass.

Two weeks in, with two engineers, the new runtime is at almost full compatibility with the existing Studio surface area covered by our E2E suite. That was not a guaranteed outcome. I had budgeted weeks of “okay, but this one specific feature breaks under native PHP” — and so far there’s almost none of that. We’re plugging into the same WordPress, the same SQLite drop-in, and the same site management code Playground CLI already supports. The runtime swap turned out to touch a much smaller surface area than I feared.

The biggest compatibility wrinkle so far was Blueprints detecting SQLite. Studio installs the SQLite integration as a must-use plugin, while the Blueprints phar expected it under wp-content/plugins. The fix is temporary, but it got us through the experiment and gave us a clear upstream follow-up.

What’s next

Real benchmarks. Page load, memory, cold start, plugin install — the full gamut. We need numbers, not vibes.
The concurrency story. PHP_CLI_SERVER_WORKERS > 1 hits SQLite locks fast. Whether we live with workers=1, manage a pool, or do something else is the next architectural question.
How we surface this in the UI, if at all.

Two weeks, two engineers, almost full compatibility. The fun part — how much faster — is week three.

Two weeks down, two to go. I’ll write again at the end of the month with whichever answer the experiment produces.