Deploy MongoDB

Railway offers two MongoDB deployment options to accommodate different needs: a Standalone Instance and a High Availability (HA) Replica Set.

  • Standalone Instance - a single MongoDB database server that is easy to manage; ideal for development environments, smaller projects, or services that are less sensitive to disruption.

  • High Availability (HA) Replica Set - intended for production workloads where uptime is critical. It consists of three MongoDB nodes configured as a replica set.

Standalone MongoDB

Let's talk about how to deploy, connect, and manage the standalone instance.

Deploy

You can deploy a standalone MongoDB database via the CMD + K menu or by clicking the + New button on the Project Canvas.

GIF of the Adding Database

You can also deploy it via the template from the template marketplace.

Deployed Service

Upon deployment, you will have a standalone MongoDB service running in your project, deployed from the official mongo Docker image.

Custom Start Command

The MongoDB database service starts with the following Start Command to enable communication over Private Network: mongod --ipv6 --bind_ip ::,0.0.0.0

Connect

Connect to MongoDB from another service in your project by referencing the environment variables made available in the Mongo service:

  • MONGOHOST
  • MONGOPORT
  • MONGOUSER
  • MONGOPASSWORD
  • MONGO_URL

Connecting Externally

It is possible to connect to MongoDB externally (from outside of the project in which it is deployed), by using the TCP Proxy which is enabled by default.

Keep in mind that you will be billed for Network Egress when using the TCP Proxy.

Modify the Deployment

Since the deployed container is pulled from the official MongoDB image in Docker Hub, you can modify the deployment based on the instructions in Docker Hub.

High Availability MongoDB Replica Set

We'll cover how to deploy, connect, and manage the High Availability (HA) MongoDB Replica Set in this section.

Deploy

You can deploy a HA MongoDB Replica Set via the template in the marketplace.

MongoDB HA in the marketplace

Deployed Services

Upon deployment, a cluster of 3 MongoDB nodes will be added to your project. The nodes are deployed from a custom Dockerfile. The Dockerfile pulls the mongo Docker image and copies a script into the container. The script is run when the container starts to generate the keyfile for authentication.

An init service is also deployed alongside the nodes to initiate the replica set once the nodes are up. It should be deleted post-deploy.

Multi-region Deployment

By default, each node is deployed to a different region (US West, US East, and EU West) for fault tolerance.

Since region selection is a Pro-only feature, this only applies to Pro users. If you deploy this template as a Hobby user, all nodes will deploy to US West.

Connect

To connect to the MongoDB Replica Set, you should construct your MongoDB URI to include all nodes in the set. Each node exposes a REPLICA_SET_PRIVATE_URI environment variable that can be referenced to connect to the cluster.

Mongo URI variable

For some examples, check out the example apps within the source repo for the replica set.

Connecting Externally

It is possible to connect to the MongoDB Replica Set externally (from outside of the project in which it is deployed) by setting up a tunnel into the private network.

Check out this tutorial for more information on how to implement a Tailscale subnet router, to tunnel into the private network and connect to the replica set.

Modify the Deployment

Since the containers deployed are based on the MongoDB image, you can reference the documentation in Docker hub to understand how to customize them using environment variables.

You can also fork the Mongo Cluster repository to make changes not supported by environment variables.

Backup and Monitoring

Especially for production environments, performing regular backups and monitoring the health of your database is essential. Consider adding:

  • Backup solutions: Automate regular backups to ensure data recovery in case of failure. We suggest checking out this Database S3 backups template as an example.

  • Observability: Implement monitoring for insights into performance and health of your database. Check out the tutorial which covers setting up observability on a Mongo replica set.

Additional Resources

While these templates are available for your convenience, they are considered unmanaged, meaning you have total control over their configuration and maintenance.

We strongly encourage you to refer to the source documentation to gain deeper understanding of their functionality and how to use them effectively. Here are some links to help you get started:


Edit this file on GitHub