Zuhair Ahmed

Sr. Product Manager

A beginner’s guide to start deploying Atlas clusters today with Infrastructure as Code best practices

How to Deploy MongoDB Atlas with Terraform on AWS

MongoDB

Tim Kelly

Developer Advocate

Learn how to automate infrastructure management with HashiCorp Terraform and MongoDB Atlas. This tutorial covers setting up clusters, vector search, and building a Spring Boot RAG app with OpenAI embeddings for intelligent data retrieval and scalable cloud integration.

Terraforming AI Workflows: RAG With MongoDB Atlas and Spring AI

Community

Samuel Molling

This article is for anyone who intends to use or already uses infrastructure as code (IaC) on the MongoDB Atlas platform or wants to learn more about it.

MongoDB Atlas With Terraform - Cluster and Backup Policies

Aastha Mahendru

Software Engineer

As the volumes of data managed by organizations grow exponentially, effective log management becomes critical for maintaining the performance and security of database platforms. 

Automation and configuration of log management through infrastructure as code (IaC) tools can enable users to automatically push mongod, mongos, and audit logs directly to their S3 buckets instead of manually downloading zipped log files or creating any custom solutions to continuously pull logs from Atlas.

To enhance developer agility, we’re introducing a new capability that enables developer teams to push logs to an Amazon S3 bucket, providing a continuous, scalable, cost-effective solution for log storage and analysis.

