Deploy and Host MariaDB + Flanger with Railway

MariaDB that bills less memory. This is the official mariadb:11.8 image with Flanger wrapping the server. Flanger watches which cached file data the database re-reads and drops the rest.

About Hosting MariaDB + Flanger

Railway bills a service's memory as the kernel counts it, and that count includes the page cache. For MariaDB, by default MariaDB reads through the page cache as well as its buffer pool, so the same data can be held twice. That cache stays billed after the workload stops touching it.

Flanger 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 Flanger 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 dump and point queries, memory ended at 206 MB instead of 702 MB, with 292 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 Flanger 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. MariaDB may behave the same way until then.

Common Use Cases

Databases whose memory bill stays high after dumps 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 MariaDB + Flanger Hosting

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

Deployment Dependencies

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

Implementation Details

MariaDB 11.8 LTS, started with --innodb-buffer-pool-size=1G. The buffer pool is MariaDB's own memory, which Flanger never touches, so lower that flag if you want a smaller bill on a small database.

Variables: MARIADB_URL (private network), MARIADB_PUBLIC_URL (TCP proxy), MARIADBHOST, MARIADBPORT, MARIADBUSER, MARIADBPASSWORD, MARIADBDATABASE, MARIADB_DATABASE, MARIADB_ROOT_PASSWORD. A TCP proxy on port 3306 is included.

Optional switches:

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

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

Reporting an issue

If something looks wrong, open your service's logs on Railway and paste these into your report:

the event="start" line and the event="roots" line from the start of the log
the last few event="summary" lines
any event="warning" or event="backoff" lines near the problem

They contain versions, sizes, rates and data-folder paths, and no passwords or query contents, but read them before sharing. Set FLANGER_OFF=1 to run plain, in case you need the problem gone first.

Why Deploy MariaDB + Flanger 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 MariaDB + Flanger 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.