Nic Raboy

You might have already known that MongoDB offers a [free tier](https://www.mongodb.com/pricing) through M0 clusters on MongoDB Atlas, but did you know that there are numerous ways to deploy depending on your infrastructure needs? To be clear, there's no wrong way to deploy a MongoDB Atlas cluster, but there could be an easier way to fit your operations needs.

In this article, we're going to have a quick look at the various ways you can deploy a MongoDB Atlas cluster using tools like Terraform, CloudFormation, CLIs, and simple point and click.

## Using the Atlas Web UI to Deploy a Cluster

If you're a fan of point and click deployments like I am, the web UI for MongoDB Atlas will probably fit your needs. Let's take a quick look at how to deploy a new cluster with a database using the UI found within the [MongoDB Cloud Dashboard](https://cloud.mongodb.com).

Within the **Databases** tab for your account, if you don't have any databases or clusters, you'll be presented with the opportunity to build one using the "Build a Database" button.

![Create a New MongoDB Atlas Cluster on the Web](https://mongodb-devhub-cms.s3.us-west-1.amazonaws.com/web_ui_no_databases_a91dad06e4.png "Create a New MongoDB Atlas Cluster on the Web")

Since we're keeping things free for this article, let's choose the "Shared" option when presented on the next screen. If you think you'll need something else, don't let me stop you!

After selecting "Shared" from the options, you'll be able to create a new cluster by first selecting your cloud service provider and region.

![MongoDB Atlas Cloud Service Provider](https://mongodb-devhub-cms.s3.us-west-1.amazonaws.com/web_ui_cloud_service_provider_fe6bdd877e.png "MongoDB Atlas Cloud Service Provider")

You can use the defaults, or select a provider or region that you would prefer to use. Your choice has no impact on how you will end up working with your cluster. However, choosing a provider and location that matches your other services could render performance improvements.

After selecting the "Create Cluster" button, your cluster will deploy. This could take a few minutes depending on your cluster size.

![Cluster Dashboard in MongoDB Atlas](https://mongodb-devhub-cms.s3.us-west-1.amazonaws.com/web_ui_created_cluster_e5bd23c35a.png "Cluster Dashboard in MongoDB Atlas")

At this point, you can continue exploring Atlas, create a database or two, and be on your way to creating great applications. A good next step after deploying your cluster would be adding entries to your access list. You can learn how to do that [here](https://docs.atlas.mongodb.com/security/add-ip-address-to-list/).

Let's say you prefer a more CLI-driven approach.

## Using the MongoDB CLI to Deploy a Cluster

The MongoDB CLI can be useful if you want to do script-based deployments or if you prefer to do everything from the command line.

To install the MongoDB CLI, check out the [installation documentation](https://docs.mongodb.com/mongocli/stable/install/) and follow the instructions. You'll also need to have a MongoDB Cloud account created.

If this is your first time using the MongoDB CLI, check out the [configuration documentation](https://docs.mongodb.com/mongocli/stable/configure/#std-label-mcli-configure) to learn how to add your credentials and other information.

For this example, we're going to use the quick start functionality that the CLI offers. From the CLI, execute the following:

```bash
mongocli atlas quickstart
```

Using the quick start approach, you'll be presented with a series of questions regarding how you want your Atlas cluster configured. This includes the creation of users, network access rules, and other various pieces of information.

To see some of the other options for the CLI, check out the [documentation](https://docs.mongodb.com/mongocli/master/command/mongocli-atlas-clusters-create/).

## Using the Atlas Admin API to Deploy a Cluster

A similar option to using the CLI for creating MongoDB Atlas clusters is to use the Atlas Admin API. One difference here is that you don't need to download or install any particular CLI and you can instead use HTTP requests to get the job done using anything capable of making HTTP requests.

Take the following HTTP request, for example, one that can still be executed from the command prompt:

```
curl --location --request POST 'https://cloud.mongodb.com/api/atlas/v1.0/groups/{GROUP_ID}/clusters?pretty=true' \
--user "{PUBLIC_KEY}:{PRIVATE_KEY}" --digest \
--header 'Content-Type: application/json' \
--data-raw '{
    "name": "MyCluster",
    "providerSettings": {
        "providerName": "AWS",
        "instanceSizeName": "M10",
        "regionName": "US_EAST_1"
    }
}'
```

The above cURL request is a trimmed version, containing just the required parameters, taken from the Atlas Admin API [documentation](https://docs.atlas.mongodb.com/reference/api/clusters-create-one/). You can try the above example after switching the `GROUP_ID`, `PUBLIC_KEY`, and `PRIVATE_KEY` placeholders with those found in your Atlas dashboard. The `GROUP_ID` is the project id representing where you'd like to create your cluster. The `PUBLIC_KEY` and `PRIVATE_KEY` are the keys for a particular project with proper permissions for creating clusters.

The same cURL components can be executed in a programming language or even a tool like [Postman](https://www.mongodb.com/developer/article/automate-automation-mongodb-atlas/). The Atlas Admin API is not limited to just cURL using a command line.

While you can use the Atlas Admin API to create users, apply access rules, and similar, it would take a few different HTTP requests in comparison to what we saw with the CLI because the CLI was designed to make these kinds of interactions a little easier.

For information on the other optional fields that can be used in the request, refer to the [documentation](https://docs.atlas.mongodb.com/reference/api/clusters-create-one/).

## Using HashiCorp Terraform to Deploy a Cluster

There's a chance that your organization is already using an infrastructure-as-code (IaC) solution such as Terraform. The great news is that we have a Terraform provider for MongoDB Atlas that allows you to create a free Atlas database easily.

Take the following example Terraform configuration:

```
locals {
	mongodb_atlas_api_pub_key = "PUBLIC_KEY"
	mongodb_atlas_api_pri_key = "PRIVATE_KEY"
	mongodb_atlas_org_id  = "ORG_ID"
	mongodb_atlas_project_id = "PROJECT_ID"
}

terraform {
	required_providers {
    	    mongodbatlas = {
      	        source = "mongodb/mongodbatlas"
      	        version = "1.1.1"
    	    }
	}
}

provider "mongodbatlas" {
	public_key  = local.mongodb_atlas_api_pub_key
	private_key = local.mongodb_atlas_api_pri_key
}

resource "mongodbatlas_cluster" "my_cluster" {
	project_id          	= local.mongodb_atlas_project_id
	name                	= "terraform"

	provider_name = "TENANT"
	backing_provider_name = "AWS"
	provider_region_name = "US_EAST_1"
	provider_instance_size_name = "M0"
}

output "connection_strings" {
	value = mongodbatlas_cluster.my_cluster.connection_strings.0.standard_srv
}

```

If you added the above configuration to a **main.tf** file and swapped out the information at the top of the file with your own, you could execute the following commands to deploy a cluster with Terraform:

```
terraform init
terraform plan
terraform apply
```

The configuration used in this example was taken from the Terraform template accessible within the [Visual Studio Code Extension for MongoDB](https://docs.mongodb.com/mongodb-vscode/create-cluster-terraform/). However, if you'd like to learn more about Terraform with MongoDB, check out the official provider information within the [Terraform Registry](https://registry.terraform.io/providers/mongodb/mongodbatlas/latest).

## Using AWS CloudFormation to Deploy a Cluster

If your applications are all hosted in AWS, then CloudFormation, another IaC solution, may be one you want to utilize.

If you're interested in a script-like configuration for CloudFormation, Cloud Product Manager Jason Mimick wrote a thorough tutorial titled [Get Started with MongoDB Atlas and AWS CloudFormation](https://www.mongodb.com/developer/how-to/get-started-atlas-aws-cloudformation/). However, like I mentioned earlier, I'm a fan of a point and click solution.

A point and click solution can be accomplished with AWS CloudFormation! Navigate to the [MongoDB Atlas on AWS](https://aws.amazon.com/quickstart/architecture/mongodb-atlas/) page and click "How to Deploy."

You'll have a few options, but the simplest option is to launch the Quick Start for [deploying without VPC peering](https://fwd.aws/jQ46Q).

![MongoDB Atlas with AWS CloudFormation Quick Start](https://mongodb-devhub-cms.s3.us-west-1.amazonaws.com/aws_cloud_formation_quickstart_1_718e2527e9.png "MongoDB Atlas with AWS CloudFormation Quick Start")

The next steps involve following a four-part configuration and deployment wizard.

The first step consists of selecting a configuration template.

![MongoDB Atlas with AWS CloudFormation Quick Start](https://mongodb-devhub-cms.s3.us-west-1.amazonaws.com/aws_cloud_formation_quickstart_2_03532bf71c.png "MongoDB Atlas with AWS CloudFormation Quick Start")

Unless you know your way around CloudFormation, the defaults should work fine.

The second step of the configuration wizard is for defining the configuration information for MongoDB Atlas. This is what was seen in other parts of this article.

![MongoDB Atlas with AWS CloudFormation Quick Start](https://mongodb-devhub-cms.s3.us-west-1.amazonaws.com/aws_cloud_formation_quickstart_3_9e51523d6a.png "MongoDB Atlas with AWS CloudFormation Quick Start")

Replace the fields with your own information, including the public key, private key, and organization id to be used with CloudFormation. Once more, these values can be found and configured within your [MongoDB Atlas Dashboard](https://cloud.mongodb.com).

![MongoDB Atlas with AWS CloudFormation Quick Start](https://mongodb-devhub-cms.s3.us-west-1.amazonaws.com/aws_cloud_formation_quickstart_4_93459017d0.png "MongoDB Atlas with AWS CloudFormation Quick Start")

The final stage of the configuration wizard is for defining permissions. For the sake of this article, everything in the final stage will be left with the default provided information, but feel free to use your own.

Once you review the CloudFormation configuration, you can proceed to the deployment, which could take a few minutes.

As I mentioned, if you'd prefer not to go through this wizard, you can also explore a more scripted approach using the CloudFormation and AWS CLI.

## Conclusion

You just got an introduction to some of the ways that you can deploy MongoDB Atlas clusters. Like I mentioned earlier, there isn't a wrong way, but there could be a better way depending on how you're already managing your infrastructure.

If you get stuck with your MongoDB Atlas deployment, navigate to the [MongoDB Community Forums](https://community.mongodb.com) for some help!

Learn how to quickly and easily deploy a MongoDB Atlas cluster using a variety of methods such as CloudFormation, Terraform, the CLI, and more.

5 Different Ways to Deploy a Free Database with MongoDB Atlas

Need a consistent development and deployment experience as developers work across teams and use different machines for their daily tasks? That is where Docker has you covered with containers. A common experience might include running a local version of MongoDB Community in a container and an application in another container. This strategy works for some organizations, but what if you want to leverage all the benefits that come with MongoDB Atlas in addition to a container strategy for your application development?

In this tutorial we'll see how to create a MongoDB-compatible web application, bundle it into a container with Docker, and manage creation as well as destruction for MongoDB Atlas with the [Atlas CLI](https://www.mongodb.com/docs/atlas/cli/stable/) during container deployment.

It should be noted that this tutorial was intended for a development or staging setting through your local computer. It is not advised to use all the techniques found in this tutorial in a production setting. Use your best judgment when it comes to the code included.

If you’d like to try the results of this tutorial, check out the repository and instructions on [GitHub](https://github.com/mongodb-developer/atlas-cli-docker-example).

## The prerequisites

There are a lot of moving parts in this tutorial, so you'll need a few things prior to be successful:

- A [MongoDB Atlas](https://www.mongodb.com/atlas/database) account
- [Docker](https://www.docker.com/)
- Some familiarity with Node.js and JavaScript

The [Atlas CLI](https://www.mongodb.com/docs/atlas/cli/stable/) can create an Atlas account for you along with any keys and ids, but for the scope of this tutorial you'll need one created along with quick access to the "Public API Key", "Private API Key", "Organization ID", and "Project ID" within your account. You can see how to do this in the [documentation](https://www.mongodb.com/docs/atlas/configure-api-access/#grant-programmatic-access-to-service).

Docker is going to be the true star of this tutorial. You don't need anything beyond [Docker](https://www.docker.com/) because the Node.js application and the Atlas CLI will be managed by the Docker container, not your host computer.

On your host computer, create a project directory. The name isn't important, but for this tutorial we'll use **mongodbexample** as the project directory.

## Create a simple Node.js application with Express Framework and MongoDB

We're going to start by creating a Node.js application that communicates with MongoDB using the [Node.js driver for MongoDB](https://www.mongodb.com/docs/drivers/node/current/). The application will be simple in terms of functionality. It will connect to MongoDB, create a database and collection, insert a document, and expose an API endpoint to show the document with an HTTP request.

Within the project directory, create a new **app** directory for the Node.js application to live. Within the **app** directory, using a command line, execute the following:

```bash
npm init -y
npm install express mongodb
```

If you don't have Node.js installed, just create a **package.json** file within the **app** directory with the following contents:

```json
{
    "name": "mongodbexample",
    "version": "1.0.0",
    "description": "",
    "main": "main.js",
    "scripts": {
        "test": "echo \"Error: no test specified\" && exit 1",
        "start": "node main.js"
    },
    "keywords": [],
    "author": "",
    "license": "ISC",
    "dependencies": {
        "express": "^4.18.2",
        "mongodb": "^4.12.1"
    }
}
```

Next, we'll need to define our application logic. Within the **app** directory we need to create a **main.js** file. Within the **main.js** file, add the following JavaScript code:

```javascript
const { MongoClient } = require("mongodb");
const Express = require("express");

const app = Express();

const mongoClient = new MongoClient(process.env.MONGODB_ATLAS_URI);
let database, collection;

app.get("/data", async (request, response) => {
    try {
        const results = await collection.find({}).limit(5).toArray();
        response.send(results);
    } catch (error) {
        response.status(500).send({ "message": error.message });
    }
});

const server = app.listen(3000, async () => {
    try {
        await mongoClient.connect();
        database = mongoClient.db(process.env.MONGODB_DATABASE);
        collection = database.collection(`${process.env.MONGODB_COLLECTION}`);
        collection.insertOne({ "firstname": "Nic", "lastname": "Raboy" });
        console.log("Listening at :3000");
    } catch (error) {
        console.error(error);
    }
});

process.on("SIGTERM", async () => {
    if(process.env.CLEANUP_ONDESTROY == "true") {
        await database.dropDatabase();
    }
    mongoClient.close();
    server.close(() => {
        console.log("NODE APPLICATION TERMINATED!");
    });
});
```

There's a lot happening in the few lines of code above. We're going to break it down!

Before we break down the pieces, take note of the environment variables used throughout the JavaScript code. We'll be passing these values through Docker in the end so we have a more dynamic experience with our local development.

The first important snippet of code to focus on is the start of our application service:

```javascript
const server = app.listen(3000, async () => {
    try {
        await mongoClient.connect();
        database = mongoClient.db(process.env.MONGODB_DATABASE);
        collection = database.collection(`${process.env.MONGODB_COLLECTION}`);
        collection.insertOne({ "firstname": "Nic", "lastname": "Raboy" });
        console.log("Listening at :3000");
    } catch (error) {
        console.error(error);
    }
});
```

Using the client that was configured near the top of the file, we can connect to MongoDB. Once connected, we can get a reference to a database and collection. This database and collection doesn't need to exist before that because it will be created automatically when data is inserted. With the reference to a collection, we insert a document and begin listening for API requests through HTTP.

This brings us to our one and only endpoint:

```javascript
app.get("/data", async (request, response) => {
    try {
        const results = await collection.find({}).limit(5).toArray();
        response.send(results);
    } catch (error) {
        response.status(500).send({ "message": error.message });
    }
});
```

When the `/data` endpoint is consumed, the first five documents in our collection are returned to the user. Otherwise if there was some issue, an error message would be returned.

This brings us to something optional, but potentially valuable when it comes to a Docker deployment for local development:

```javascript
process.on("SIGTERM", async () => {
    if(process.env.CLEANUP_ONDESTROY == "true") {
        await database.dropDatabase();
    }
    mongoClient.close();
    server.close(() => {
        console.log("NODE APPLICATION TERMINATED!");
    });
});
```

The above code says that when a termination event is sent to the application, drop the database we had created and close the connection to MongoDB as well as the Express Framework service. This could be useful if we want to undo everything we had created when the container stops. If you want your changes to persist, it might not be necessary. For example, if you want your data to exist between container deployments, persistence would be required. On the other hand, maybe you are using the container as part of a test pipeline and you want to clean up when you’re done, the termination commands could be valuable.

So we have an environment variable heavy Node.js application. What's next?

## Deploying a MongoDB Atlas cluster with network rules, user roles, and sample data

While we have the application, our MongoDB Atlas cluster may not be available to us. For example, maybe this is our first time being exposed to Atlas and nothing has been created yet. We need to be able to quickly and easily create a cluster, configure our IP access rules, specify users and permissions, and then connect with our Node.js application.

This is where the MongoDB Atlas CLI does the heavy lifting!

There are many different ways to create a script. Some like Bash, some like ZSH, some like something else. We're going to be using ZX which is a JavaScript wrapper for Bash.

Within your project directory, not your **app** directory, create a **docker_run_script.mjs** file with the following code:

```javascript
#!/usr/bin/env zx

$.verbose = true;

const runtimeTimestamp = Date.now();

process.env.MONGODB_CLUSTER_NAME = process.env.MONGODB_CLUSTER_NAME || "examples";
process.env.MONGODB_USERNAME = process.env.MONGODB_USERNAME || "demo";
process.env.MONGODB_PASSWORD = process.env.MONGODB_PASSWORD || "password1234";
process.env.MONGODB_DATABASE = process.env.MONGODB_DATABASE || "business_" + runtimeTimestamp;
process.env.MONGODB_COLLECTION = process.env.MONGODB_COLLECTION || "people_" + runtimeTimestamp;
process.env.CLEANUP_ONDESTROY = process.env.CLEANUP_ONDESTROY || false;

var app;

process.on("SIGTERM", () => { 
    app.kill("SIGTERM");
});

try {
    let createClusterResult = await $`atlas clusters create ${process.env.MONGODB_CLUSTER_NAME} --tier M0 --provider AWS --region US_EAST_1 --output json`;
    await $`atlas clusters watch ${process.env.MONGODB_CLUSTER_NAME}`
    let loadSampleDataResult = await $`atlas clusters loadSampleData ${process.env.MONGODB_CLUSTER_NAME} --output json`;
} catch (error) {
    console.log(error.stdout);
}

try {
    let createAccessListResult = await $`atlas accessLists create --currentIp --output json`;
    let createDatabaseUserResult = await $`atlas dbusers create --role readWriteAnyDatabase,dbAdminAnyDatabase --username ${process.env.MONGODB_USERNAME} --password ${process.env.MONGODB_PASSWORD} --output json`;
    await $`sleep 10`
} catch (error) {
    console.log(error.stdout);
}

try {
    let connectionString = await $`atlas clusters connectionStrings describe ${process.env.MONGODB_CLUSTER_NAME} --output json`;
    let parsedConnectionString = new URL(JSON.parse(connectionString.stdout).standardSrv);
    parsedConnectionString.username = encodeURIComponent(process.env.MONGODB_USERNAME);
    parsedConnectionString.password = encodeURIComponent(process.env.MONGODB_PASSWORD);
    parsedConnectionString.search = "retryWrites=true&w=majority";
    process.env.MONGODB_ATLAS_URI = parsedConnectionString.toString();
    app = $`node main.js`;
} catch (error) {
    console.log(error.stdout);
}
```

Once again, we're going to break down what's happening!

Like with the Node.js application, the ZX script will be using a lot of environment variables. In the end, these variables will be passed with Docker, but you can hard-code them at any time if you want to test things outside of Docker.

The first important thing to note is the defaulting of environment variables:

```javascript
process.env.MONGODB_CLUSTER_NAME = process.env.MONGODB_CLUSTER_NAME || "examples";
process.env.MONGODB_USERNAME = process.env.MONGODB_USERNAME || "demo";
process.env.MONGODB_PASSWORD = process.env.MONGODB_PASSWORD || "password1234";
process.env.MONGODB_DATABASE = process.env.MONGODB_DATABASE || "business_" + runtimeTimestamp;
process.env.MONGODB_COLLECTION = process.env.MONGODB_COLLECTION || "people_" + runtimeTimestamp;
process.env.CLEANUP_ONDESTROY = process.env.CLEANUP_ONDESTROY || false;
```

The above snippet isn't a requirement, but if you want to avoid setting or passing around variables, defaulting them could be helpful. In the above example, the use of `runtimeTimestamp` will allow us to create a unique database and collection should we want to. This could be useful if numerous developers plan to use the same Docker images to deploy containers because then each developer would be in a sandboxed area. If the developer chooses to undo the deployment, only their unique database and collection would be dropped.

Next we have the following:

```javascript
process.on("SIGTERM", () => { 
    app.kill("SIGTERM");
});
```

We have something similar in the Node.js application as well. We have it in the script because eventually the script controls the application. So when we (or Docker) stops the script, the same stop event is passed to the application. If we didn't do this, the application would not have a graceful shutdown and the drop logic wouldn't be applied.

Now we have three try / catch blocks, each focusing on something particular.

The first block is responsible for creating a cluster with sample data:

```javascript
try {
    let createClusterResult = await $`atlas clusters create ${process.env.MONGODB_CLUSTER_NAME} --tier M0 --provider AWS --region US_EAST_1 --output json`;
    await $`atlas clusters watch ${process.env.MONGODB_CLUSTER_NAME}`
    let loadSampleDataResult = await $`atlas clusters loadSampleData ${process.env.MONGODB_CLUSTER_NAME} --output json`;
} catch (error) {
    console.log(error.stdout);
}
```

If the cluster already exists, an error will be caught. We have three blocks because in our scenario, it is alright if certain parts already exist.

Next we worry about users and access:

```javascript
try {
    let createAccessListResult = await $`atlas accessLists create --currentIp --output json`;
    let createDatabaseUserResult = await $`atlas dbusers create --role readWriteAnyDatabase,dbAdminAnyDatabase --username ${process.env.MONGODB_USERNAME} --password ${process.env.MONGODB_PASSWORD} --output json`;
    await $`sleep 10`
} catch (error) {
    console.log(error.stdout);
}
```

We want our local IP address to be added to the access list and we want a user to be created. In this example, we are creating a user with extensive access, but you may want to refine the level of permission they have in your own project. For example, maybe the container deployment is meant to be a sandboxed experience. In this scenario, it makes sense that the user created access only the database and collection in the sandbox. We `sleep` after these commands because they are not instant and we want to make sure everything is ready before we try to connect.

Finally we try to connect:

```javascript
try {
    let connectionString = await $`atlas clusters connectionStrings describe ${process.env.MONGODB_CLUSTER_NAME} --output json`;
    let parsedConnectionString = new URL(JSON.parse(connectionString.stdout).standardSrv);
    parsedConnectionString.username = encodeURIComponent(process.env.MONGODB_USERNAME);
    parsedConnectionString.password = encodeURIComponent(process.env.MONGODB_PASSWORD);
    parsedConnectionString.search = "retryWrites=true&w=majority";
    process.env.MONGODB_ATLAS_URI = parsedConnectionString.toString();
    app = $`node main.js`;
} catch (error) {
    console.log(error.stdout);
}
```

After the first try / catch block finishes, we'll have a connection string. We can finalize our connection string with a Node.js URL object by including the username and password, then we can run our Node.js application. Remember, the environment variables and any manipulations we made to them in our script will be passed into the Node.js application.

## Transition the MongoDB Atlas workflow to containers with Docker and Docker Compose

At this point, we have an application and we have a script for preparing MongoDB Atlas and launching the application. It's time to get everything into a Docker image to be deployed as a container.

At the root of your project directory, add a **Dockerfile** file with the following:

```dockerfile
FROM node:18

WORKDIR /usr/src/app

COPY ./app/* ./
COPY ./docker_run_script.mjs ./

RUN curl https://fastdl.mongodb.org/mongocli/mongodb-atlas-cli_1.3.0_linux_x86_64.tar.gz --output mongodb-atlas-cli_1.3.0_linux_x86_64.tar.gz
RUN tar -xvf mongodb-atlas-cli_1.3.0_linux_x86_64.tar.gz && mv mongodb-atlas-cli_1.3.0_linux_x86_64 atlas_cli
RUN chmod +x atlas_cli/bin/atlas
RUN mv atlas_cli/bin/atlas /usr/bin/

RUN npm install -g zx
RUN npm install

EXPOSE 3000

CMD ["./docker_run_script.mjs"]
```

The custom Docker image will be based on a Node.js image which will allow us to run our Node.js application as well as our ZX script.

After our files are copied into the image, we run a few commands to download and extract the MongoDB Atlas CLI.

Finally, we install ZX and our application dependencies and run the ZX script. The `CMD` command for running the script is done when the container is run. Everything else is done when the image is built.

We could build our image from this **Dockerfile** file, but it is a lot easier to manage when there is a Compose configuration. Within the project directory, create a **docker-compose.yml** file with the following YAML:

```yaml
version: "3.9"
services:
    web:
        build:
            context: .
            dockerfile: Dockerfile
        ports:
            - "3000:3000"
        environment:
            MONGODB_ATLAS_PUBLIC_API_KEY: YOUR_PUBLIC_KEY_HERE
            MONGODB_ATLAS_PRIVATE_API_KEY: YOUR_PRIVATE_KEY_HERE
            MONGODB_ATLAS_ORG_ID: YOUR_ORG_ID_HERE
            MONGODB_ATLAS_PROJECT_ID: YOUR_PROJECT_ID_HERE
            MONGODB_CLUSTER_NAME: examples
            MONGODB_USERNAME: demo
            MONGODB_PASSWORD: password1234
            # MONGODB_DATABASE: sample_mflix
            # MONGODB_COLLECTION: movies
            CLEANUP_ONDESTROY: true
```

You'll want to swap the environment variable values with your own. In the above example, the database and collection variables are commented out so the defaults would be used in the ZX script.

To see everything in action, execute the following from the command line on the host computer:

```bash
docker-compose up
```

The above command will use the **docker-compose.yml** file to build the Docker image if it doesn't already exist. The build process will bundle our files, install our dependencies, and obtain the MongoDB Atlas CLI. When Compose deploys a container from the image, the environment variables will be passed to the ZX script responsible for configuring MongoDB Atlas. When ready, the ZX script will run the Node.js application, further passing the environment variables. If the `CLEANUP_ONDESTROY` variable was set to `true`, when the container is stopped the database and collection will be removed.

## Conclusion

The [MongoDB Atlas CLI](https://www.mongodb.com/docs/atlas/cli/stable/) can be a powerful tool for bringing MongoDB Atlas to your local development experience on Docker. Essentially you would be swapping out a local version of MongoDB with Atlas CLI logic to manage a more feature-rich cloud version of MongoDB.

MongoDB Atlas enhances the MongoDB experience by giving you access to more features such as Atlas Search, Charts, and App Services, which allow you to build great applications with minimal effort.

Learn how to use the MongoDB Atlas CLI with Docker in this example that includes JavaScript and Node.js.

CLI

All CLI Content

Local Development with the MongoDB Atlas CLI and Docker

5 Different Ways to Deploy a Free Database with MongoDB Atlas

Related Topics