This guide will walk you through how to set up push-based logging to Amazon S3 in Atlas through our [HashiCorp Terraform MongoDB Atlas provider.](https://registry.terraform.io/providers/mongodb/mongodbatlas/latest) Let’s get started! 

## Prerequisites

- Create a [MongoDB Atlas](https://www.mongodb.com/cloud/atlas/register) account. 
- Create an [AWS](https://aws.amazon.com/free/) account.
- Install [HashiCorp Terraform](https://developer.hashicorp.com/terraform/tutorials/aws-get-started/install-cli) on your terminal or sign up for a free [Terraform Cloud](https://app.terraform.io/public/signup/account) account.
- Create [MongoDB Atlas programmatic API keys](https://www.mongodb.com/docs/atlas/configure-api-access/#grant-programmatic-access-to-service) and [associate them with Terraform. ](https://www.mongodb.com/developer/products/atlas/deploy-mongodb-atlas-terraform-aws/)
- [Configure your AWS credentials](https://registry.terraform.io/providers/hashicorp/aws/latest/docs#provider-configuration) to be used with Terraform.
- Select an IDE of your choice. For this tutorial, we will be using [VS Code](https://code.visualstudio.com/).

You can enable the [push-based log export](https://www.mongodb.com/docs/atlas/push-logs/#std-label-mongodb-logs-push) feature on a project level in your Atlas organization after you have authorized your Atlas project to access the S3 bucket in your AWS account. This means all clusters in your Atlas project will be automatically configured to push logs to the S3 bucket.

So to start off, let’s give Atlas what it needs to get the appropriate permissions!

*Note that if you prefer to manage IAM roles and permissions via UI or other tools, you can accomplish this by following the appropriate steps outlined in **[Set Up Unified AWS Access](https://www.mongodb.com/docs/atlas/security/set-up-unified-aws-access/#set-up-unified-aws-access)**, skipping* **Step #2**, and configuring the appropriate roles in your Terraform configuration.* 

## Configure the Hashicorp Terraform MongoDB Atlas and AWS providers

In this tutorial, we will use Terraform to manage all operations so you don’t have to worry about jumping between your AWS Management Console, your MongoDB Atlas account, and your Terraform configuration files. This requires you to first specify the [HashiCorp Terraform MongoDB Atlas provider](https://registry.terraform.io/providers/mongodb/mongodbatlas/latest) as well as [Hashicorp Terraform AWS provider](https://registry.terraform.io/providers/hashicorp/aws/latest) versions in a **versions.tf** file as below:

```
terraform {
 required_providers {
   mongodbatlas = {
     source  = "mongodb/mongodbatlas"
     version = ">= 1.16.0"
   }
   aws = {
     source  = "hashicorp/aws"
     version = ">= 5.0"
   }
 }
 required_version = ">= 1.0"
}
```

Note: Before deploying anything, be sure to store the MongoDB Atlas programmatic API keys you created as part of the prerequisites as [environment variables](https://developer.hashicorp.com/terraform/cli/config/environment-variables), and additionally, ensure to have configured your credentials for the AWS provider. 

We will now create a **variables.tf** file for declaring Terraform variables and a **terraform.tfvars** file for defining variable values. These files are typically created within the root directory of your Terraform project.

In **variables.tf**, we will define the identifier of your Atlas organization, the name of your new Atlas project, and the name of the new S3 bucket that the logs will be pushed to:

```
# Atlas Organization ID
variable "atlas_org_id" {
 type        = string
 description = "Atlas Organization ID"
}

# Atlas Project Name
variable "atlas_project_name" {
 type        = string
 description = "Atlas Organization ID"
}

# Unique AWS S3 Bucket Name
variable "s3_bucket_name" {
 type        = string
 description = "AWS S3 Bucket Name for logs"
}
```

In the **terraform.tfvars** file, we will configure the values for the above variables:

```
atlas_org_id = "<UPDATE WITH YOUR ORG ID>"
atlas_project_name = "<UPDATE WITH A NAME FOR PROJECT>"
s3_bucket_name = "<UPDATE WITH A UNIQUE NAME FOR YOUR S3 BUCKET>"
```

We can now run `terraform init` in the terminal. This will initialize Terraform and download Terraform MongoDB Atlas and AWS providers.

![The screenshot shows that Terraform and the providers have been successfully initialized.][1]

## Set up AWS access for MongoDB Atlas

To set up unified AWS access, you must give [Organization Owner](https://www.mongodb.com/docs/atlas/reference/user-roles/#mongodb-authrole-Organization-Owner) or [Project Owner](https://www.mongodb.com/docs/atlas/reference/user-roles/#mongodb-authrole-Project-Owner) access to the Atlas project.

From here, set up cloud provider access in MongoDB Atlas. You can do this with the `mongodbatlas_cloud_provider_access_setup` resource which returns an `atlas_aws_account_arn` and `atlas_assumed_role_external_id`.

At this point, your ***.tf** configuration file should look similar to this:

```
resource "mongodbatlas_project" "exampleProject" {
 name   = var.atlas_project_name
 org_id = var.atlas_org_id
}

resource "mongodbatlas_cloud_provider_access_setup" "setupOnly" {
 project_id    = mongodbatlas_project.exampleProject.id
 provider_name = "AWS"
}
```

*If you are curious to learn more about this authorization mechanism, visit the* [*AWS docs*](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user_externalid.html)*.*

Next, create an IAM role with the `assume_role_policy` in Atlas configured with the Atlas AWS account from the previous step as the principal.

```
resource "aws_iam_role" "atlasRole" {
 name                 = "atlas-role"
 max_session_duration = 43200

 assume_role_policy = jsonencode({
   "Version" : "2012-10-17",
   "Statement" : [
     {
       "Effect" : "Allow",
       "Principal" : {
         "AWS" : "${mongodbatlas_cloud_provider_access_setup.setupOnly.aws_config[0].atlas_aws_account_arn}"
       },
       "Action" : "sts:AssumeRole",
       "Condition" : {
         "StringEquals" : {
           "sts:ExternalId" : "${mongodbatlas_cloud_provider_access_setup.setupOnly.aws_config[0].atlas_assumed_role_external_id}"
         }
       }
     }
   ]
 })
}

resource "aws_iam_role_policy" "atlasRolePolicy" {
 name = "atlas-role-policy"
 role = aws_iam_role.atlasRole.id

 policy = jsonencode({
   "Version" : "2012-10-17",
   "Statement" : [
     {
       "Effect" : "Allow",
       "Action" : "s3:*",
       "Resource" : "*"
     }
   ]
 })
}
```

Finally, use `mongodbatlas_cloud_provider_access_authorization` resource to authorize and configure the new IAM Assumed Role ARN. 

*Tip: For now, we have only authorized this role for S3 actions but once successful, you can expand the policy and use the role_id value when configuring other Atlas services that use AWS,* *such as* [*Data Federation*](https://www.mongodb.com/docs/atlas/data-federation/#std-label-atlas-data-federation) *and* [*encryption at Rest*](https://www.mongodb.com/docs/atlas/security-aws-kms/#std-label-security-aws-kms)*.*

```
resource "mongodbatlas_cloud_provider_access_authorization" "authRole" {
 project_id = mongodbatlas_project.exampleProject.id
 role_id    = mongodbatlas_cloud_provider_access_setup.setupOnly.role_id

 aws {
   iam_assumed_role_arn = aws_iam_role.atlasRole.arn
 }
}
```

## Configure an Amazon S3 bucket 

Now that you have given Atlas the authorization to Amazon S3 service, we will create a new S3 bucket (or use an existing bucket) and configure an `aws_iam_role_policy` resource to allow the previously created `atlasRole` to perform operations required for pushing the logs to this bucket:

```
resource "aws_s3_bucket" "atlasLogBucket" {
 bucket        = var.s3_bucket_name
 force_destroy = true      // required for destroying as Atlas creates a test folder in the bucket when push-based log export is initially created
}

resource "aws_iam_role_policy" "atlasLogBucketPolicy" {
 name = "atlas-log-bucket-policy"
 role = aws_iam_role.atlasRole.id

 policy = jsonencode({
   "Version" : "2012-10-17",
   "Statement" : [
     {
       "Effect" : "Allow",
       "Action" : [
         "s3:ListBucket",
         "s3:PutObject",
         "s3:GetObject",
         "s3:GetBucketLocation"
       ],
       "Resource" : [
         "${aws_s3_bucket.atlasLogBucket.arn}",
         "${aws_s3_bucket.atlasLogBucket.arn}/*"
       ]
     }
   ]
 })
}
```

Let’s deploy everything so far by running the below commands from the terminal: 

```
terraform plan
terraform apply
```

With that, you have configured your S3 bucket!

## Enable push-based log export

Coming back to where it all started, you can now very easily enable push-based log export configuration for your Atlas project. All you need is the name of the S3 bucket and the `role_id` from the `mongodbatlas_cloud_provider_access_authorization` resource. Add the below to your ***.tf** file:

```
resource "mongodbatlas_push_based_log_export" "logExport" {
 project_id  = mongodbatlas_project.exampleProject.id
 bucket_name = aws_s3_bucket.atlasLogBucket.bucket
 iam_role_id = mongodbatlas_cloud_provider_access_authorization.authRole.role_id
 prefix_path = "push-based-log-test"
}
```

To deploy again, run from the terminal: 

```
terraform plan
terraform apply
```

If your deployment was successful, you should be greeted with “Apply complete!” 

![Terraform in terminal showcasing deployment][2]

You can verify the configuration by fetching objects in the S3 bucket. You can do this by updating your Terraform configuration to include the `aws_s3_objects` data source and specify the bucket name and the prefix path like this:

```
data "aws_s3_objects" "atlasLogObjects" {
 bucket = aws_s3_bucket.atlasLogBucket.bucket
 prefix = mongodbatlas_push_based_log_export.logExport.prefix_path
}
```

List the objects in the bucket by creating an **outputs.tf** file and referencing the `keys` parameter as below:

```
output "log_bucket_keys" {
 value = data.aws_s3_objects.atlasLogObjects.keys
}
```

Run `terraform plan` followed by `terraform apply` in the terminal. You should now see an “atlas-test” object created in your S3 bucket in the outputs:

![Terraform in terminal showing objects created in Amazon S3 bucket as outputs][3]

Atlas creates this test object to verify that the IAM role configured has write access to this S3 bucket for the purposes of push-based log exporting. It is safe to delete this file once the log export configuration is successful.

Now that you have successfully configured push-based log export to your S3 bucket, as soon as a cluster is deployed in your Atlas project, you should see the logs in your configured S3 bucket. Happy logging!

## All done

Congratulations! You now have everything that you need to start pushing your MongoDB Atlas database logs to your Amazon S3 bucket.

The HashiCorp Terraform Atlas provider is open-sourced under the [Mozilla Public License v2.0](https://github.com/mongodb/terraform-provider-mongodbatlas?tab=MPL-2.0-1-ov-file) and we welcome community contributions. To learn more, see our [contributing guidelines](https://github.com/mongodb/terraform-provider-mongodbatlas/blob/master/CONTRIBUTING.md). 

The fastest way to get started is to create a MongoDB Atlas account from the [AWS Marketplace](https://aws.amazon.com/marketplace/pp/prodview-pp445qepfdy34?sr=0-2&ref_=beagle&applicationId=AWSMPContessa). To learn more about the Terraform provider, check out our [documentation](https://registry.terraform.io/providers/mongodb/mongodbatlas/latest/docs), [tutorials](https://www.mongodb.com/developer/search/?s=Terraform&sortMode=0), [solution brief](https://www.mongodb.com/collateral/build-resilient-applications-with-mongodb-atlas-and-hashicorp-terraform), or [get started](https://account.mongodb.com/account/login?signedOut=true&n=https%3A%2F%2Fcloud.mongodb.com%2Fgo%3Fl%3Dhttps%3A%2F%2Fcloud.mongodb.com%2Fv2%2F%3Cproject%3E%23%2FdataFederation%26_ga%3D2.121590028.567858162.1702935684-1592895210.1668436484%26_gac%3D1.90809704.1702935684.CjwKCAiA-P-rBhBEEiwAQEXhH1-PuNDJyW2Z4QzJDKtcrNGmvK965-IyQbQ-bitpEZxRCffLHhX-KRoC1HsQAvD_BwE) directly.

Go build with MongoDB Atlas and the HashiCorp Terraform Atlas provider today! 


  [1]: https://images.contentstack.io/v3/assets/blt39790b633ee0d5a7/blt719e8a5da077f3b7/668c54ae94a816a0f907e508/1.png
  [2]: https://images.contentstack.io/v3/assets/blt39790b633ee0d5a7/bltfb254491bf60da59/668c54c4534bb9564426eab1/2.png
  [3]: https://images.contentstack.io/v3/assets/blt39790b633ee0d5a7/bltd3faa714bbb7a907/668c54d794a8162a6907e50e/3.png

Streamlining Log Management to Amazon S3 Using Atlas Push-based Log Exports With HashiCorp Terraform

Rutuja Rajwade

Product Marketing Manager

An event-driven architecture is a highly effective framework for creating applications that are responsive, scalable, and maintainable with loosely coupled components. This approach has become essential in developing applications that can rapidly respond to customer demands and dynamic market conditions.

For example, in healthcare, event-driven systems process data emitted by medical devices (like ECGs and blood glucose monitors) to provide real-time insights and alerts to healthcare providers, enabling timely interventions. Financial institutions utilize event-driven architectures to process and analyze transactions in real time. This allows for immediate fraud detection, risk assessment, and dynamic pricing based on current market conditions.

In this tutorial, we cover how to get started with MongoDB Atlas for near real-time data processing with HashiCorp Terraform. By integrating [MongoDB Atlas Stream Processing](https://www.mongodb.com/products/platform/atlas-stream-processing) with the [HashiCorp Terraform MongoDB Atlas Provider](https://registry.terraform.io/providers/mongodb/mongodbatlas/latest), developers can efficiently manage real-time data workflows and automate resource provisioning.

Let’s get started!

## Prerequisites

- Create a [MongoDB Atlas](https://www.mongodb.com/cloud/atlas/register) account. (More configuration details will be shown below.)
- Install [HashiCorp Terraform](https://developer.hashicorp.com/terraform/tutorials/aws-get-started/install-cli) on your terminal or sign up for a free [Terraform Cloud](https://app.terraform.io/public/signup/account) account.
- Create [MongoDB Atlas programmatic API keys](https://www.mongodb.com/docs/atlas/configure-api-access/#grant-programmatic-access-to-service) and [associate them with Terraform](https://www.mongodb.com/developer/products/atlas/deploy-mongodb-atlas-terraform-aws/) (further details below).
- Choose your IDE. For this tutorial, we will be using [VS Code](https://code.visualstudio.com/).

## Deploy foundational Atlas Stream Processing resources using the Terraform provider 

There are three main components to consider with Atlas Stream Processing: 

- [Stream Processing Instance](https://www.mongodb.com/docs/atlas/atlas-sp/overview/#mongodb-expression-exp.Stream-Processing-Instance) (SPI) — This acts as the primary environment where your streaming data processes are executed. It's responsible for managing and executing the stream processing tasks, maintaining performance, and ensuring data integrity throughout the streaming lifecycle.
- [Connection registry](https://www.mongodb.com/docs/atlas/atlas-sp/overview/#mongodb-expression-exp.Connection-Registry) — This serves as the conduit between your data sources/sinks and the processing instance. It's tasked with the secure and efficient transport of streaming data, facilitating continuous data ingestion from various sources into the SPI.
- [Stream processor](https://www.mongodb.com/docs/atlas/atlas-sp/overview/#mongodb-expression-exp.Stream-Processor) — This is where the business logic for data transformation and analysis is defined and executed. Using MongoDB's expressive querying and aggregation capabilities, this component processes incoming data streams continuously, enabling immediate data manipulation and enrichment before forwarding it for storage or further processing.

At this time, the Terraform Atlas Provider supports management of the SPI ([mongodbatlas_stream_instance](https://registry.terraform.io/providers/mongodb/mongodbatlas/latest/docs/resources/stream_instance)) and connections in the Connection Registry ([mongodbatlas_stream_connection](https://registry.terraform.io/providers/mongodb/mongodbatlas/latest/docs/resources/stream_connection)), with programmatic support for stream processors coming in the future. 

First, we need to deploy basic Atlas resources to get started. As part of this tutorial, this includes an Atlas project, M10 dedicated Atlas cluster, database user, and IP access list entry. 

In addition, we will be deploying one Stream Processing Instance and two connections in the connection registry. See our Atlas Admin [Open API Specification documentation](https://www.mongodb.com/docs/atlas/reference/api-resources-spec/v2/#tag/Streams/operation/createStreamInstance) for a full list of supported cloud providers, regions, and all other parameter inputs for these resources:

- In this example, our Stream Processing Instance will be hosted on AWS us-east-1 using an SP30 tier. More information on Stream Processing tiers is available in the [documentation](https://www.mongodb.com/docs/atlas/billing/stream-processing-costs/).
- For the connection registry, we will point our data source to type [Sample](https://www.mongodb.com/docs/atlas/atlas-stream-processing/tutorial/#add-the-sample-stream-connection-to-the-connection-registry.) (solar data that we provide as a sample source to use when getting started) which is great for testing purposes. (Type Kafka is also supported.)
- For a connection to the built-in sample_stream_solar, provide a configuration file with the following syntax:

```
{
  "name": "sample_stream_solar",
  "type": "Sample"
}
```

- Our data sink will point to the M10 dedicated Atlas cluster we mentioned earlier. 
- In the sample Terraform script provided below, replace the “org_id” field, and enter your own organization’s ID and your unique username and password in the “username” and “password” fields.
- Ensure that the IP address added to the script matches the one in Terraform. If you are unsure of the IP address that you are running Terraform on (and you are performing this step from that machine), simply click “Use Current IP Address and Save”. Another option is to open up your IP access list to all, but this comes with significant potential risks. To do this, you can add the following two CIDRs: 0.0.0.0/1 and 128.0.0.0/1. These entries will open your IP access list to, at most, 4,294,967,296 (or 2^32) IPv4 addresses and should be used with caution.

See the below Terraform script as part of our `main.tf` file.

```
terraform {
  required_providers {
    mongodbatlas = {
      source = "mongodb/mongodbatlas"
    }
  }
  required_version = ">= 0.13"
}

resource "mongodbatlas_project" "testProject" {
  name   = "testProject16"
  org_id = "[YOUR ORG_ID]"
}

resource "mongodbatlas_project_ip_access_list" "testIPAccessList" {
  project_id = mongodbatlas_project.testProject.id
  ip_address = "[YOUR IP ADDRESS]"
}

resource "mongodbatlas_database_user" "testUser" {
  project_id         = mongodbatlas_project.testProject.id
  username           = "[YOUR USERNAME]"
  password           = "[YOUR PASSWORD]"
  auth_database_name = "admin"
  roles {
    role_name     = "readWrite"
    database_name = "dbforApp"
  }
}

resource "mongodbatlas_advanced_cluster" "testCluster" {
  project_id   = mongodbatlas_project.testProject.id
  name         = "testCluster"
  cluster_type = "REPLICASET"
  replication_specs {
    region_configs {
      electable_specs {
        instance_size = "M10"
        node_count    = 3
      }
      provider_name = "AWS"
      priority      = 7
      region_name   = "US_EAST_1"
    }
  }
}

resource "mongodbatlas_stream_instance" "myFirstStreamInstance" {
  project_id    = mongodbatlas_project.testProject.id
  instance_name = "myFirstStreamInstance"
  data_process_region = {
    region         = "VIRGINIA_USA"
    cloud_provider = "AWS"
  }
  stream_config = {
    tier = "SP30"
  }
}

resource "mongodbatlas_stream_connection" "dataSource" {
    project_id = mongodbatlas_project.testProject.id
    instance_name = mongodbatlas_stream_instance.myFirstStreamInstance.instance_name
    connection_name = "sample_stream_solar"
    type = "Sample"
}

resource "mongodbatlas_stream_connection" "dataSink" {
    project_id = mongodbatlas_project.testProject.id
    instance_name = mongodbatlas_stream_instance.myFirstStreamInstance.instance_name
    connection_name = "dataSink"
    type = "Cluster"
    cluster_name = mongodbatlas_advanced_cluster.testCluster.name
    db_role_to_execute = {
      role = "atlasAdmin"
      type = "BUILT_IN"
    }
}
```

Note: Before deploying, be sure to store your MongoDB Atlas programmatic API keys created as part of prerequisites as [Environment Variables](https://developer.hashicorp.com/terraform/cli/config/environment-variables). To deploy, you can use the below commands from the terminal: 

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

If your deployment was successful, you should be greeted with “Apply complete!” 

![Screenshot of completed deployment][1]

To confirm, you should be able to see your newly created SPI in the Atlas UI. (To navigate from the home screen, click on “Stream Processing” on the left-hand menu.) 

![Screenshot of Atlas UI after creation of stream processing instance][2]

By going into the Connection Registry, we can also verify that our connections were successfully created. 

![Screenshot of Atlas UI showcasing connection registry][3]

## Get connection string and create stream processor 

Next, you’ll need to retrieve the Atlas Stream Processing connection string and create your first stream processor.

While still in the Atlas UI, click “Connect” and select the tool to access your data through MongoDB Shell or MongoDB for VS Code. 

![Screenshot of Atlas UI showcasing connection to MongoDB Shell and MongoDB VSCode][4]

This will generate your connection string which you can use to connect to your Stream Processing Instance. 

At this point, your first stream processors can be created to define how your data will be processed in your SPI. As mentioned earlier, there are currently no Terraform resources as of yet to provide this configuration. To learn more about how stream processors can be configured, refer to [Manage Stream Processors](https://www.mongodb.com/docs/atlas/atlas-sp/manage-stream-processor/#manage-stream-processors).

For more detailed information, also see our [Atlas Stream Processing example](https://github.com/mongodb/terraform-provider-mongodbatlas/blob/master/examples/mongodbatlas_stream_instance/atlas-streams-user-journey.md) in our Terraform repo. 

## All done 

Congratulations! You have everything that you need now to run your first [Atlas Stream Processing](https://www.mongodb.com/docs/atlas/atlas-sp/overview/)-based workflow. 

With the above steps, teams can utilize Atlas Stream Processing capabilities within the Terraform MongoDB Atlas Provider. Whether you are developing complex event processing systems, real-time analytics, or interactive user engagement features, Atlas Stream Processing integrated with Terraform provides a robust infrastructure to support scalable and resilient applications. 

The HashiCorp Terraform Atlas Provider is open-sourced under the [Mozilla Public License v2.0](https://github.com/mongodb/terraform-provider-mongodbatlas?tab=MPL-2.0-1-ov-file) and we welcome community contributions. To learn more, see our [contributing guidelines](https://github.com/mongodb/terraform-provider-mongodbatlas/blob/master/CONTRIBUTING.md). 

The fastest way to get started is to create a MongoDB Atlas account from the [AWS Marketplace](https://aws.amazon.com/marketplace/seller-profile?id=c9032c7b-70dd-459f-834f-c1e23cf3d092). To learn more about the Terraform Provider, check out our [documentation](https://registry.terraform.io/providers/mongodb/mongodbatlas/latest/docs), [tutorials](https://www.mongodb.com/developer/search/?s=Terraform&sortMode=0), [solution brief](https://www.mongodb.com/collateral/build-resilient-applications-with-mongodb-atlas-and-hashicorp-terraform), or [get started today](https://cloud.mongodb.com).

Go build with MongoDB Atlas and the HashiCorp Terraform Atlas Provider today! 


  [1]: https://images.contentstack.io/v3/assets/blt39790b633ee0d5a7/bltd8b6fd1c026e0dfa/664bc07e1983ea56f5ac2899/1.png
  [2]: https://images.contentstack.io/v3/assets/blt39790b633ee0d5a7/bltc57e0777ae3b69f3/664bc0907853391c269e3c1f/2.png
  [3]: https://images.contentstack.io/v3/assets/blt39790b633ee0d5a7/bltb73dbc3b43a2e8a0/664bc09f941bc85c3f9df7b1/3.png
  [4]: https://images.contentstack.io/v3/assets/blt39790b633ee0d5a7/blt6e9c931aa8a32787/664bc0ae55b39716c16049d8/4.png

How to Get Started with MongoDB Atlas Stream Processing and the HashiCorp Terraform MongoDB Atlas Provider

Last year, MongoDB announced the general availability of [Atlas Vector Search](https://www.mongodb.com/blog/post/introducing-atlas-vector-search-build-intelligent-applications-semantic-search-ai), a new capability in Atlas that allows developers to search across data stored in MongoDB based on its semantic meaning using high dimensional vectors (i.e., “embeddings”) created by machine learning models. 

This allows developers to build intelligent applications that can understand and process human language in a way traditional, text-based search methods cannot since they will only produce an exact match for the query. 

For example, searching for “warm winter jackets” on an e-commerce website that only supports text-based search might return products with the exact match keywords "warm," "winter," and "jackets." Vector search, on the other hand, understands the semantic meaning of "warm winter jackets'' as apparel designed for cold temperatures. It retrieves items that are not only labeled as "winter jackets” but are specifically designed for warmth, including products that might be described with related terms like "insulated," giving users more helpful search results. 

Integrating Atlas Vector Search with infrastructure-as-code (IaC) tools like HashiCorp Terraform can then streamline and optimize your development workflows, ensuring that sophisticated search capabilities are built directly into the infrastructure deployment process. 

This guide will walk you through how to get started with Atlas Vector Search through our [HashiCorp Terraform Atlas provider](https://registry.terraform.io/providers/mongodb/mongodbatlas/latest). Let’s get started! 

### Pre-requisites

 - Create a [MongoDB Atlas](https://www.mongodb.com/cloud/atlas/register) account. 
 - Install [HashiCorp Terraform](https://developer.hashicorp.com/terraform/tutorials/aws-get-started/install-cli) on your terminal or sign up for a free [Terraform Cloud](https://app.terraform.io/public/signup/account) account.
 - Create [MongoDB Atlas programmatic API keys](https://www.mongodb.com/docs/atlas/configure-api-access/#grant-programmatic-access-to-service) and [associate them with Terraform](https://www.mongodb.com/developer/products/atlas/deploy-mongodb-atlas-terraform-aws/). 
 - Select an IDE of your choice. For this tutorial, we will be using [VS Code](https://code.visualstudio.com/).

## Step 1: Deploy Atlas dedicated cluster with Atlas Search Nodes

First, we need to deploy basic Atlas resources to get started. This includes an Atlas project, an M10 dedicated Atlas cluster (which is pay-as-you-go, great for development and low-traffic applications), a database user, and an IP Access List Entry. 

**Note**: When configuring your MongoDB Atlas cluster with Terraform, it's important to restrict IP access to only the IP address from which the Terraform script will be deployed. This minimizes the risk of unauthorized access. 

In addition, as part of this tutorial, we will be using [Atlas Search Nodes](https://www.mongodb.com/blog/post/search-nodes-now-public-preview-performance-scale-dedicated-infrastructure) (optional). These provide dedicated infrastructure for [Atlas Search](https://www.mongodb.com/cloud/atlas/lp/search) and [Vector Search](https://www.mongodb.com/products/platform/atlas-vector-search) workloads, allowing you to fully scale search independent of database needs. Incorporating Search Nodes into your Atlas deployment allows for better performance at scale and delivers workload isolation, higher availability, and the ability to optimize resource usage. 

Lastly, when using Terraform to manage infrastructure, it is recommended to maintain organized file management practices. Typically, your Terraform configurations/scripts will be written in files with the `.tf` extension, such as `main.tf`. This file, which we are using in this tutorial, contains the primary configuration details for deploying resources and should be located ideally in a dedicated project directory on your local machine or on Terraform Cloud. 

See the below Terraform script as part of our `main.tf` file: 

```
terraform {
  required_providers {
    mongodbatlas = {
      source = "mongodb/mongodbatlas"
    }
  }
  required_version = ">= 0.13"
}

resource "mongodbatlas_project" "exampleProject" {
  name   = "exampleProject"
  org_id = "63234d3234ec0946eedcd7da"
}

resource "mongodbatlas_advanced_cluster" "exampleCluster" {
  project_id   = mongodbatlas_project.exampleProject.id
  name         = "ClusterExample"
  cluster_type = "REPLICASET"

  replication_specs {
    region_configs {
      electable_specs {
        instance_size = "M10"
        node_count    = 3
      }
      provider_name = "AWS"
      priority      = 7
      region_name   = "US_EAST_1"
    }
  }
}

resource "mongodbatlas_search_deployment" "exampleSearchNode" {
  project_id   = mongodbatlas_project.exampleProject.id
  cluster_name = mongodbatlas_advanced_cluster.exampleCluster.name
  specs = [
    {
      instance_size = "S20_HIGHCPU_NVME"
      node_count    = 2
    }
  ]
}

resource "mongodbatlas_database_user" "testUser" {
  username           = "username123"
  password           = "password-test123"
  project_id         = mongodbatlas_project.exampleProject.id
  auth_database_name = "admin"

  roles {
    role_name     = "readWrite"
    database_name = "dbforApp"
  }
}

resource "mongodbatlas_project_ip_access_list" "test" {
  project_id = mongodbatlas_project.exampleProject.id
  ip_address = "174.218.210.1"
}
```

**Note**: Before deploying, be sure to store your MongoDB Atlas programmatic API keys created as part of the prerequisites as [environment variables](https://developer.hashicorp.com/terraform/cli/config/environment-variables). To deploy, you can use the below commands from the terminal: 

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

## Step 2: Create your collections with vector data 

For this tutorial, you can create your own collection of vectorized data if you have data to use. 

Alternatively, you can use our [sample data](https://www.mongodb.com/docs/atlas/sample-data/). This is great for testing purposes. The collection you can use is the "sample_mflix.embedded_movies" which already has embeddings generated by Open AI. 

To use sample data, from the Atlas UI, go into the Atlas cluster Overview page and select “Atlas Search” at the top of the menu presented. 
![(Cluster Overview in the Atlas UI)](https://images.contentstack.io/v3/assets/blt39790b633ee0d5a7/blt5c0ebd39059d0e07/6627cb3b776d0cbe1d24d57a/Screenshot_2024-04-23_at_10.52.09_AM.png)

Then, click “Load a Sample Dataset.”
![(Atlas Search menu in the Atlas UI)](https://images.contentstack.io/v3/assets/blt39790b633ee0d5a7/bltae4597ed96ca2b63/6627cb85210d90f4f03a44b4/Screenshot_2024-04-23_at_10.53.44_AM.png)

## Step 3: Add vector search index in Terraform configuration 

Now, head back over to Terraform and create an Atlas Search index with type “vectorSearch.” If you are using the sample data, also include a reference to the database “sample_mflix” and the collection “embedded_movies.” 

Lastly, you will need to set the “fields” parameter as per our example below. See our documentation to learn more about [how to index fields for vector search](https://www.mongodb.com/docs/atlas/atlas-vector-search/vector-search-type/#how-to-index-fields-for-vector-search) and the associated required parameters. 

```
resource "mongodbatlas_search_index" "test-basic-search-vector" {
  name   = "test-basic-search-index"  
  project_id = mongodbatlas_project.exampleProject.id
  cluster_name = mongodbatlas_advanced_cluster.exampleCluster.name
  type = "vectorSearch"
  database = "sample_mflix"
  collection_name = "embedded_movies"
  fields = <<-EOF
    [{
        "type": "vector",
        "path": "plot_embedding",
        "numDimensions": 1536,
        "similarity": "euclidean"
    }]
    EOF
}
```

To deploy again, you can use the below commands from the terminal: 
```
terraform init 
terraform plan
terraform apply 
```

If your deployment was successful, you should be greeted with “Apply complete!” 
![(Terraform in terminal showcasing deployment)](https://images.contentstack.io/v3/assets/blt39790b633ee0d5a7/bltded5c4cdf9b4a083/6627cbeae7ce95db12de9b09/Screenshot_2024-04-23_at_10.55.27_AM.png)

To confirm, you should be able to see your newly created Atlas Search index resource in the Atlas UI with Index Type “vectorSearch” and Status as “ACTIVE.” 
![(Atlas UI showcasing Vector Search deployment)](https://images.contentstack.io/v3/assets/blt39790b633ee0d5a7/blt23db256850afad56/6627cc13bb637218621defb9/Screenshot_2024-04-23_at_10.56.10_AM.png)

## Step 4: Get connection string and connect to the MongoDB Shell to begin Atlas Vector Search queries 

While still in the Atlas UI, go back to the homepage, click “Connect” on your Atlas cluster, and select “Shell.” 

![(Atlas UI page where you can choose a cluster connection method)](https://images.contentstack.io/v3/assets/blt39790b633ee0d5a7/blt95d147e9c622bd5d/6627cc47e7ce95a8b8de9b1a/Screenshot_2024-04-23_at_10.56.59_AM.png)

This will generate your connection string which you can use in the MongoDB Shell to connect to your Atlas cluster. 

### All done

Congratulations! You have everything that you need now to run your first [Vector Search queries](https://www.mongodb.com/docs/atlas/atlas-vector-search/vector-search-stage/).

With the above steps, teams can leverage Atlas Vector Search indexes and dedicated Search Nodes for the Terraform MongoDB Atlas provider to build a retrieval-augmented generation, semantic search, or recommendation system with ease. 

The HashiCorp Terraform Atlas provider is open-sourced under the [Mozilla Public License v2.0](https://github.com/mongodb/terraform-provider-mongodbatlas?tab=MPL-2.0-1-ov-file) and we welcome community contributions. To learn more, see our [contributing guidelines](https://github.com/mongodb/terraform-provider-mongodbatlas/blob/master/CONTRIBUTING.md).

The fastest way to get started is to create a MongoDB Atlas account from the [AWS Marketplace](https://aws.amazon.com/marketplace/seller-profile?id=c9032c7b-70dd-459f-834f-c1e23cf3d092) or [Google Cloud Marketplace](https://console.cloud.google.com/marketplace/product/mongodb/mdb-atlas-self-service?pli=). To learn more about the Terraform provider, check out the [documentation](https://registry.terraform.io/providers/mongodb/mongodbatlas/latest/docs), [solution brief](https://www.mongodb.com/collateral/build-resilient-applications-with-mongodb-atlas-and-hashicorp-terraform), and [tutorials](https://www.mongodb.com/developer/search/?s=Terraform&sortMode=0), or [get started today](https://account.mongodb.com/account/login?signedOut=true&n=https%3A%2F%2Fcloud.mongodb.com%2Fgo%3Fl%3Dhttps%253A%252F%252Fcloud.mongodb.com%252Fv2%252F%253Cproject%253E%2523%252FdataFederation%26_ga%3D2.121590028.567858162.1702935684-1592895210.1668436484%26_gac%3D1.90809704.1702935684.CjwKCAiA-P-rBhBEEiwAQEXhH1-PuNDJyW2Z4QzJDKtcrNGmvK965-IyQbQ-bitpEZxRCffLHhX-KRoC1HsQAvD_BwE).  

Go build with MongoDB Atlas and the HashiCorp Terraform Atlas provider today! 



Learn how to leverage Atlas Vector Search with HashiCorp Terraform in this tutorial.

Leveraging Atlas Vector Search With HashiCorp Terraform: Empowering Semantic Search in Modern Applications

In this tutorial, I will show how to create a user for the MongoDB database in Atlas using Terraform and how to store this credential securely in HashiCorp Vault. We saw in the previous article, [MongoDB Atlas With Terraform - Cluster and Backup Policies](https://www.mongodb.com/developer/products/atlas/atlas-terraform-cluster-backup-policies/), how to create a cluster with configured backup policies. Now, we will go ahead and create our first user. If you haven't seen the previous articles, I suggest you look to understand how to get started.

This article is for anyone who intends to use or already uses infrastructure as code (IaC) on the MongoDB Atlas platform or wants to learn more about it.

Everything we do here is contained in the provider/resource documentation: 

 - [mongodbatlas_database_user](https://registry.terraform.io/providers/mongodb/mongodbatlas/latest/docs/resources/database_user)
- [vault_kv_secret_v2](https://registry.terraform.io/providers/hashicorp/vault/latest/docs/resources/kv_secret_v2)

> Note: We will not use a backend file. However, for productive implementations, it is extremely important and safer to store the state file in a remote location such as [S3](https://developer.hashicorp.com/terraform/language/settings/backends/s3), [GCS](https://developer.hashicorp.com/terraform/language/settings/backends/gcs), [Azurerm](https://developer.hashicorp.com/terraform/language/settings/backends/azurerm), etc.

## Creating a User
At this point, we will create our first user using Terraform in MongoDB Atlas and store the URI to connect to my cluster in HashiCorp Vault. For those unfamiliar, [HashiCorp Vault](https://www.hashicorp.com/products/vault) is a secrets management tool that allows you to securely store, access, and manage sensitive credentials such as passwords, API keys, certificates, and more. It is designed to help organizations protect their data and infrastructure in complex, distributed IT environments. In it, we will store the connection URI of the user that will be created with the cluster we created in the [last article](https://www.mongodb.com/developer/products/atlas/atlas-terraform-cluster-backup-policies/).

Before we begin, make sure that all the prerequisites mentioned in the previous article are properly configured: Install [Terraform](https://developer.hashicorp.com/terraform/tutorials/aws-get-started/install-cli), create an API key in MongoDB Atlas, and set up a project and a cluster in Atlas. These steps are essential to ensure the success of creating your database user.

### Configuring HashiCorp Vault to run on Docker
The first step is to run HashiCorp Vault so that we can test our module. It is possible to run Vault on Docker Local. If you don't have Docker installed, you can [download it](https://docs.docker.com/engine/install/). After downloading Docker, we will download the image we want to run — in this case, from Vault. To do this, we will execute a command in the terminal `docker pull vault:1.13.3` or download using Docker Desktop.

![Looking for the image in docker][1]

Now, we will create a container from this image. Click on the image and click on **Run**. After this, a box will open where we only need to map the port from our computer to the container. In this case, I will use port 8200 which is the Vault's default port. Click **Run**.

![Screen to configure docker port][2]

The container will start running. If we go to our browser and enter the URL `localhost:8200/`, the Vault login screen will appear.

![Vault sign in screen][3]

To access the Vault, we will use the Root Token that is generated when we create the container.

![Log screen containing token][4]

Now, we will log in. After opening, we will create a new KV-type engine just to illustrate it a little better. Click **Secrets Engines** -> Enable new Engine -> Generic KV and click **Next**.

![Secrets engine selection screen][5]

In Path, put `kv/my_app` and click on **Enable Engine**. Now, we have our Vault configured and working.

## Terraform provider configuration for MongoDB Atlas and HashiCorp Vault
The next step is to configure the Terraform provider. This will allow Terraform to communicate with the MongoDB Atlas and Vault API to manage resources. Add the following block of code to your providers.tf file:

```
provider "mongodbatlas" {}
provider "vault" {
  address = "http://localhost:8200"
  token = "hvs.brmNeZd31NwEmyky1uYI2wvY"
  skip_child_token = true
}
```

In the previous article, we configured the Terraform provider by placing our public and private keys in environment variables. We will continue in this way. We will add a new provider, the Vault. In it, we will configure the Vault address, the authentication token, and the skip_child_token parameter so that we can authenticate to the Vault.
> Note: It is not advisable to specify the authentication token in a production environment. Use one of the authentication methods recommended by HashiCorp, such as app_role. You can evaluate the options [in Terraform’s docs](https://registry.terraform.io/providers/hashicorp/vault/latest/docs)

## Creating the Terraform version file
The version file continues to have the same purpose, as mentioned in other articles, but we will add the version of the Vault provider as something new.

```
terraform {
    required_version = ">= 0.12"
    required_providers {
        mongodbatlas = {
            source = "mongodb/mongodbatlas"
            version = "1.14.0"
        }
        vault = {
            source = "hashicorp/vault"
            version = "4.0.0"
        }
    }
}
```
### Defining the database user and vault resource
After configuring the version file and establishing the Terraform and provider versions, the next step is to define the user resource in MongoDB Atlas. This is done by creating a .tf file — for example, main.tf — where we will create our module. As we are going to make a module that will be reusable, we will use variables and default values so that other calls can create users with different permissions, without having to write a new module.

```
# ------------------------------------------------------------------------------
# RANDOM PASSWORD
# ------------------------------------------------------------------------------
resource "random_password" "default" {
    length = var.password_length
    special = false
}

# ------------------------------------------------------------------------------
# DATABASE USER
# ------------------------------------------------------------------------------
resource "mongodbatlas_database_user" "default" {
    project_id = data.mongodbatlas_project.default.id
    username = var.username
    password = random_password.default.result
    auth_database_name = var.auth_database_name

    dynamic "roles" {
        for_each = var.roles
        content {
            role_name = try(roles.value["role_name"], null)
            database_name = try(roles.value["database_name"], null)
            collection_name = try(roles.value["collection_name"], null)
        }
    }

    dynamic "scopes" {
        for_each = var.scope
        content {
            name = scopes.value["name"]
            type = scopes.value["type"]
        }
    }


    dynamic "labels" {
        for_each = local.tags
        content {
            key = labels.key
            value = labels.value
        }
    }
}

resource "vault_kv_secret_v2" "default" {
    mount = var.vault_mount
    name = var.secret_name
    data_json = jsonencode(local.secret)
}
```

At the beginning of the file, we have the random_password resource that is used to generate a random password for our user. In the mongodbatlas_database_user resource, we will specify our user details. We are placing some values as variables as done in other articles, such as name and auth_database_name with a default value of admin. Below, we create three dynamic blocks: roles, scopes, and labels. For roles, it is a list of maps that can contain the name of the role (read, readWrite, or some other), the database_name, and the collection_name. These values can be optional if you create a user with atlasAdmin permission, as in this case, it does not. It is necessary to specify a database or collection, or if you wanted, to specify only the database and not a specific collection. We will do an example. For the scopes block, the type is a DATA_LAKE or a CLUSTER. In our case, we will specify a cluster, which is the name of our created cluster, the demo cluster. And the labels serve as tags for our user.

Finally, we define the vault_kv_secret_v2 resource that will create a secret in our Vault. It receives the mount where it will be created and the name of the secret. The data_json is the value of the secret; we are creating it in the locals.tf file that we will evaluate below. It is a JSON value — that is why we are encoding it.

In the variable.tf file, we create variables with default values:
```
variable "project_name" {
    description = "The name of the Atlas project"
    type = string
}

variable "cluster_name" {
    description = "The name of the Atlas cluster"
    type = string
}

variable "password_length" {
    description = "The length of the password"
    type = number
    default = 20
}

variable "username" {
    description = "The username of the database user"
    type = string
}

variable "auth_database_name" {
    description = "The name of the database in which the user is created"
    type = string
    default = "admin"
}

variable "roles" {
    description = <<HEREDOC
    Required - One or more user roles blocks.
    HEREDOC
    type = list(map(string))
}

variable "scope" {
    description = "The scopes to assign to the user"
    type = list(object({
        name = string
        type = string
    }))
    default = []
}

variable "labels" {
    type = map(any)
    default = null
    description = "A JSON containing additional labels"
}

variable "uri_options" {
    type = string
    default = "retryWrites=true&w=majority&readPreference=secondaryPreferred"
    description = "A string containing additional URI configs"
}

variable "vault_mount" {
    description = "The mount point for the Vault secret"
    type = string
}

variable "secret_name" {
    description = "The name of the Vault secret"
    type = string
}

variable "application" {
    description = <<HEREDOC
    Optional - Key-value pairs that tag and categorize the cluster for billing and organizational purposes.
    HEREDOC
    type = string
}

variable "environment" {
    description = <<HEREDOC
    Optional - Key-value pairs that tag and categorize the cluster for billing and organizational purposes.
    HEREDOC
    type = string
}
```

We configured a file called **locals.tf** with the values for our Vault and the tags that were created, like the last article. The interesting thing here is that we are defining how our user's connection string will be assembled and saved in the Vault. We could only save the username and password too, but I personally prefer to save the URI. This way, I can specify some good practices such as defining connection tags, such as readPreference, without depending on the developer to place it in the application. In the code below, there are some text treatments so that the URI is correct. At the end, I create a variable called **secret** that has a URI key and receives the value of the created URI.

```terraform
locals {
    private_connection_srv = data.mongodbatlas_advanced_cluster.default.connection_strings.0.standard_srv
    cluster_uri = trimprefix(local.private_connection_srv, "mongodb+srv://")
    private_connection_string = "mongodb+srv://${mongodbatlas_database_user.default.username}:${random_password.default.result}@${local.cluster_uri}/${var.auth_database_name}?${var.uri_options}"

    secret = { "URI" = local.private_connection_string }

    tags = {
    name = var.application
    environment = var.environment
    }
}
```
In this article, we adopt the use of data sources in Terraform to establish a dynamic connection with existing resources, such as our MongoDB Atlas project and our cluster. Specifically, in the data.tf file, we define a data source, mongodbatlas_project and mongodbatlas_advanced_cluster, to access information about an existing project and cluster based on its name:

```terraform
data "mongodbatlas_project" "default" {
    name = var.project_name
}


data "mongodbatlas_advanced_cluster" "default" {
    project_id = data.mongodbatlas_project.default.id
    name = var.cluster_name
}
```

Finally, we define our variables file, terraform.tfvars:

```terraform
project_name = "project-test"
username = "usr_myapp"
application = "teste-cluster"
environment = "dev"
cluster_name = "cluster-demo"

roles = [{
        "role_name" = "readWrite",
        "database_name" = "db1",
        "collection_name" = "collection1"
    }, {
        "role_name" : "read",
        "database_name" : "db2"
}]

scope = [{
    name = "cluster-demo",
    type = "CLUSTER"
}]

secret_name = "MY_MONGODB_SECRET"
vault_mount = "kv/my_app"
```
These values defined in terraform.tfvars are used by Terraform to populate corresponding variables in your configuration. In it, we are specifying the user's scope, values for the Vault, and our user's roles. The user will have readWrite permission on db1 in collection1 and read permission on db2 in all collections for the demo cluster.

The file structure is as follows:

 - main.tf: In this file, we will define the main resource, the mongodbatlas_database_user and vault_kv_secret_v2, along with a random password generation. Here, you have configured the cluster and backup routines. 
 - provider.tf: This file is where we define the provider we are using, in our case, mongodbatlas and Vault.
 - terraform.tfvars: This file contains the variables that will be used in our module — for example, the user name and Vault information, among others.
 - variable.tf: Here, we define the variables mentioned in the terraform.tfvars file, specifying the type and, optionally, a default value.
 - version.tf: This file is used to specify the version of Terraform and the providers we are using.
 - data.tf: Here, we specify a datasource that will bring us information about our project and created cluster. We will search for its name and for our module, it will give us the project ID and cluster information such as its connection string.
 - locals.tf: We specify example tags to use in our user and treatments to create the URI in the Vault.

Now is the time to apply. =D

We run a Terraform init in the terminal in the folder where the files are located so that it downloads the providers, modules, etc…

> Note: Remember to export the environment variables with the public and private key.

```terraform
export MONGODB_ATLAS_PUBLIC_KEY="your_public_key"
export MONGODB_ATLAS_PRIVATE_KEY=your_private_key"
```

Now, we run init and then plan, as in previous articles.

We assess that our plan is exactly what we expect and run the apply to create it.

When running the `terraform apply` command, you will be prompted for approval with `yes` or `no`. Type `yes`.

Now, let's look in Atlas to see if the user was created successfully...

![User displayed in database access][6]

![Access permissions displayed][7]

Let's also look in the Vault to see if our secret was created.

![MongoDB secret URI][8]

It was created successfully! Now, let's test if the URI is working perfectly.

This is the format of the URI that is generated:
`mongosh "mongodb+srv://usr_myapp:<password>@<clusterEndpoint>/admin?retryWrites=true&majority&readPreference=secondaryPreferred"`

![Mongosh login ][9]

We connect and will make an insertion to evaluate whether the permissions are adequate — initially, in db1 in collection1.

![Command to insert to db and acknowledged][10]

Success! Now, in db3, make sure it will not have permission in another database.

![Access denied to unauthroized collection][11]
Excellent — permission denied, as expected.

We have reached the end of this series of articles about MongoDB. I hope they were enlightening and useful for you!

To learn more about MongoDB and various tools, I invite you to visit the [Developer Center](https://www.mongodb.com/developer/) to read the other articles.


  [1]: https://images.contentstack.io/v3/assets/blt39790b633ee0d5a7/blt3adf134a1cc654f8/661cefe94c473591d2ee4ca7/image2.png
  [2]: https://images.contentstack.io/v3/assets/blt39790b633ee0d5a7/blt01b4534800d306c0/661cefe912f2752a7aeff578/image8.png
  [3]: https://images.contentstack.io/v3/assets/blt39790b633ee0d5a7/bltabb003cbf7efb6fa/661cefe936f462858244ec50/image1.png
  [4]: https://images.contentstack.io/v3/assets/blt39790b633ee0d5a7/blt2c34530c41490c28/661cefe90aca6b12ed3273b3/image7.png
  [5]: https://images.contentstack.io/v3/assets/blt39790b633ee0d5a7/blt867d41655e363848/661cefe931ff3a1d35a41344/image9.png
  [6]: https://images.contentstack.io/v3/assets/blt39790b633ee0d5a7/bltcdaf7406e85f79d5/661cefe936f462543444ec54/image3.png
  [7]: https://images.contentstack.io/v3/assets/blt39790b633ee0d5a7/bltbb0d0b37cd3e7e23/661cefe91c390d5d3c98ec3d/image10.png
  [8]: https://images.contentstack.io/v3/assets/blt39790b633ee0d5a7/blt0dc4c9ad575c4118/661cefe9ba18470cf69b8c14/image6.png
  [9]: https://images.contentstack.io/v3/assets/blt39790b633ee0d5a7/bltc6c61799f656701f/661cf85d4c4735186bee4ce7/image5.png
  [10]: https://images.contentstack.io/v3/assets/blt39790b633ee0d5a7/bltdd01eaae2a3d9d24/661cefe936f462254644ec58/image11.png
  [11]: https://images.contentstack.io/v3/assets/blt39790b633ee0d5a7/blt05fe248cb479b18a/661cf85d4c47359b89ee4ce5/image4.png

Learn how to create a user for MongoDB and secure their credentials securely in Hashicorp Vault.

MongoDB Atlas With Terraform: Database Users and Vault

In this tutorial, I will show you how to start using MongoDB Atlas with Terraform and create some simple resources. This first part is simpler and more introductory, but in the next article, I will explore more complex items and how to connect the creation of several resources into a single module. The tutorial is aimed at people who want to maintain their infrastructure as code (IaC) in a standardized and simple way. If you already use or want to use IaC on the MongoDB Atlas platform, this article is for you.

What are modules?

They are code containers for multiple resources that are used together. They serve several important purposes in building and managing infrastructure as code, such as:

 1. Code reuse.
 2. Organization.
 3. Encapsulation.
 4. Version management.
 5. Ease of maintenance and scalability.
 6. Sharing in the community.

Everything we do here is contained in the [provider/resource documentation](https://registry.terraform.io/providers/mongodb/mongodbatlas/latest/docs/resources/project).

> Note: We will not use a backend file. However, for productive implementations, it is extremely important and safer to store the state file in a remote location such as an [S3](https://developer.hashicorp.com/terraform/language/settings/backends/s3), [GCS](https://developer.hashicorp.com/terraform/language/settings/backends/gcs), [Azurerm](https://developer.hashicorp.com/terraform/language/settings/backends/azurerm), etc…

## Creating a project

In this first step, we will dive into the process of creating a project using Terraform. Terraform is a powerful infrastructure-as-code tool that allows you to manage and provision IT resources in an efficient and predictable way. By using it in conjunction with MongoDB Atlas, you can automate the creation and management of database resources in the cloud, ensuring a consistent and reliable infrastructure.

To get started, you'll need to install [Terraform](https://developer.hashicorp.com/terraform/tutorials/aws-get-started/install-cli) in your development environment. This step is crucial as it is the basis for running all the scripts and infrastructure definitions we will create. After installation, the next step is to configure Terraform to work with MongoDB Atlas. You will need an API key that has permission to create a project at this time.

To create an API key, you must:
 1. Select **Access Manager** at the top of the page, and click **Organization Access**. 
 2. Click **Create API Key**.
    ![Organization Access Manager for your organization][1]
 3. Enter a brief description of the API key and the necessary permission. In this case, I put it as Organization Owner. After that, click **Next**.
    ![Screen to create your API key][2]
 4. Your API key will be displayed on the screen.
    ![Screen with information about your API key][3]
 5. Release IP in the Access List (optional): If you have enabled your organization to use API keys, the requestor's IP must be released in the Access List; you must include your IP in this list. To validate whether it is enabled or not, go to **Organization Settings -> Require IP Access List** for the Atlas Administration API. In my case, it is disabled, as it is just a demonstration, but in case you are using this in an organization, I strongly advise you to enable it.
    ![Validate whether the IP Require Access List for APIs is enabled in Organization Settings][4]

After creating an API key, let's start working with Terraform. You can use the IDE of your choice; I will be using VS Code. Create the files within a folder. The files we will need at this point are:
 - main.tf: In this file, we will define the main resource, `mongodbatlas_project`. Here, you will configure the project name and organization ID, as well as other specific settings, such as teams, limits, and alert settings.
 - provider.tf: This file is where we define the provider we are using — in our case, `mongodbatlas`. Here, you will also include the access credentials, such as the API key.
 - terraform.tfvars: This file contains the variables that will be used in our project — for example, the project name, team information, and limits, among others.
 - variable.tf: Here, we define the variables mentioned in the terraform.tfvars file, specifying the type and, optionally, a default value.
 - version.tf: This file is used to specify the version of Terraform and the providers we are using.

The main.tf file is the heart of our Terraform project. In it, you start with the data source declaration `mongodbatlas_roles_org_id` to obtain the `org_id`, which is essential for creating the project.
Next, you define the `mongodbatlas_project` resource with several settings. Here are some examples:
 - `name` and `org_id` are basic settings for the project name and organization ID.
 - Dynamic blocks are used to dynamically configure teams and limits, allowing flexibility and code reuse.
 - Other settings, like `with_default_alerts_settings` and `is_data_explorer_enabled`, are options for customizing the behavior of your MongoDB Atlas project.

In the main.tf file, we will then add our project resource, called `mongodbatlas_project`.

```tf
data "mongodbatlas_roles_org_id" "org" {}

resource "mongodbatlas_project" "default" {
 name   = var.name
 org_id = data.mongodbatlas_roles_org_id.org.org_id

 dynamic "teams" {
   for_each = var.teams
   content {
     team_id    = teams.value.team_id
     role_names = teams.value.role_names
   }
 }

 dynamic "limits" {
   for_each = var.limits
   content {
     name  = limits.value.name
     value = limits.value.value
   }
 }

 with_default_alerts_settings                     = var.with_default_alerts_settings
 is_collect_database_specifics_statistics_enabled = var.is_collect_database_specifics_statistics_enabled
 is_data_explorer_enabled                         = var.is_data_explorer_enabled
 is_extended_storage_sizes_enabled                = var.is_extended_storage_sizes_enabled
 is_performance_advisor_enabled                   = var.is_performance_advisor_enabled
 is_realtime_performance_panel_enabled            = var.is_realtime_performance_panel_enabled
 is_schema_advisor_enabled                        = var.is_schema_advisor_enabled
}
```

In the provider file, we will define the provider we are using and the API key that will be used. As we are just testing, I will specify the API key as a variable that we will input into our code. However, when you are using it in production, you will not want to pass the API key in the code in exposed text, so it is possible to pass it through environment variables or even AWS secret manager.
```tf
provider "mongodbatlas" {
   public_key  = var.atlas_public_key
   private_key = var.atlas_private_key
}
```

In the variable.tf file, we will specify the variables that we are waiting for a user to pass. As I mentioned earlier, the API key is an example.
```tf
variable "name" {
 description = <<HEREDOC
   The name of the project you want to create.
   HEREDOC
 type        = string
}

variable "teams" {
 description = <<HEREDOC
   The list of teams that belong to the project.
   The roles can be:
   Organization:
       ORG_OWNER
       ORG_MEMBER
       ORG_GROUP_CREATOR
       ORG_BILLING_ADMIN
       ORG_READ_ONLY
   Project:
       GROUP_CLUSTER_MANAGER
       GROUP_DATA_ACCESS_ADMIN
       GROUP_DATA_ACCESS_READ_ONLY
       GROUP_DATA_ACCESS_READ_WRITE
       GROUP_OWNER
       GROUP_READ_ONLY
   HEREDOC
 type = list(object({
   team_id    = string
   role_names = list(string)
 }))
 default = []
}

variable "is_collect_database_specifics_statistics_enabled" {
 description = <<HEREDOC
   If true, Atlas collects and stores database-specific statistics for the specified project.
   HEREDOC
 type        = bool
 default     = true
}

variable "is_data_explorer_enabled" {
 description = <<HEREDOC
   If true, Atlas enables Data Explorer for the specified project.
   HEREDOC
 type        = bool
 default     = false
}

variable "is_extended_storage_sizes_enabled" {
 description = <<HEREDOC
   If true, Atlas enables extended storage sizes for the specified project.
   HEREDOC
 type        = bool
 default     = true
}

variable "is_performance_advisor_enabled" {
 description = <<HEREDOC
   If true, Atlas enables Performance Advisor for the specified project.
   HEREDOC
 type        = bool
 default     = true
}


variable "is_realtime_performance_panel_enabled" {
 description = <<HEREDOC
   If true, Atlas enables the Real Time Performance Panel for the specified project.
   HEREDOC
 type        = bool
 default     = true
}


variable "is_schema_advisor_enabled" {
 description = <<HEREDOC
   If true, Atlas enables Schema Advisor for the specified project.
   HEREDOC
 type        = bool
 default     = true
}


variable "with_default_alerts_settings" {
 description = <<HEREDOC
   If true, Atlas enables default alerts settings for the specified project.
   HEREDOC
 type        = bool
 default     = true
}


variable "limits" {
 description = <<HEREDOC
   Allows one to configure a variety of limits to a Project. The limits attribute is optional.
   https://www.mongodb.com/docs/atlas/reference/api-resources-spec/v2/#tag/Projects/operation/setProjectLimit
   HEREDOC
 type = list(object({
   name  = string
   value = string
 }))


 default = []
}


variable "atlas_public_key" {
 description = <<HEREDOC
   The public key of the Atlas user you want to use to create the project.
   HEREDOC
 type        = string
}


variable "atlas_private_key" {
 description = <<HEREDOC
   The private key of the Atlas user you want to use to create the project.
   HEREDOC
 type        = string
}
```

As you can see, we are placing several variables. The idea is that we can reuse the module to create different projects that have different specifications. For example, one needs the data from the databases to be visible on the Atlas Platform, so we put the `is_data_explorer_enabled` variable as `True`. On the other hand, if, for some security reason, the company does not want users to use the platform for data visualization, it is possible to specify it as `False`, and the Collections button that we have when we enter the cluster within Atlas will disappear.

In the versions.tf file, we specify the version of Terraform we use and the necessary providers with their respective versions. This configuration is crucial so that the code always runs in the same version, avoiding inconsistencies and incompatibilities that may arise with updates.

Here is what our providers file will look like:
```tf
terraform {
   required_version = ">= 0.12"
   required_providers {
       mongodbatlas = {
           source = "mongodb/mongodbatlas"
           version = "1.14.0"
       }
   }
}
```
 - `required_version = ">= 0.12"`: This line specifies that your Terraform project requires, at a minimum, Terraform version 0.12. By using >=, you indicate that any version of Terraform from 0.12 onward is compatible with your project. This offers some flexibility by allowing team members and automation systems to use newer versions of Terraform as long as they are not older than 0.12.
 - `required_providers`: This section lists the providers required for your Terraform project. In your case, you are specifying the mongodbatlas provider.
 - `source = "mongodb/mongodbatlas"`: This defines the source of the mongodbatlas provider. Here, mongodb/mongodbatlas is the official identifier of the MongoDB Atlas provider in the Terraform Registry.
 - `version = "1.14.0":` This line specifies the exact version of the mongodbatlas provider that your project will use, which is version 1.14.0. Unlike Terraform configuration, where we specify a minimum version, here you are defining a provider-specific version. This ensures that everyone using your code will work with the same version of the provider, avoiding discrepancies and issues related to version differences.

Finally, we have the variable file that will be included in our code, .tfvars.
```tf
name = "project-test"
atlas_public_key = "YOUR PUBLIC KEY"
atlas_private_key = "YOUR PRIVATE KEY"
```

We are specifying the value of the name variable, which is the name of the project and the public/private key of our provider. You may wonder, "Where are the other variables that we specified in the main.tf and variable.tf files?" The answer is: These variables were specified with a default value within the variable.tf file — for example, the limits value:
```tf
variable "limits" {
 description = <<HEREDOC
   Allows one to configure a variety of limits to a Project. The limits attribute is optional.
   https://www.mongodb.com/docs/atlas/reference/api-resources-spec/v2/#tag/Projects/operation/setProjectLimit
   HEREDOC
 type = list(object({
   name  = string
   value = string
 }))
 default = []
}
```

We are saying that if no information is passed in .tfvars, the default value is empty. This means that it will not create any limit rules for our project. If we want to specify a limit, we just put the following variable in .tfvars:
```tf
name              = "project-test"
atlas_public_key  = "YOUR PUBLIC KEY"
atlas_private_key = "YOUR PRIVATE KEY"
limits = [{
 "name" : "atlas.project.deployment.clusters",
 "value" : 26
 }, {
 "name" : "atlas.project.deployment.nodesPerPrivateLinkRegion",
 "value" : 51
}]
```

Now is the time to apply. =D

We run a `terraform init` in the terminal in the folder where the files are located so that it downloads the providers, modules, etc…

Now that init has worked, let's run the plan and evaluate what will happen. You can run the plan, like this `terraform plan`:
```console
samuelmolling@Samuels-MacBook-Pro project % terraform plan
data.mongodbatlas_roles_org_id.org: Reading...
data.mongodbatlas_roles_org_id.org: Read complete after 0s [id=5d7072c9014b769c4bd89f60]

Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols:
   + create

Terraform will perform the following actions:

   # mongodbatlas_project.default will be created
   + resource "mongodbatlas_project" "default" {
       + cluster_count = (known after apply)
       + created = (known after apply)
       + id = (known after apply)
       + is_collect_database_specifics_statistics_enabled = true
       + is_data_explorer_enabled = false
       + is_extended_storage_sizes_enabled = true
       + is_performance_advisor_enabled = true
       + is_realtime_performance_panel_enabled = true
       + is_schema_advisor_enabled = true
       + name = "project-test"
       + org_id = "5d7072c9014b769c4bd89f60"
       + with_default_alerts_settings = true

       + limits {
           + current_usage = (known after apply)
           + default_limit = (known after apply)
           + maximum_limit = (known after apply)
           + name = "atlas.project.deployment.clusters"
           + value = 26
         }
       + limits {
           + current_usage = (known after apply)
           + default_limit = (known after apply)
           + maximum_limit = (known after apply)
           + name = "atlas.project.deployment.nodesPerPrivateLinkRegion"
           + value = 51
         }
     }

Plan: 1 to add, 0 to change, 0 to destroy.

───────────────────────────────────────── ───────── ───────────────────────────────────────── ───────── ───────────────────────────────────────── ───────── ───────────────────────────────────────── ────

Note: You didn't use the -out option to save this plan, so Terraform can't guarantee to take exactly these actions if you run `terraform apply` now.
```

Show! It was exactly the output we expected to see: the creation of a project resource, with some limits and `is_data_explorer_enabled` set to False. Let's apply this!

When you run the command `terraform apply`, you will be asked for approval with `yes` or `no`. Type `yes`.
```console
samuelmolling@Samuels-MacBook-Pro project % terraform apply
data.mongodbatlas_roles_org_id.org: Reading...
data.mongodbatlas_roles_org_id.org: Read complete after 0s [id=5d7072c9014b769c4bd89f60]

Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols:
   + create

Terraform will perform the following actions:

   # mongodbatlas_project.default will be created
   + resource "mongodbatlas_project" "default" {
       + cluster_count = (known after apply)
       + created = (known after apply)
       + id = (known after apply)
       + is_collect_database_specifics_statistics_enabled = true
       + is_data_explorer_enabled = false
       + is_extended_storage_sizes_enabled = true
       + is_performance_advisor_enabled = true
       + is_realtime_performance_panel_enabled = true
       + is_schema_advisor_enabled = true
       + name = "project-test"
       + org_id = "5d7072c9014b769c4bd89f60"
       + with_default_alerts_settings = true

       + limits {
           + current_usage = (known after apply)
           + default_limit = (known after apply)
           + maximum_limit = (known after apply)
           + name = "atlas.project.deployment.clusters"
           + value = 26
         }
       + limits {
           + current_usage = (known after apply)
           + default_limit = (known after apply)
           + maximum_limit = (known after apply)
           + name = "atlas.project.deployment.nodesPerPrivateLinkRegion"
           + value = 51
         }
     }

Plan: 1 to add, 0 to change, 0 to destroy.

Do you want to perform these actions?
   Terraform will perform the actions described above.
   Only 'yes' will be accepted to approve.

   Enter a value: yes

mongodbatlas_project.default: Creating...
mongodbatlas_project.default: Creation complete after 9s [id=659ed54eb3343935e840ce1f]

Apply complete! Resources: 1 added, 0 changed, 0 destroyed.
```

Now, let's look at Atlas to see if the project was created successfully...

![MongoDB Atlas view of our project][5]

It worked!

In this tutorial, we saw how to create our first API key. We created a project using Terraform and our first module. In an upcoming article, we’ll look at how to create a cluster and user using Terraform and Atlas.

To learn more about MongoDB and various tools, I invite you to enter the [Developer Center](https://www.mongodb.com/developer/) to read the other articles.

  [1]: https://images.contentstack.io/v3/assets/blt39790b633ee0d5a7/blt4febcb777b3987da/65af88cec3bf069197fe083c/image1.png
  [2]: https://images.contentstack.io/v3/assets/blt39790b633ee0d5a7/bltb484eb33048284e2/65af88cec3bf061522fe0840/image3.png
  [3]: https://images.contentstack.io/v3/assets/blt39790b633ee0d5a7/blt322b2cb5a1505843/65af88cedf8733067dcdc1f3/image5.png
  [4]: https://images.contentstack.io/v3/assets/blt39790b633ee0d5a7/bltf51cdf161ede323e/65af88ce18af000fd20a9124/image2.png
  [5]: https://images.contentstack.io/v3/assets/blt39790b633ee0d5a7/blt7ff9636ae3df9340/65af88cec7bb161d62a2a593/image4.png

Learn how to get started with organising your MongoDB deployment with Terraform, using code to build and maintain your infrastructure.

MongoDB Atlas with Terraform

*This article was originally written by Aja Hammerly and Abirami Sukumaran, developer advocates from Google.*

Serverless computing promises the ability to spend less time on infrastructure and more time on developing your application. But historically, if you used serverless offerings from different vendors you didn't see this benefit. Instead, you often spent a significant amount of time configuring the different products and ensuring they can communicate with each other. We want to make this easier for everyone. We've started by using HashiCorp Terraform to make it easier to provision resources to run the MEAN stack on Cloud Run with MongoDB Atlas as your database. If you want to try it out, our GitHub repository is here: [https://github.com/GoogleCloudPlatform/terraform-mean-cloudrun-mongodb](https://github.com/GoogleCloudPlatform/terraform-mean-cloudrun-mongodb)

## MEAN Stack Basics

If you aren't familiar, the [MEAN stack](https://www.mongodb.com/mean-stack) is a technology stack for building web applications. The MEAN stack is composed of four main components—MongoDB, Express, Angular, and Node.js.

* MongoDB is responsible for data storage
* Express.js is a Node.js web application framework for building APIs
* Angular is a client-side JavaScript platform
* Node.js is a server-side JavaScript runtime environment. The server uses the MongoDB Node.js driver to connect to the database and retrieve and store data

Our project runs the MEAN stack on Cloud Run (Express, Node) and MongoDB Atlas (MongoDB).

The repository uses a sample application to make it easy to understand all the pieces. In the sample used in this experiment, we have a client and server application packaged in individual containers each that use the MongoDB-Node.js driver to connect to the MongoDB Atlas database.

Below we'll talk about how we used Terraform to make deploying and configuring this stack easier for developers and how you can try it yourself.

## Required One-Time Setup

To use these scripts, you'll need to have both MongoDB Atlas and Google Cloud accounts.

### MongoDB Atlas Setup

1. Login with your MongoDB Atlas Account.
2. Once you're logged in, click on "Access Manager" at the top and select "Organization Access"

![organization access](https://mongodb-devhub-cms.s3.us-west-1.amazonaws.com/organization_access_42968c44e5.png)

3. Select the "API Keys" tab and click the "Create API Key" button
4. Give your new key a short description and select the "Organization Owner" permission
5. Click "Next" and then make a note of your public and private keys
6. Next, you'll need your Organization ID. In the left navigation menu, click “Settings”. 

7. Locate your Organization ID and copy it.

![organization settings](https://mongodb-devhub-cms.s3.us-west-1.amazonaws.com/organization_settings_9bfefb6845.png)

That's everything for Atlas. Now you're ready to move on to setting up Google Cloud!

### Google Cloud Tooling and Setup
You'll need a billing account setup on your Google Cloud account and to make note of your Billing Account ID. You can find your Billing Account ID on the [billing page](https://console.cloud.google.com/billing/00D737-88ECBD-3F7424?project=next-demo-363322).

You'll also need to pick a [region](https://cloud.google.com/compute/docs/regions-zones) for your infrastructure. Note that Google Cloud and Atlas use different names for the same region. You can find a mapping between Atlas regions and Google Cloud regions [here](https://www.mongodb.com/docs/atlas/reference/google-gcp/). You'll need a region that supports the M0 cluster tier. Choose a region close to you and make a note of both the Google Cloud and Atlas region names.

Finally, you'll need a terminal with the [Google Cloud CLI](https://cloud.google.com/sdk/docs/install-sdk) (gcloud) and [Terraform](https://www.terraform.io/downloads) installed. You can use your workstation or try [Cloud Shell](https://cloud.google.com/shell), which has these tools already installed. To get started in Cloud Shell with the repo cloned and ready to configure, [click here](https://shell.cloud.google.com/cloudshell/editor?cloudshell_git_repo=https://github.com/GoogleCloudPlatform/terraform-mean-cloudrun-mongodb).

### Configuring the Demo

If you haven't already, clone [this repo](https://github.com/GoogleCloudPlatform/terraform-mean-cloudrun-mongodb). Run `terraform init` to make sure Terraform is working correctly and download the provider plugins. Then, create a file in the root of the repository called `terraform.tfvars` with the following contents, replacing placeholders as necessary:

*atlas\_pub\_key          = "\<your Atlas public key>"*

*atlas\_priv\_key         = "\<your Atlas private key>"*

*atlas\_org\_id           = "\<your Atlas organization ID>"*

*google\_billing\_account = "\<your billing account ID>"*

If you selected the *us-central1/US\_CENTRAL* region then you're ready to go. If you selected a different region, add the following to your `terraform.tfvars ` file:

atlas\_cluster\_region = "\<Atlas region ID>"

google\_cloud\_region  = "\<Google Cloud region ID>"

Run terraform init again to make sure there are no new errors. If you get an error, check your terraform.tfvars file.

### Deploy the Demo

You're ready to deploy! You have two options: you can run `terraform plan` to see a full listing of everything that Terraform wants to do without any risk of accidentally creating those resources. If everything looks good, you can then run `terraform apply` to execute the plan.

Alternately, you can just run terraform apply on its own and it will create a plan and display it before prompting you to continue. You can learn more about the plan and apply commands in [this tutorial](https://learn.hashicorp.com/tutorials/terraform/plan). For this demo, we're going to just run `terraform apply`:

![running terraform apply](https://mongodb-devhub-cms.s3.us-west-1.amazonaws.com/image3_Zd_D_Pl7_W_max_2000x2000_5610c7b9f5.png)

If everything looks good to you, type yes and press enter. This will take a few minutes. When it's done, Terraform will display the URL of your application:

![terraform URL of application](https://mongodb-devhub-cms.s3.us-west-1.amazonaws.com/image6_8tpnxe_Y_max_800x800_07d449032f.png)

Open that URL in your browser and you'll see the sample app running.

### Cleaning Up
When you're done, run terraform destroy to clean everything up:

![run terraform destroy to clean up](https://mongodb-devhub-cms.s3.us-west-1.amazonaws.com/image5_Bo_Zgc_Tn_max_2000x2000_c8bcf14c87.png)

If you're sure you want to tear everything down, type yes and press enter. This will take a few minutes. When Terraform is done everything it created will have been destroyed and you will not be billed for any further usage.

## Next Steps

You can use the code in this repository to deploy your own applications. Out of the box, it will work with any application that runs in a single container and reads the MongoDB connection string from an environment variable called ATLAS\_URI, but the Terraform code can easily be modified if you have different needs or to support more complex applications.

For more information please refer to the [Next Steps](https://github.com/GoogleCloudPlatform/terraform-mean-cloudrun-mongodb/blob/main/README.md#next-steps) section of the readme.

Learn about using HashiCorp Terraform to make it easier to provision resources to run the MEAN stack on Cloud Run with MongoDB Atlas as your database. 

Easy Deployment of MEAN Stack with MongoDB Atlas, Cloud Run, and HashiCorp Terraform

Terraform is an open-source infrastructure-as-configuration software tool created by HashiCorp.

Terraform

Featured

Terraforming AI Workflows: RAG With MongoDB Atlas and Spring AI

MongoDB Atlas With Terraform - Cluster and Backup Policies

Streamlining Log Management to Amazon S3 Using Atlas Push-based Log Exports With HashiCorp Terraform

All Terraform Content