Ffi on Luther Monson

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.

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.

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.