MongoDB Atlas: how do I set up org/projects, IP access or private endpoints, and production users/roles for a new production cluster?

Launching a production workload on MongoDB Atlas is more than just spinning up a cluster. To run safely at scale, you need a clear organization and project structure, locked-down network access (IP allowlisting or private endpoints), and least-privilege database users and roles. This guide walks through a pragmatic, production-ready setup you can adapt to your environment.

1. Plan your Atlas organization and project structure

Your Atlas organization is the top‑level container, and projects group related clusters, users, and network settings. A clean structure is the foundation for secure, maintainable production environments.

1.1 When to create multiple organizations vs projects

Use one Atlas organization when:

Your company is a single legal entity
Billing is managed centrally
You want shared org-level SSO and security policies

Consider multiple organizations when:

You manage completely separate business units or legal entities
You require hard isolation of billing and access policies
Different customers or teams must never see each other in the Atlas UI

Within an organization, use projects to isolate environments and applications:

Common patterns:

Per-environment projects
- mycompany-prod
- mycompany-staging
- mycompany-dev
Per-application projects within each environment
- payments-prod, analytics-prod, etc.

For most teams, a good starting point is:

org: mycompany
- project: mycompany-prod
- project: mycompany-staging
- project: mycompany-dev

This gives clear isolation while keeping administration manageable.

1.2 Use project-level access control

Each Atlas project has its own:

Clusters
Database users
Network access (IP access lists, private endpoints)
Project-level roles for Atlas users

Best practices:

Grant Atlas users project access only to the environments they need (e.g., developers get *-dev, SREs get prod + staging).
Use roles like Project ReadOnly or Project Data Access for non-admin users.
Keep production access minimal, audited, and tied to identity provider groups (SSO) where possible.

2. Create a new production project and cluster

2.1 Create the project

In the Atlas UI:

Sign in to Atlas.
From the Organizations menu, choose your organization.
From the Projects menu, select New Project (or similar action).
Name it something clear like myapp-prod.
Add only the users or IDP groups that should have production admin or read access.

You can also use the Atlas CLI:

brew install mongodb-atlas-cli
atlas setup
atlas projects create myapp-prod

2.2 Create the production cluster

Inside your new myapp-prod project:

Click Build a Database.
Choose a Dedicated cluster tier (e.g., M10+ for production).
Select the primary Cloud provider and region closest to your app.
Configure:
- Redundancy (multi-region/replica set)
- Backup (enable Cloud Backup / continuous backups)
- Encryption (at-rest is on by default; configure customer key management if required)
- Cluster name with a clear pattern, e.g., myapp-prod-cluster1.

You can also configure clusters via:

Atlas CLI
Atlas Administration API
Terraform / AWS CloudFormation
Kubernetes Operator

This “infrastructure-as-code” (IaC) approach is recommended for repeatable, auditable production setups.

3. Configure IP access lists or private endpoints

MongoDB Atlas lets you control which sources can connect to your cluster via:

IP access lists (public access from specific IPs/CIDRs)
Private endpoints (private connectivity over your cloud provider network)

Use IP access lists for simpler setups or non-critical workloads, and private endpoints for production systems needing stronger network isolation.

3.1 IP access lists for production

In the Atlas UI:

Select your production project.
In the sidebar, click Database & Network Access under the Security heading.
Go to the Network Access or IP Access List tab (name may vary).
Add entries for:
- Application servers’ outbound IPs or CIDRs
- Bastion hosts / jump boxes you use for maintenance
- Monitoring or ETL tools that need direct DB access

Guidelines:

Avoid 0.0.0.0/0 for production. This exposes the cluster to the internet.
Use static IPs or NAT gateways so outbound connections originate from known addresses.
Document each entry with a clear comment (e.g., prod-app-ecs-cluster, prod-bastion).
Review IP access lists regularly and remove unused entries.

3.2 Private endpoints for secure, internal-only access

For production workloads in AWS, Azure, or GCP, private endpoints are strongly recommended.

High-level steps:

In Atlas, open Network Access.
Choose Private Endpoint (for your cloud provider).
Create a private endpoint service in Atlas providing service details or IDs.
In your cloud provider:
- Create a VPC/VNet endpoint targeting the Atlas service.
- Attach it to the appropriate VPC/VNet and subnets.
- Configure security groups / network security groups to allow traffic from your app subnets.
Back in Atlas, approve and finalize the private endpoint.

Once configured:

Your applications connect to the same Atlas connection string, but network traffic flows privately.
You can still keep IP access lists very restrictive or limited to provider IP ranges used for private connectivity.

4. Set up production database users and roles

Atlas enforces that you manage database users via:

Atlas UI
Atlas CLI
Atlas Administration API
IaC integrations (Terraform, etc.)

If you try to create or modify DB users directly from the shell on an Atlas cluster, Atlas will roll back those changes.

Atlas also limits you to a maximum of 100 database users per project, which is usually sufficient when you use shared app users or IAM-based auth.

