Rust on Luther Monson

Composer Without PHP: Embedding vivacity in ePHPm

Wed, 14 Oct 2026 23:20:00 -0700

The pitch for ePHPm is one binary in place of php-fpm, nginx and Redis. There was always a hole in it though. To deploy a PHP app you still need to run composer install. That drags PHP and composer.phar back onto the box or into the container build, just for that one step. ephpm composer install now runs a pure-Rust, Composer-compatible installer called vivacity inside the ePHPm binary. One binary serves the app and installs its dependencies. On Windows that works with no PHP installed at all. Getting it right took five upstream PRs and a fork. It also took a docs rewrite that took back claims we’d already made. And I had to teach ephpm to pretend to be php.

Clustered SQLite in ePHPm, Part 3: CDC Over the Cluster Channel

Tue, 15 Sep 2026 21:08:00 -0700

By the end of Part 2 ePHPm v0.7.0 ran exactly one SQLite engine in process. That was Turso, for single-node and clustered mode alike. The sidecar was gone. What I skipped over is how a replica actually gets the primary’s writes, and what happens when the primary dies with data on it. That’s this post.

Part 1: Replication by sidecar with sqld
Part 2: Adding Turso
Part 3: CDC over the cluster channel (this post)

CDC from the engine itself

Turso has change data capture built in. Turn it on for a connection and every committed change lands in a turso_cdc table. Each row has a monotonically increasing change_id, the table, the rowid, and before/after images of the record. The primary tails that table and ships transaction batches. Replicas apply them. That’s the whole design. It landed as an experimental path in #186 at the end of July. The tailer and applier live in litewire (litewire#10).

Calling Rust From PHP Without a Socket, Part 1: The Native Functions

Mon, 14 Sep 2026 20:40:00 -0700

ePHPm is a single Rust binary that embeds PHP. It carries its own KV store and its own SQLite-backed database in the same process. For a long time PHP code could only reach that KV store the same way it reaches Redis. It opened a TCP socket to the RESP listener ePHPm runs on localhost, encoded a command and waited for the reply. That works, and every PHP Redis client in existence already speaks it. But it is a strange thing to do when the hash map you’re talking to lives a few pointers away in the same address space.

P99 From 280 ms to 58 ms by Making the Queue Fair

Mon, 07 Sep 2026 19:45:00 -0700

A third-party Laravel runtime comparison put ePHPm’s worker mode at the top on throughput. It was about 19% ahead of FrankenPHP on /api/static. It was also at the bottom of the fast group on tail latency, with a P99 of 157 ms against FrankenPHP’s 57 ms. Best throughput plus the fattest tail is a shape worth chasing, because fast execution can’t produce it. Making requests faster lowers the mean and the tail. Only waiting can pull them apart. Specifically, unfair waiting.

Stop Running PHP on tokio's spawn_blocking - Own Your Thread Pool

Fri, 04 Sep 2026 20:30:00 -0700

For most of its life, ePHPm ran every PHP request on tokio’s spawn_blocking pool. It works. It passes tests and it serves benchmarks fine. It’s the first thing anybody reaches for when they need to call blocking code from async Rust. It’s also quietly wrong for a language runtime. The problems only show up under overload or after a crash. Over the last three weeks it got replaced with a pool of OS threads that ePHPm owns. That pool shipped first behind a config flag, then as the default. As of v0.9.0 the spawn_blocking engine is gone.

Clustered ACME in Production: Three Bugs That Took TLS Down

Wed, 02 Sep 2026 19:30:00 -0700

ePHPm gets its own certificates from Let’s Encrypt. In a cluster only one node should be talking to the CA. The nodes elect an ACME leader over the shared KV store. The leader orders the cert, and everybody else installs it from KV. That all had unit tests and had worked on single nodes for months. Then I tried to move wildcard TLS termination for our preview environment off a separate proxy and onto the 3-node cluster itself. In about two days it found three separate bugs that each took TLS down. None of them showed up in a unit test. All of them are the kind of thing you only learn by putting the feature on real machines.

Middleware in PHP: Compiling It With elephc, Then Not Needing To

Mon, 31 Aug 2026 20:50:00 -0700

ePHPm middleware runs before PHP. It’s a small versioned C ABI, loaded with dlopen, that gets to look at a request and reject it before PHP boots or the request body is read. That’s the right shape for a gateway. It’s the wrong shape for most PHP shops, who want to write their middleware in PHP. This is the story of compiling PHP into a native .so to fit that ABI and finding exactly where it broke. Then I built the lane that should have existed in the first place.

Security and Performance Hardening of a Rust Database Proxy

Thu, 27 Aug 2026 20:30:00 -0700

litewire is the piece of ePHPm that lets PHP apps talk MySQL to a SQLite file. I wrote about how it works and about the MySQL quirks WordPress depends on. This one is the less visible half of August:

an audit pass on litewire
a multi-tenant mode that turned a database proxy into a security boundary
a performance regression I shipped and then had to go find

It’s written in Rust. Memory safety is supposed to be the part I don’t have to think about, and it mostly is. The use-after-free in this story was in a dependency. The worst bug wasn’t a memory bug at all.

Rolling Your Own KV Store Instead of Embedding Redis

