Ephpm on Luther Monson

Fourth Place in Worker Mode, and Why It Wasn't PHP

Thu, 15 Oct 2026 19:45:00 -0700

We added ePHPm to the Yii3 runtime benchmark. It runs the same Yii3 API app on a bunch of PHP runtimes and compares them. Our fork with the ePHPm runner is ephpm/app-api.

Most of the results were good. ePHPm came first in classic mode and first on the database endpoint in both modes. Classic mode is the PHP-FPM style, where every request starts fresh.

Worker mode was the surprise. In worker mode the app boots once and stays in memory, like Octane or FrankenPHP’s worker mode. We came fourth of ten at about 50.7k requests a second. Workerman (~65k) and Swoole (~62k) were ahead.

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.

A Lock Is Only as Good as Its Release

Tue, 13 Oct 2026 20:40:00 -0700

Every “build a lock on Redis” tutorial spends its time on acquisition: SET key value NX PX 30000, one winner, done. The release gets one line, DEL key. That line is where most of the lock bugs I’ve had in ePHPm lived. Over about three months the same mistake showed up in three places. First the native session handler, then two of the Composer wrapper packages, and finally the cluster. Each time it wore a slightly different costume.

Step Debugging a Worker That Never Ends

Mon, 12 Oct 2026 21:10:00 -0700

Persistent workers are the big performance win in modern PHP. You boot Laravel or Symfony once, keep the container in memory, and serve thousands of requests out of the same process. ePHPm has had a worker mode for a while. Like most worker runtimes it had a quiet hole in it. You couldn’t step debug a request with Xdebug. I wanted that fixed without patching Xdebug and without giving up the warm pool. The answer ended up being to stop fighting the constraint and route around it. The debug lane is merged on main and coming in the upcoming v0.12.0 release.

WebSockets in ePHPm, From Zero to a Working Chat

Sun, 11 Oct 2026 17:30:00 -0700

I covered the design of ePHPm’s native WebSockets in a few paragraphs of the odds and ends post. Rust owns the socket and PHP runs once per event. An idle connection never costs you a PHP thread. That was the why. This post is the how. We’ll build a small chat app with login, per-user push notifications from ordinary HTTP requests and a browser client. Then we’ll serve it over TLS. Last come the limits, the sharp edges and how to debug it when the browser only tells you 1006.

An Upstream PHP JIT Use-After-Free, and Why Our Default Flipped Twice

Thu, 01 Oct 2026 20:10:00 -0700

In August, ePHPm turned PHP’s tracing JIT on by default in single-site serve mode. Three days later it went back off on every platform, and it’s still off. The reason turned out to be a use-after-free in PHP’s tracing JIT that has nothing to do with ePHPm. Stock php -S with a stock Laravel skeleton dies on it in a couple of requests. The fix is now released upstream. So this seemed like the right time to write up how we got there, and what still has to happen before the default can flip again.

Calling Rust From PHP Without a Socket, Part 2: Making Existing Code Use It

Mon, 21 Sep 2026 19:55:00 -0700

Part 1 covered the plumbing. ePHPm registers ephpm_kv_* and ephpm_db_* functions that call straight into Rust. A cache read through one costs about a tenth of a microsecond instead of a loopback round trip. That’s nice and also useless on its own. Nobody is going to rewrite their WordPress object cache or their Laravel cache store around a function called ephpm_kv_set(). Applications talk to existing APIs instead:

Redis through phpredis or Predis
the cache through PSR-6/16 or wp_cache_*
the database through wpdb, mysqli, Eloquent or DBAL

So there’s a set of Composer packages in the ephpm org whose whole job is to sit under those APIs and route them to the native functions. This post covers what’s in them and the rule that decides when they switch on. It also covers the bugs that only showed up once real applications ran on top.

ePHPm Odds and Ends: OOM-Killed Links, Opcode Scanning, WebSockets and a 44 ms Stall

Fri, 18 Sep 2026 20:05:00 -0700

Not every fix in ePHPm earns a full write-up. A few of the smaller ones have stuck with me because the lesson in each was bigger than the diff. Here are four from this summer.

A release build the OOM killer kept eating

