# Provisioning a MongoDB Atlas cluster > Part of Prisma's Data Guide. The complete index is at https://www.prisma.io/dataguide/llms.txt. Learn how to provision a MongoDB Atlas cluster: choose between Free, Flex and Dedicated tiers, pick a region and version, lock down network access and database users, and script it all with the Atlas CLI. Canonical URL: https://www.prisma.io/dataguide/mongodb/mongodb-atlas-setup Content revision: d63a2962984e4d7c087fa26169ff1009afa41a14fcb2bf7e1baeeeb77cc2fed6 Source revision: 1fe7ef3d9287b7c3aadd4cd0d2fe478dafd71727 Last updated: 2026-09-30 ## Introduction MongoDB Atlas is [MongoDB's](https://www.prisma.io/dataguide/intro/database-glossary#mongodb) managed database service. It runs your [cluster](https://www.prisma.io/dataguide/intro/database-glossary#cluster) on AWS, Google Cloud or Microsoft Azure and takes care of provisioning, patching and monitoring, and on paid tiers, backups. Every Atlas cluster is a [replica set](https://www.prisma.io/dataguide/intro/database-glossary#replication), or a sharded cluster built from replica sets, so features that need one, such as [transactions](https://www.prisma.io/dataguide/mongodb/mongodb-transactions), work without extra setup. This guide explains the decisions you make when you create a cluster and then shows how to make them with the Atlas CLI, so that the setup is repeatable. The Atlas web interface asks the same questions, but its screens change often; for click-by-click steps, follow MongoDB's [Create a Cluster](https://www.mongodb.com/docs/atlas/tutorial/create-new-cluster/) tutorial. To run MongoDB on your own machine instead, see [Setting up a local MongoDB database](https://www.prisma.io/dataguide/mongodb/setting-up-a-local-mongodb-database). ## How Atlas is organized After you [register for Atlas](https://www.mongodb.com/cloud/atlas/register), your account belongs to an **organization**, which holds the billing settings and one or more **projects**. A project holds up to 25 clusters, and it's where network access and database users are defined: IP access list entries apply to every cluster in the project, and so do database users unless you restrict them to specific clusters. That makes projects a natural boundary between environments. If development and production live in separate projects, a development password can't open the production database. Keep the two kinds of users apart: **Atlas users** sign in to the Atlas UI, CLI or Administration API to manage infrastructure, while **database users** are the credentials that applications and tools such as `mongosh` use to read and write data. ## Choosing a cluster tier The tier decides how much hardware your cluster gets, whether it shares that hardware with other customers, and which Atlas features you can use. As of September 2026, Atlas offers three kinds of clusters: | | Free | Flex | Dedicated (`M10` and up) | | :------------------------- | :-------------------- | :------------------------------------- | :----------------------------------------------- | | Hardware | Shared | Shared | Each node on its own instance | | Storage (data and indexes) | 512 MB | 5 GB | 10 GB to 4 TB, depending on tier | | Operations per second | 100 | 500 | Sized by tier (RAM, vCPUs, storage) | | Backups | None | One daily snapshot | Configurable snapshots and point-in-time restore | | Private networking | No | No | Private endpoints and network peering | | MongoDB version | 8.0, managed by Atlas | 8.0, managed by Atlas | Your choice of supported version | | Cost | Free, one per project | Billed hourly, capped at $30 per month | Billed hourly by tier, storage and region | These figures come from MongoDB's [Free cluster limits](https://www.mongodb.com/docs/atlas/reference/free-shared-limitations/), [Flex cluster limits](https://www.mongodb.com/docs/atlas/reference/flex-limitations/) and [Flex pricing](https://www.mongodb.com/docs/atlas/billing/atlas-flex-costs/) pages, and they change over time. **Free clusters** (`M0` in the CLI and API) are for learning and prototypes. They also allow at most 500 connections and 10 GB of data in and 10 GB out per seven days, and Atlas pauses them after 30 days without connections. **Flex clusters** are the low-cost option for development, proofs of concept and small or spiky workloads. They replaced the shared `M2` and `M5` tiers and the serverless instances, which you haven't been able to create since February 2025. Since January 22, 2026, Atlas no longer supports them at all: existing `M2` and `M5` clusters became Flex clusters, and serverless instances were migrated to Free, Flex or dedicated clusters depending on their usage. **Dedicated clusters** give each node its own instance and unlock the full Atlas feature set. `M10` and `M20` suit development and low-traffic production, but they use burstable infrastructure: after a burst, the cloud provider caps their CPU, which can throttle a heavy workload. MongoDB recommends `M30` and larger for production, and `M30` is also the smallest tier that can be sharded. You aren't locked in: you can later scale a Free cluster to Flex or dedicated, and a Flex cluster to dedicated. Dedicated clusters can also change tier automatically: cluster-tier auto-scaling is on by default when you create a cluster in the Atlas UI, but off by default through the Administration API, which the Atlas CLI uses. The UI may also offer **Atlas Infinite**, a new edition of dedicated clusters that separates compute from storage. It's in public preview, limited to selected AWS regions and doesn't support sharding yet. This guide uses the default edition, Atlas Core; the commands below create Atlas Core clusters. ## Choosing a cloud provider and region Put the cluster on the same cloud provider and in the same region as the application that uses it. Every query crosses the network between them, so distance adds latency to every round trip, and traffic between regions or providers can add data transfer charges. Prefer regions that Atlas marks as recommended. On AWS, for example, these have at least three availability zones, and Atlas puts one node of a three-node replica set in each, so losing a zone still leaves a majority. Free and Flex clusters are available only in a subset of regions, while dedicated clusters can also span several regions or cloud providers. The Atlas CLI uses Atlas's own region names, such as `US_EAST_1` for AWS `us-east-1`. Once you're logged in, you can list the regions available for a provider and tier: ```bash atlas clusters availableRegions list --provider AWS --tier M10 ``` Choose the cluster name with care, too. Atlas builds the cluster's hostname from it, and you can't rename a cluster after it's deployed. Names can be up to 64 characters and shouldn't contain sensitive information. ## Choosing a MongoDB version Free and Flex clusters run the version Atlas chooses (MongoDB 8.0 in September 2026), and Atlas upgrades them for you. On dedicated clusters, you choose between two release cadences: - **A major version**, such as 8.0. Atlas applies patch releases automatically, and you decide when to move to the next major version, which lets you test the upgrade in staging first. - **The latest version with automatic upgrades.** Atlas also moves the cluster to new minor and major releases, including the rapid releases between major versions (8.3 at the time of writing). [MongoDB 8.0 is supported until October 31, 2029](https://www.mongodb.com/legal/support-policy/lifecycles), and 7.0 until August 31, 2027. MongoDB 9.0 was released in September 2026, but when this was written Atlas's [version availability table](https://www.mongodb.com/docs/atlas/atlas-versions/) didn't list it for dedicated clusters yet. For a new cluster on a major-version cadence, choose 8.0. Atlas emails you at least six months before a version reaches end of life and upgrades the cluster after that date. ## Securing access to the cluster Unless you set up private networking, clients reach an Atlas cluster over the public internet, so three layers protect it: which networks can connect, which credentials are accepted, and encryption. ### Network access Over the public internet, Atlas accepts client connections only from addresses on the project's [IP access list](https://www.mongodb.com/docs/atlas/security/ip-access-list/). Each entry is a single IP address or a CIDR range. Keep the list short: - For development, add your current public IP address. Temporary entries, which Atlas removes automatically within a week, suit one-off access from somewhere new. - For production, add the outbound IP addresses of your application servers. - Avoid `0.0.0.0/0`. It lets anyone on the internet try to log in, leaving passwords as the only defense, and Atlas emails the project's members when someone adds it. If your hosting platform can't give you stable outbound addresses, look for a private networking option first. Dedicated clusters can avoid the public internet altogether. [Private endpoints](https://www.mongodb.com/docs/atlas/security-private-endpoint/) (AWS PrivateLink, Azure Private Link and Google Cloud Private Service Connect) and network peering keep traffic on the cloud provider's private network. Free and Flex clusters support neither, which is one more reason to run production on a dedicated tier. ### Database users [Database users](https://www.mongodb.com/docs/atlas/security-add-mongodb-users/) can authenticate with a password (SCRAM, the default), an X.509 client certificate, OIDC (workforce identity federation for people, workload identity federation for applications on Azure or Google Cloud; MongoDB 7.0 and later) or AWS IAM. Free and Flex clusters support only passwords, X.509 and AWS IAM. Where your platform supports them, MongoDB recommends the federated options and AWS IAM over passwords, because they avoid long-lived secrets. Give each user only the access it needs. Besides built-in roles such as `atlasAdmin`, `readWriteAnyDatabase` and `readAnyDatabase`, Atlas lets you grant specific privileges on one database or collection, such as `readWrite` on `appdb`, and define custom roles. The user that `atlas setup` creates gets `atlasAdmin`, and MongoDB's docs say the Atlas UI's connect dialog offers to create an Atlas Admin user when a project has none, so check the roles of any user the Atlas UI created for you. Admin rights are fine for a sandbox, but an application should have its own user with `readWrite` on its own database. For short-lived access, Atlas can create temporary users that it deletes automatically within a week. Manage database users only through the Atlas UI, the Atlas CLI or the Administration API: Atlas rolls back user changes made any other way, so the `db.createUser()` approach from [How to manage users and authentication in MongoDB](https://www.prisma.io/dataguide/mongodb/configuring-mongodb-user-accounts-and-authentication) is for self-managed servers. The role concepts in [How to manage authorization and privileges in MongoDB](https://www.prisma.io/dataguide/mongodb/authorization-and-privileges) apply to Atlas too. ### Encryption Atlas requires TLS for every connection. It supports TLS 1.2 and 1.3 and rejects 1.0 and 1.1. On dedicated clusters, you can raise the minimum TLS version the cluster accepts; before you require 1.3, check that your drivers, language runtime and operating system support it. Free and Flex clusters also require clients that support the TLS SNI extension, as `mongosh` does. You don't need to turn anything on: connection strings that start with `mongodb+srv://` enable TLS automatically. Atlas also [encrypts cluster storage and snapshot volumes at rest](https://www.mongodb.com/docs/atlas/setup-cluster-security/) with AES-256 by default, with keys managed by the cloud provider. Dedicated clusters can add encryption with your own keys in AWS KMS, Azure Key Vault or Google Cloud KMS. For background, see [How MongoDB encrypts data](https://www.prisma.io/dataguide/mongodb/mongodb-encryption). ## Planning backups What Atlas backs up depends on the tier: - **Free clusters** have no backups. Export data yourself with `mongodump` and restore it with `mongorestore` (see [MongoDB database tools](https://www.prisma.io/dataguide/mongodb/mongodb-database-tools)). - **Flex clusters** always have backups: one snapshot a day, starting 24 hours after you create the cluster, and Atlas keeps the last eight. You can't change the schedule, take on-demand snapshots or restore to a point in time. - **Dedicated clusters** use [Cloud Backup](https://www.mongodb.com/docs/atlas/backup/cloud-backup/overview/), which you turn on per cluster. It takes snapshots on a schedule and keeps them according to a retention policy you configure. Continuous Cloud Backup adds point-in-time restore by replaying the oplog up to the moment you choose. Deleting a cluster also deletes its snapshots, unless you choose to keep them when you terminate it in the Atlas UI or a Backup Compliance Policy retains them. Export anything you need to keep before you delete a cluster, and test restores regularly. [Backup considerations](https://www.prisma.io/dataguide/managing-databases/backup-considerations) covers how to choose a strategy. ## Provisioning a cluster with the Atlas CLI The [Atlas CLI](https://www.mongodb.com/docs/atlas/cli/current/) manages Atlas from the terminal, so you can script cluster creation and keep it in version control. The commands in this section use Atlas CLI 1.59.0. ### Installing and logging in With Homebrew on macOS or Linux, this installs the Atlas CLI together with `mongosh`: ```bash brew install mongodb-atlas-cli ``` MongoDB also provides `apt` and `yum` packages, a Chocolatey package for Windows, a Docker image and downloadable binaries; see [Install or Update the Atlas CLI](https://www.mongodb.com/docs/atlas/cli/current/install-atlas-cli/). Then log in: ```bash atlas auth login ``` For interactive use, choose the user account option. The command prints a one-time code and a URL and opens the browser when you press Enter (`--noBrowser` skips that). After you sign in and paste the code, you pick a default organization and project, which the CLI saves in a profile. Later commands act on that project unless you pass `--projectId`. For scripts and CI, log in with a service account or API key instead. ### The quick way: `atlas setup` For a sandbox, `atlas setup` does everything in one go: it logs you in if needed, creates a Free cluster with a database user, and can connect you with `mongosh` when it's done. ```bash atlas setup --clusterName sandbox --provider AWS --region US_EAST_1 --currentIp --skipSampleData ``` `--currentIp` adds the public IP address of the machine you run the command on to the access list, and `--skipSampleData` skips loading MongoDB's sample datasets. The database user this creates has the `atlasAdmin` role, so don't reuse it in an application. ### Step by step For clusters that will hold real data, create each piece separately so you choose every setting. `atlas clusters create` creates a Flex cluster unless you pass another `--tier`, such as `M0` for a Free cluster: ```bash atlas clusters create dev-cluster --provider AWS --region US_EAST_1 --tier FLEX atlas clusters watch dev-cluster ``` `atlas clusters watch` waits until the cluster is ready. A production cluster needs a few more decisions: ```bash atlas clusters create prod-cluster \ --provider AWS --region US_EAST_1 \ --tier M30 --diskSizeGB 40 --mdbVersion 8.0 \ --backup --enableTerminationProtection ``` - `--tier M30` is the smallest tier MongoDB recommends for production. The CLI creates a three-member replica set by default. - `--diskSizeGB` sets the storage for each node. Set it explicitly for dedicated tiers, because the CLI's default is 2 GB. - `--mdbVersion 8.0` keeps the cluster on the 8.0 major version. - `--backup` turns on Continuous Cloud Backup, so you can restore to a point in time. - `--enableTerminationProtection` blocks deletion until someone turns the protection off. Next, allow your own IP address and your application servers' network to connect. To make an entry temporary, add `--deleteAfter` with an ISO 8601 timestamp in UTC: ```bash atlas accessLists create --currentIp --comment "dev laptop" atlas accessLists create 203.0.113.0/24 --type cidrBlock --comment "app servers" ``` Create a database user for the application that can only read and write the `appdb` database, and only on `prod-cluster`. Without `--scope`, the user would get this access on every cluster in the project. When you leave out `--password`, the CLI prompts for it, which keeps the password out of your shell history: ```bash atlas dbusers create --username appUser --role readWrite@appdb --scope prod-cluster ``` Finally, print the cluster's SRV connection string, which starts with `mongodb+srv://`. If you connect through network peering or private endpoints, add `--type private` or `--type privateEndpoint`: ```bash atlas clusters connectionStrings describe prod-cluster ``` ## Connecting to the cluster To open a shell, pass the connection string and user name to `mongosh`, which then prompts for the password: ```bash mongosh "mongodb+srv:///" --username appUser ``` Replace `` with the host from the connection string. An SRV connection string doesn't list individual servers: the client looks up the replica set members in DNS, so Atlas can replace nodes without you changing your configuration. If your network's DNS can't resolve these SRV records, the Atlas UI can also show a standard `mongodb://` connection string that lists every host. Applications use the same host in a connection string that includes the credentials: ```text mongodb+srv://appUser:@/?retryWrites=true&w=majority ``` Load this string from an environment variable or a secret manager rather than committing it to source control, and percent-encode characters such as `@`, `:` or `/` in the password. [Introduction to MongoDB connection URIs](https://www.prisma.io/dataguide/mongodb/connection-uris) explains each part of the string. ## Developing against a local Atlas deployment For tests and offline work, the Atlas CLI can run a [local Atlas deployment](https://www.mongodb.com/docs/atlas/cli/current/atlas-cli-deploy-local/): a single-node replica set in a container on your machine that also supports MongoDB Search and Vector Search. It needs Docker (Docker Desktop 4.31 or later on macOS and Windows, Docker Engine 27.0 or later on Linux) or, on Red Hat Enterprise Linux, Podman 5.0 or later. ```bash atlas local setup dev-local --mdbVersion 8.0 atlas local connect dev-local --connectWith mongosh ``` The deployment listens only on `127.0.0.1` unless you pass `--bindIpAll`, and `--port` picks a port other than the default 27017. `atlas local stop dev-local` pauses it, and `atlas local delete dev-local` removes it along with its data. These `atlas local` commands replace the `atlas deployments` commands, which have been deprecated since Atlas CLI 1.52.0. ## Pausing and deleting clusters Atlas bills paid clusters by the hour, so clean up what you don't need: - **Free clusters** can't be paused by hand. Atlas pauses them after 30 days without connections and emails you a week before. You can resume a paused Free cluster unless it runs a version too old for Atlas to restore, so export the data if you won't use it for a while. - **Flex clusters** can't be paused, and Atlas doesn't pause them when they're idle. Delete them when you're done. - **Dedicated clusters** can be paused for up to 30 days, after which Atlas resumes them. While paused, you pay only for storage and can't read or write data. Backups stop, but existing snapshots are kept until they expire. ```bash atlas clusters pause prod-cluster atlas clusters start prod-cluster ``` To delete a cluster, first turn off termination protection if it's enabled. The command asks for confirmation unless you add `--force`, and it can't be undone. It also deletes the cluster's backup snapshots; to keep them, terminate the cluster in the Atlas UI and choose to keep existing snapshots: ```bash atlas clusters delete dev-cluster ``` Access list entries and database users belong to the project, not the cluster, so remove the ones you no longer need with `atlas accessLists delete` and `atlas dbusers delete`. ## Conclusion Provisioning an Atlas cluster comes down to a handful of decisions: a tier that fits the workload (Free to learn, Flex for small projects, `M30` and up for production), a region next to your application, a MongoDB version you can plan upgrades around, and access that is as narrow as possible, with specific IP addresses or private endpoints and one least-privileged database user per application. Making these decisions with the Atlas CLI leaves you with commands you can review, repeat and keep next to your code. ## FAQ **How do I connect BI tools such as Tableau to Atlas?** Use the [MongoDB SQL Interface](https://www.mongodb.com/docs/sql-interface/). The older BI Connector for Atlas is no longer supported after September 2026, and MongoDB recommends the SQL Interface for new projects. **How do I monitor an Atlas cluster?** Atlas collects [metrics](https://www.mongodb.com/docs/atlas/monitor-cluster-metrics/) for every cluster and can alert you on them. Free and Flex clusters show only connections, logical size, network and operation counters. Dedicated clusters add the full set of metrics, the Real-Time Performance Panel and the Performance Advisor, which suggests indexes for slow queries.