---
title: "Deploy MongoDB + Flanger"
description: "MongoDB 7.0 with Flanger, which drops page cache it isn't using"
category: "Storage"
url: https://railway.com/deploy/mongodb-flanger
---

# Deploy MongoDB + Flanger

MongoDB 7.0 with Flanger, which drops page cache it isn't using

**[Deploy MongoDB + Flanger on Railway](https://railway.com/template/mongodb-flanger)**

Machine-readable deploy manifest (JSON, validated by TemplateCI): https://railway.com/deploy/mongodb-flanger/manifest.json

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

## Template content

### MongoDB https://devicons.railway.app/i/mongodb.svg

- **Image:** ghcr.io/housek/flanger-mongo:7.0
- **Start command:** `/usr/local/bin/flanger -- docker-entrypoint.sh mongod --ipv6 --bind_ip ::,0.0.0.0 --setParameter diagnosticDataCollectionEnabled=false`

## Documentation

# Deploy and Host MongoDB + Flanger with Railway

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

## About Hosting MongoDB + Flanger

Railway bills a service's memory as the kernel counts it, and that count includes the **page cache**. For MongoDB, WiredTiger keeps its own cache and also reads through the kernel's page cache, so the same data is held twice, and a `mongodump` pulls whole collections into the cache. 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 `mongodump` and point reads, memory ended at 1.65 GB instead of 2.7 GB, with 1.0 GB 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. MongoDB may behave the same way until then.

## Common Use Cases

- Databases whose memory bill stays high after `mongodump` backups or bulk imports
- Collections much larger than the data actually read day to day
- Small and side-project databases where page cache is a large share of the bill

## Dependencies for MongoDB + Flanger Hosting

- A Railway volume mounted at `/data/db` (included in this template)

### Deployment Dependencies

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

### Implementation Details

MongoDB 7.0, because current 8.0 builds refuse to start on Linux 6.19 and newer (SERVER-121912).

Variables: `MONGO_URL` (private network), `MONGO_PUBLIC_URL` (TCP proxy), `MONGOHOST`, `MONGOPORT`, `MONGOUSER`, `MONGOPASSWORD`, `MONGO_INITDB_ROOT_USERNAME`, `MONGO_INITDB_ROOT_PASSWORD`. A TCP proxy on port 27017 is included.

Optional switches:

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