Deploy and Host MySQL + Autocache Reaper with Railway

MySQL that bills less memory. This is the official mysql:8.4 image with autocache-reaper wrapping the server. The reaper watches which cached file data the database re-reads and drops the rest.

About Hosting MySQL + Autocache Reaper

Railway bills a service's memory as the kernel counts it, and that count includes the page cache. For MySQL, dumps and other large reads can leave file data in that cache, and it stays billed after the workload stops touching it.

The reaper drops it at a pace bounded by the disk's measured IO headroom, and backs off when what it dropped comes back. The database starts first and keeps running whatever the reaper does, and signals are passed through, so a redeploy is a clean shutdown. Only file cache is touched, never the database's own memory: dropped cache is re-read from the volume if needed, and dirty pages are never dropped.

In a 5-minute run with a mysqldump and point queries, memory ended at 547 MB instead of 1,240 MB, with 556 MB evicted and nothing re-read. That was measured in a test container, not on Railway. Your saving depends on your workload: data that is re-read all the time stays cached.

That is one short run. On a mostly idle Postgres deployment over 19 hours, the same reaper kept re-reading small files it had just dropped, about 10 KB/s. It is harmless to a quiet database, but it is wasted work, and a fix is in progress. MySQL may behave the same way until then.

Common Use Cases

Databases whose memory bill stays high after mysqldump backups or bulk imports
Databases larger than their working set
Small and side-project databases where page cache is a large share of the bill

Dependencies for MySQL + Autocache Reaper Hosting

A Railway volume mounted at /var/lib/mysql (included in this template)

Deployment Dependencies

Image: ghcr.io/housek/acr-mysql:8.4, rebuilt automatically whenever its base image changes, after tests and a start/stop check pass

Implementation Details

MySQL 8.4 LTS, started with the same flags as Railway's MySQL template, including --innodb-buffer-pool-size=1G. The buffer pool is MySQL's own memory, which the reaper never touches, so lower that flag if you want a smaller bill on a small database.

Variables: MYSQL_URL (private network), MYSQL_PUBLIC_URL (TCP proxy), MYSQLHOST, MYSQLPORT, MYSQLUSER, MYSQLPASSWORD, MYSQLDATABASE, MYSQL_DATABASE, MYSQL_ROOT_PASSWORD. A TCP proxy on port 3306 is included.

Optional switches:

AUTOCACHE_DRY_RUN=1: log what would be evicted, evict nothing.
AUTOCACHE_OFF=1: kill switch, plain MySQL behaviour.
Without a restart, from a shell in the service: echo live > /dev/shm/autocache-mode (or dry-run, pause).

The reaper logs one JSON line per event on stderr: start, roots, and a periodic summary with usage, file, evicted_total and reread_total.

Why Deploy MySQL + Autocache Reaper on Railway?

Railway is a singular platform to deploy your infrastructure stack. Railway will host your infrastructure so you don't have to deal with configuration, while allowing you to vertically and horizontally scale it.

By deploying MySQL + Autocache Reaper on Railway, you are one step closer to supporting a complete full-stack application with minimal burden. Host your servers, databases, AI agents, and more on Railway.