Why I Started Daypress: Replacing WordPress's PHP Runtime with a Single Rust Binary
The 40 percent web tax
WordPress powers over forty percent of the web for a good reason: editors love the publishing workflow, agencies know how to ship with it, and you own your database. But the runtime underneath that editorial workflow was designed for a very different era of the internet.
On a typical production site I audited earlier this year, a single uncached request triggered 114 SQL queries, booted 62 PHP classes across 28 plugins, and consumed 48 MB of worker memory before flushing a single byte of HTML. To make that fast, the industry invented an entire compensatory stack: Varnish, Redis object caches, Cloudflare page rules, and expensive managed hosting tiers.
We should not need five caching layers in front of a blog just to hide the cost of parsing PHP on every request.
One binary, one embedded SQLite WAL file
When I started sketching Daypress, I set one non-negotiable constraint: cargo build --release had to produce a single self-contained executable with zero external daemons. No MySQL server to tune, no PHP-FPM pool to size, and no Node.js SSR sidecar.
By pairing Axum with embedded Rusqlite in Write-Ahead Logging (WAL) mode, reads happen in-process with microsecond latency. A cold container boots in under 50 milliseconds, idles at roughly 18 MB of RAM, and serves SSR pages in under a millisecond on a \ VPS.
Why we build in public under v0.1
Replacing a twenty-year ecosystem is not a weekend project. Today in v0.1, the single binary, the WordPress-style admin portal, the /wp-json/wp/v2/* REST API, and our native Daystudio visual builder are all live and running this very site. Over the coming releases, we are hardening 1-click migrations against real-world exports and designing a capability-based WebAssembly plugin sandbox so untrusted extensions can never compromise the host again.