Mon, 17 Aug 2026 20:44:00 -0700

Every PHP deployment I’ve run eventually grew a Redis. Sessions, the WordPress object cache, Laravel’s cache and locks, rate limiting. ePHPm is supposed to be one binary that replaces nginx + php-fpm + Redis, so it needed a cache in the box. I didn’t want to write one. This post covers why I did anyway and how it’s built. It also covers the bug that sat in its eviction code from March until last month. Then I compare it against a stock Redis on the same machine with redis-benchmark doing the talking.

Requests That End Wrong: A 200 That Was Really a Crash

Thu, 13 Aug 2026 21:14:00 -0700

The scariest response a server can send isn’t a 500. It’s a 200 that should have been a 500. A crash is loud. The pod restarts, an alert fires, somebody looks. A truncated page with a success status code is quiet. Your CDN caches it and the health check calls the box healthy. A client parses half a document as if it were the whole thing.

ePHPm embeds PHP inside a Rust server. So we own the part of PHP that php-fpm normally owns: starting a request, running the script and ending it. Over the last couple of months I’ve fixed three bugs that all live in that start-and-end code. None of them were in the SAPI I/O callbacks like ub_write and read_post, where you’d expect to find embed bugs. They were in the Zend request lifecycle and in TSRM teardown. That’s code you never touch when you run PHP behind php-fpm.

Gossip-Based Clustering for PHP Apps

Tue, 04 Aug 2026 20:52:00 -0700

Most PHP developers never touch clustering primitives. That’s by design. PHP is share-nothing. Each request starts from zero, and anything shared lives somewhere else. Sessions go in Redis. Cache goes in Redis or Memcached. Locks go in Redis. When you run two app servers, the “cluster” is really two stateless boxes pointed at the same Redis. That works until Redis is the thing you’re trying not to run.

ePHPm has its own KV store in the same process as PHP. On one node that’s straightforward. On three nodes behind a load balancer, a session written on node 1 has to be readable on node 3. That means the nodes have to know about each other and agree on where data lives. This post is how that works as of v0.5.2, including the parts I’m not happy with yet.

Building a Custom SAPI - How PHP Actually Talks to the Outside World

Thu, 30 Jul 2026 20:18:00 -0700

If you’ve only ever run PHP behind nginx, you’ve probably never had to think about how echo reaches a socket. When you embed PHP like ePHPm does, it’s the first thing you have to answer. The answer is a SAPI. There is very little written about implementing one. Most of what I know came from reading sapi/cli, sapi/cgi and sapi/embed in php-src. Then I found out which parts I’d misread. This is the write-up I wanted back in March.

SQLite as a Production Database via Protocol Translation

Sat, 25 Jul 2026 20:40:00 -0700

Most of the PHP sites I’d put on ePHPm don’t need a MySQL server. A brochure WordPress, an internal Laravel tool, a preview environment that lives for an afternoon. What they do need is something that looks like MySQL, because mysqli and pdo_mysql are the only database drivers their code has ever been pointed at. I mentioned this in the ePHPm pragmatism post as a one-paragraph “because”. This is the longer version, now that WordPress 7.0 and Laravel 13 both install and run end to end on it.

The Pragmatism of ePHPm - Every Decision Has a "Because" Behind It

Sun, 21 Jun 2026 19:05:00 -0700

ePHPm tagged v0.1.0 this week, three months after the first commit. Before the feature list grows any further I want to write down how decisions get made on it. This is mostly for myself. The easiest way to ruin a project like this is to let it turn into a checklist of things other projects have.

The pitch is simple. One binary that runs a PHP app with fewer moving parts than nginx + php-fpm + Redis + MySQL. Every feature has to trace back to that. If I can’t finish the sentence “this exists because…” with a real problem from running PHP in production, it doesn’t go in.

PHP Signal Safety - The Init Ordering Bug Nobody Warns You About

Sun, 12 Apr 2026 20:15:00 -0700

Last week I wrote about why ePHPm embeds PHP from Rust and promised the signal bug its own post. Here it is. It’s the kind of bug where the fix is about ten lines and the explanation is the whole post. Nothing in PHP’s embed documentation (there’s barely any) tells you that initializing PHP has process-wide side effects. Those side effects assume PHP is the only thing in the process.

The setup

The first working version of ephpm serve looked like every async Rust program. It was #[tokio::main]-style. Build the runtime, then inside it load config, initialize PHP and start the HTTP server. PHP requests run on spawn_blocking threads. Simplified:

Why Rust for PHP Embedding (Not Go)

Sun, 05 Apr 2026 19:40:00 -0700

Go is my primary language and has been for a long time. When I started building ePHPm a few weeks ago the obvious move was to write it in Go. ePHPm is a PHP application server. It’s one binary that embeds the real PHP interpreter (libphp, the Zend engine) and puts an HTTP server, TLS, a KV cache and a database proxy around it. A PHP app doesn’t need nginx + php-fpm + Redis to run. FrankenPHP already proved the “PHP inside a Go web server” idea works, and it works well. I wrote it in Rust anyway. This post covers the reasoning, and the part of the design that Rust made easier and the part it didn’t. It also has some numbers I should have measured before I wrote the design doc instead of after.