Deploy MongoDB 9 Replica Set

Deploy and Host MongoDB 9 Replica Set with Railway

This template deploys a three-member MongoDB 9 replica set (Primary-Secondary-Secondary) with keyfile authentication, automated failover, and an HAProxy entry point that gives every client one stable connection string — through elections, restarts, and node failures.

About Hosting MongoDB 9 Replica Set

Hosting MongoDB as a replica set on Railway gives you a self-healing database: if the primary dies, the remaining members elect a new one within seconds and HAProxy re-routes traffic to it, so your application never changes its connection string. The template creates five services:

• mongo1, mongo2, mongo3 — data-bearing replica set members (MongoDB 9.0), each with a Railway Volume at /data/db. Members authenticate to each other with a shared keyfile; the root user (mongo) and password are generated at deploy time.
• mongo-init — a one-shot service that waits for all three nodes, runs rs.initiate() (idempotent), confirms 1 PRIMARY + 2 SECONDARY, then exits. The image entrypoint detects its role from the MONGO_PRIMARY_HOST variable. Delete it after the first successful deployment.
• mongo-proxy — an HAProxy edge that health-checks each node's role every 2 seconds and routes connections to the current primary only. One URL survives every failover: MONGO_PRIVATE_URL (inside Railway) and MONGO_PUBLIC_URL (through the public TCP proxy).

Drivers that handle replica-set failover natively can instead use REPLICA_SET_PRIVATE_URI (exposed on mongo1) to talk to the members directly.

Why Deploy MongoDB 9 Replica Set 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 scale it.

By deploying MongoDB 9 Replica Set on Railway, you get a production-grade HA cluster — automated elections, per-node persistent volumes, private-network replication, generated credentials, and a stable edge URL — with zero cluster administration.

Common Use Cases

• High-availability production backends: survive node failures and redeploys with automatic failover and an unchanged connection string.
• Change streams and multi-document transactions: both require a replica set — this template is one out of the box.
• Zero-downtime maintenance: restart any single node while the proxy keeps serving from the elected primary.
• Read-heavy workloads: point analytics at secondaries with REPLICA_SET_PRIVATE_URI while writes flow through the edge.

Dependencies for MongoDB 9 Replica Set Hosting

• MongoDB 9.0 (Docker Official Image + thin supervisor: keyfile bootstrap, role agent).
• HAProxy 3.2 edge with mongo-aware health checks (traffic port 27017, probe port 28017).

Deployment Dependencies

• Railway volumes on each mongo node (/data/db) for persistence.
• Railway private networking for replication traffic, role probes, and the edge.
• A Railway TCP proxy on mongo-proxy for MONGO_PUBLIC_URL (external access is optional — private-network apps don't need it).

Connect After Deployment

Grab these variables from the mongo-proxy service (auto-composed):

Operations

• Failover: automatic. Killing the primary triggers an election; the edge follows the new primary within seconds.
• Backups: snapshot each node's /data/db volume; a healthy replica set can restore from any member's data.
• Scaling: scale nodes vertically. The topology is fixed at three members.
• Upgrades: move between template versions following MongoDB release notes; replica set rollbacks follow MongoDB's supported paths.