4.1 Understand Atlas database authentication options

For Atlas deployments, you can configure DB users to authenticate via:

Username + password
X.509 certificates
AWS IAM (IAM roles/users mapped to DB users)

Pick based on your environment:

Password auth
- Simple to start with
- Make sure you use a secrets manager (e.g., AWS Secrets Manager, Vault)
X.509
- Strong mutual TLS with certificates
AWS IAM
- Lets AWS roles authenticate without embedding passwords
- Works well for EC2, ECS, Lambda running in AWS

4.2 Create production database users in the Atlas UI

To create and view users:

Select your production project.
In the sidebar, click Database & Network Access under Security.
Go to the Database Users tab.
Click Add New Database User.

You’ll define:

Authentication method:
- Username/password
- X.509
- AWS IAM
Roles and privileges:
- Atlas provides built-in roles and some specific privileges that cover a subset of MongoDB commands.

Atlas built-in roles are designed to be safely usable in a managed environment. For M10+ clusters, some MongoDB commands are unsupported; refer to Atlas docs on “Unsupported Commands in M10+ Clusters” when in doubt.

Example: Create an application user

For a typical app:

Create a user like myapp-prod-app.
Choose Password (or IAM if you’re on AWS).
Grant roles scoped to the relevant database(s), for example:
- readWrite on myapp_prod
- Optionally read on admin if needed for certain frameworks/tools
Avoid broad roles like dbOwner or readWriteAnyDatabase in production unless absolutely required.

Store the password or IAM mapping in your secret management system and inject it into your app’s environment.

Example: Create an operational/admin user

For an SRE or DBA:

Create myapp-prod-dba (or use IAM + personal accounts).
Use more powerful roles if necessary (e.g., dbAdmin or appropriate admin roles).
Consider creating separate users for ad-hoc admin tasks rather than reusing app credentials.

4.3 Use Atlas CLI or IaC to manage users

To keep production environments auditable and repeatable, manage DB users via code.

Example with Atlas CLI:

# Create an application user with readWrite on a specific DB
atlas dbusers create \
  --username myapp-prod-app \
  --password 'REDACTED' \
  --role readWrite@myapp_prod \
  --projectId <PROJECT_ID>

With Terraform or other IaC:

Define DB users and roles as resources.
Apply changes through CI/CD with approvals.
Gain version history and compliance-friendly change tracking.

Remember: modifying users directly on the cluster shell is not supported in Atlas and will be reverted.

5. Design a production-ready role and user model

To avoid privilege sprawl, design a simple but robust pattern.

5.1 Separate users by function

Consider defining:

Application service users
- One user per major application or microservice
- Minimal roles for required collections/DBs only
Read-only analytics/reporting users
- read on selected databases
- Use for BI tools, dashboards, auditors
Operational / SRE / DBA users
- More privileged but still constrained to what’s necessary
- Avoid using these for application connections

5.2 Enforce least privilege

For each user:

Determine all operations the application or person must perform (read, write, index, admin, etc.).
Map those operations to Atlas built-in roles and, where supported, specific privileges.
Start with minimal permissions in non-prod, verify everything works, then mirror them in production.

If Atlas roles do not support a command you expect, check:

If that command is unsupported on M10+ clusters.
Whether there’s a safer alternative or new Atlas role/privilege.

6. Operational best practices for a new production cluster

Once org/projects, networking, and users are set, finalize the production setup with these practices.

6.1 Enforce separation between environments

Use separate projects for prod, staging, and dev.
Do not reuse production DB users in non-production environments.
Never allow test or dev apps to connect to the prod cluster.

6.2 Monitor and audit access

Enable and integrate Atlas monitoring and alerts with your observability stack.
Review IP access lists and private endpoints periodically.
Regularly audit:
- Atlas project members and their roles.
- Database users and privileges.
- Connection patterns (e.g., unexpected sources or spikes).

6.3 Automate as much as possible

Use the Atlas CLI, Administration API, Terraform, or Kubernetes Operator to:
- Create projects and clusters
- Configure network access
- Manage database users
Treat your Atlas configuration like code—reviewed, tested in lower environments, then promoted to prod.

7. Step-by-step summary

For a new production cluster, a concise checklist:

Organization & projects
- Create or choose your Atlas organization.
- Create a *-prod project and give it limited, appropriate access.
Cluster
- Build a dedicated cluster (M10+) in the right region.
- Configure replica sets, backups, and encryption as required.
Network
- Choose IP access lists or private endpoints.
- Restrict access to app servers, bastions, and required tools only.
Database users & roles
- Create app, reporting, and admin users via Atlas UI/CLI/API.
- Use password, X.509, or AWS IAM auth as appropriate.
- Assign Atlas built-in roles with least privilege.
Governance & operations
- Monitor, audit, and periodically review access.
- Manage everything via automation and IaC where possible.

With this structure—clear org/projects, secure network access, and carefully scoped users and roles—you’ll have a robust foundation for running MongoDB Atlas in production.