ePHPm statically links libphp, ICU and a pile of other C libraries into one Rust binary. It ships for four targets. For the v0.4.2 performance release I set the release profile to lto = "fat" with codegen-units = 1 (#171). Fat LTO pulls every crate’s LLVM IR into one module in one process and optimizes it as a unit. One codegen unit removes the parallelism that would otherwise spread that memory out. That’s one very large process at the final link.

The Bugs Were Our Own Linker Wraps: Making a PHP Timeout Actually Time Out

Wed, 16 Sep 2026 19:35:00 -0700

In the stack guard post the villain was a -Wl,--wrap linker flag that turned off PHP’s C-stack overflow guard. It wasn’t the only one. Until August, max_execution_time did nothing in ePHPm on Linux, for the same reason. We had wrapped the function that arms it to a no-op. A runaway script ran until the HTTP layer’s request timeout gave up on it and sent a 504. The PHP thread kept burning CPU after that.

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.

Every Way a Tenant Escaped: A Cross-Tenant Breakout Field Guide

Sun, 13 Sep 2026 16:20:00 -0700

ePHPm can serve a directory full of sites out of one process. Point sites_dir at a folder and every subdirectory is a virtual host. The Host header decides which one you get. That’s how the PR preview environment runs. Every pull request gets a subdomain, and the code behind it is whatever somebody pushed. One process holding many tenants means ePHPm enforces every per-tenant boundary itself, in-process. There’s no container wall between site A and site B unless you add one.

Making ephpm php Byte-for-Byte Indistinguishable From php-cli

Thu, 10 Sep 2026 20:25:00 -0700

ePHPm embeds PHP into a single Rust binary. The obvious follow-up question from anybody deploying it is “do I still need a php on the box?” Composer, WP-CLI, artisan, PHPUnit and every build script in the world call php. If ephpm php can stand in for it then the answer is no. The single binary really means a single binary. “Mostly works” isn’t good enough for that though. These tools parse PHP’s output, check its exit codes and re-invoke it. So the goal was simple to state: ephpm php should be indistinguishable from php-cli.

Zero-Dependency Deployments - Single Binary for WordPress

Tue, 08 Sep 2026 20:25:00 -0700

The standard way to run a WordPress site is four services:

nginx for HTTP and TLS
php-fpm to run PHP
MySQL for data
Redis, once the site gets slow enough that someone installs an object cache plugin

That’s four processes and four config files. There are three sockets between them and four things to upgrade. For a big site that’s fine. For a brochure site or a staging copy it’s absurd. The same goes for a PR preview, a box at the edge, or a CI job that needs a real WordPress to test a plugin against.

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.

We Disabled PHP's Stack Guard Ourselves: Containing Segfaults in a Single-Process PHP Server

Sun, 06 Sep 2026 15:05:00 -0700

php-fpm has a property nobody thinks about until they leave it. When a worker segfaults, you lose one request. The master forks a new child and life goes on. ePHPm runs every tenant’s PHP as threads inside one process. That’s where the memory and latency wins come from. It also means one tenant’s segfault takes down every other tenant on the box.

This is the story of closing that gap in four steps over about two weeks. The last step turned out to be a bug we’d put there ourselves. It’s also the payoff for the thread pool work in the previous post. Everything below that actually shipped depends on ePHPm owning its own PHP threads.

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.

OPcache on Windows: Two Silent Failures

Sat, 29 Aug 2026 16:45:00 -0700

Windows is the platform where ePHPm gets the least traffic and the most surprises. Last week closed out two OPcache bugs that only exist there. Both were quiet in their own way. One killed the server at startup with nothing in our own logs. The other didn’t kill anything. It just ran PHP 8.3 with no opcode cache at all. For three weeks after a fixed SDK was published, every check stayed green.

Per-Tenant Network Policy in One Process: ePHPm's eBPF Thread Tags

Fri, 28 Aug 2026 20:40:00 -0700

In multi-tenant mode ePHPm serves every site in sites_dir from one process. Every tenant’s PHP runs as the same OS user on the same pool of ZTS threads. A thread that just served blog.example will serve shop.example a few milliseconds later. That’s the density win. It also means the kernel has no idea which tenant is behind a given connect(). As far as Linux is concerned it’s all ephpm-web.

Most of the isolation work in ePHPm happens above the kernel. That covers open_basedir, the function denylist, per-site databases and KV keyspaces. Network is the one place where that isn’t enough. This week we brought eBPF in to give the kernel a per-tenant identity. It went from a roadmap doc on Wednesday morning to merged that evening (#413, aimed at v0.8.1). v0.8.1 never got a release because its Linux legs failed to link. v0.8.2 shipped with the BPF object silently stubbed out. v0.8.3 was the first release that carried it. This post covers what it enforces and what it costs. It also covers what broke on the way out the door and what it doesn’t do.

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.

What Does One More WordPress Site Cost?

Tue, 25 Aug 2026 20:20:00 -0700

ePHPm v0.7.0 shipped per-site multi-tenancy. Point [server] sites_dir at a directory and every Host maps to its own docroot and its own Turso database file. One process serves all of them. The first question anybody asks about that is “how many sites fit on a box?” The honest way to answer it is to turn the question around. What does one more site cost? If you know the marginal RAM, file descriptors, CPU and disk for a tenant, the box size falls out of arithmetic.

What an Overloaded PHP Server Actually Returns

Mon, 24 Aug 2026 19:40:00 -0700

Ask most people what their PHP server does when it’s overloaded and you’ll hear “it returns 503s.” Ask them how they know and it usually comes down to a config setting they read about. I was in that camp for ePHPm. We had a [server.limits] max_connections knob, and the docs said it returned 503 at the cap. Every benchmark we had ever run reported zero errors under heavy load. Then I wrote a load generator that could produce overload. The honest answer was that an overloaded ePHPm returned nothing at all.

My Benchmark Was 4x Wrong Because of WSL

Thu, 20 Aug 2026 20:45:00 -0700

I do most of my benchmarking on a Windows box in WSL2. It’s the machine on my desk with 32 threads and 62 GB of RAM. Everybody who does that learns the first rule early: don’t put your data on /mnt/c. DrvFs is the 9p-backed mount that exposes the Windows drives inside WSL, and it’s slow for file-heavy work. So the databases, the docroot and the build output all live on the WSL ext4 disk. My scaling harness for ePHPm even says so in capital letters in its README.

Clustered SQLite in ePHPm, Part 2: Adding Turso

Wed, 19 Aug 2026 20:37:00 -0700

Part 1 ended with ePHPm running two SQLite engines. rusqlite ran in-process for a single node, and an embedded sqld child process ran for a cluster. The sidecar fell off a cliff past four concurrent writers. The best fix I could ship was a semaphore set to 1. This post is about replacing both engines with one, and about how I decided that engine was ready.

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

The thesis

Turso Database is a rewrite of SQLite in Rust:

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.

Faking MySQL's Quirks Well Enough to Fool WordPress

Sun, 16 Aug 2026 15:50:00 -0700

Last month I wrote about running SQLite behind a MySQL socket with litewire. I ended on “passing an install suite is not the same thing as behaving like MySQL”. That turned out to be accurate. On August 10th a few things happened at once:

I put a real WordPress 7.0.3 site through a benchmark on ePHPm.
I A/B tested the new in-process database bridge against the wire path.
I started building ephpm/db-wordpress, a wpdb drop-in that talks to the database in-process instead of over a socket.

Between them they produced six litewire issues in about three hours. None of them broke the install. All of them made WordPress quietly do the wrong thing.

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.

Database Connection Pooling with Smart Reset

Sun, 09 Aug 2026 16:25:00 -0700

PHP’s share-nothing model is one of its best properties. It has one expensive side effect: a request can’t keep a database connection for the next request. php-fpm gives you PDO::ATTR_PERSISTENT and mysqli’s p: hosts. But those are per-worker-process. PDO’s keep whatever session state the last request left behind. mysqli at least resets the session with COM_CHANGE_USER on reuse. And almost nobody turns them on. So in practice every PHP request does a TCP connect, a MySQL handshake and an auth exchange. Then it maybe sends some SETs, runs its queries and sends COM_QUIT. Multiply that by your request rate and MySQL spends a real share of its time authenticating clients it just said goodbye to.

Clustered SQLite in ePHPm, Part 1: Replication by Sidecar

Sat, 08 Aug 2026 20:14:00 -0700

Most PHP sites I have run in the last twenty years did not need a MySQL server. They needed a database, and MySQL was the one every framework spoke. With ePHPm I have been trying to get rid of that server for the common case. The piece that makes it possible is litewire. PHP connects with plain pdo_mysql. litewire speaks the MySQL wire protocol, and the queries land in a SQLite file. WordPress and Laravel don’t know the difference. No mysqld, no child processes, just ephpm and a .db file.

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.