Deploy and Host Postgres + Autocache Reaper with Railway

Postgres 18 that bills less memory. This is Railway's own Postgres image (postgres-ssl:18, same wrapper.sh, SSL, volume layout and variables as the stock Postgres template) with autocache-reaper as the entrypoint. The reaper watches which cached file data Postgres re-reads and drops the rest.

About Hosting Postgres + Autocache Reaper

Railway bills a service's memory as the kernel counts it, and that count includes the page cache: table and index files Postgres has read stay cached and billed after the workload stops touching them. After a backup, a bulk load or a one-off report, a database can sit at several times the memory it needs.

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

Measured on Railway on 2026 Oct 26 with pgbench -i -s 10 (a 157 MB database), 10 minutes after the load:

	value
memory billed at peak, during the load	574 MB
memory billed 10 minutes later	180 MB
page cache still held	13 MB
evicted	174.5 MB
re-read from disk afterwards	0.23 MB (0.13 %)

What remains is mostly Postgres's own shared_buffers, which the reaper never touches. Your saving depends on your workload: data that is re-read all the time stays cached.

Those are short-term figures. Over 19 hours on the same mostly idle database, memory held at about 160 MB with almost no page cache, but the reaper evicted 615 MB and the disk read 640 MB in that time. So it was mostly re-reading small catalog files it had just dropped, about 10 KB/s. That is harmless to a quiet database and costs no extra memory, but it is wasted work, and a fix is in progress. A 3-hour or 30-day workload has not been benchmarked yet.

Common Use Cases

Databases whose memory bill stays high after nightly backups, pg_dump runs or bulk imports
Databases larger than their working set, where most of the data is rarely read
Small and side-project databases where page cache is a large share of the bill

Dependencies for Postgres + Autocache Reaper Hosting

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

Deployment Dependencies

Image: ghcr.io/housek/acr-postgres:18, rebuilt automatically whenever Railway's postgres-ssl:18 base image changes, after tests and a start/stop check pass
Base image: Railway's Postgres SSL image

Implementation Details

Variables match Railway's Postgres template: DATABASE_URL (private network), DATABASE_PUBLIC_URL (TCP proxy), PGHOST, PGPORT, PGUSER, PGPASSWORD, PGDATABASE, POSTGRES_*, PGDATA.

Optional switches:

AUTOCACHE_DRY_RUN=1: log what would be evicted, evict nothing.
AUTOCACHE_OFF=1: kill switch, plain Postgres 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 Postgres + 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 Postgres + 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.