---
title: "Deploy MySQL + Flanger"
description: "MySQL 8.4 with Flanger, which drops page cache it isn't using"
category: "Storage"
url: https://railway.com/deploy/mysql-autocache-reaper
---

# Deploy MySQL + Flanger

MySQL 8.4 with Flanger, which drops page cache it isn't using

**[Deploy MySQL + Flanger on Railway](https://railway.com/template/mysql-autocache-reaper)**

Machine-readable deploy manifest (JSON, validated by TemplateCI): https://railway.com/deploy/mysql-autocache-reaper/manifest.json

- **Creator:** Kobe Housen's Projects
- **Category:** Storage

## Template content

### MySQL https://devicons.railway.app/i/mysql.svg

- **Image:** ghcr.io/housek/flanger-mysql:8.4
- **Start command:** `/usr/local/bin/flanger -- docker-entrypoint.sh mysqld --innodb-use-native-aio=0 --disable-log-bin --performance_schema=0 --innodb-buffer-pool-size=1G`

## Documentation

# Deploy and Host MySQL + Flanger with Railway

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

## About Hosting MySQL + Flanger

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.

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 `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 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. 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 + Flanger Hosting

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

### Deployment Dependencies

- Image: `ghcr.io/housek/flanger-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 Flanger 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:

- `FLANGER_DRY_RUN=1`: log what would be evicted, evict nothing.
- `FLANGER_OFF=1`: kill switch, plain MySQL 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 MySQL + 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 MySQL + 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.


## Similar templates

- [RustFS | (Just Updated) S3 Object Store, Public URL and Keys Set](https://railway.com/deploy/rustfs-or-just-updated-s3-object-store-p) — S3-compatible object store, keys and public URL preset, volume kept
- [TimescaleDB](https://railway.com/deploy/timescaledb-railway-template) — A PostgreSQL-based time-series database for analytics on Railway.
- [Garage S3 Storage](https://railway.com/deploy/garage-s3-storage) — Ultra-light S3 server: fast, open-source, plug-and-play.

Open this page in a browser: https://railway.com/deploy/mysql-autocache-reaper