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 new production cluster in MongoDB Atlas isn’t just about spinning up compute and storage; you also need a solid foundation for organizations and projects, secure network access via IP allow lists or private endpoints, and the right production-ready users and roles. This guide walks through a practical, production-focused setup that aligns with MongoDB Atlas best practices and uses terminology and workflows you’ll see in the Atlas UI, CLI, and automation tools.

---

1. Plan your Atlas organization and projects for production

Before you create any clusters, design how you’ll structure your Atlas organization and projects. This affects access control, billing separation, and how cleanly you can manage environments (dev, staging, prod).

1.1. Organization vs project: how to think about each

• Organization

  • Top-level container
  • Typically maps to a company, business unit, or security boundary
  • Central place for:
    • Organization-level access and SSO
    • Global API keys
    • Central billing

• Project

  • Logical grouping of clusters, database users, and network settings
  • Good fits:
    • One project per environment (e.g., my-app-prod, my-app-staging)
    • One project per product or microservice when isolation is important
  • Each project has:
    • Its own database users (up to 100 per project)
    • Its own IP access list / private endpoint configuration
    • Its own team memberships and roles

Production tip: Use a dedicated project for production. Avoid mixing dev/staging and prod clusters in the same project so you can isolate access, auditing, and network controls.

1.2. Recommended structure for a new production application

A common, scalable pattern:

• One Atlas organization per company
• For each major application:
  • my-app-prod project
  • my-app-staging project
  • my-app-dev project (optional or shared)

Within my-app-prod:

• Only production clusters
• Production-only database users
• Restricted network access (private endpoints and/or narrow IP allow list)
• Limited, role-based access for admins and operators

This structure keeps your production blast radius small and simplifies compliance and audits.

---

2. Create or select your Atlas organization and project

You can set up Atlas using the UI, Atlas CLI, or IaC (Terraform, CloudFormation, Kubernetes Operator). For production, using automation is strongly recommended, but the core concepts are the same.

2.1. Using the Atlas UI

1. Sign in to Atlas.
2. In the navigation bar, use the Organizations menu to:
   • Select an existing organization, or
   • Create a new one if this is a new company-level setup.
3. From the Projects menu:
   • Click New Project.
   • Name it something like my-app-prod.
   • Associate it with your preferred Atlas organization.
4. Add team members to the project with least-privilege roles (e.g., Project Data Access Admin, Project Owner, etc., depending on responsibilities).

2.2. Using the Atlas CLI (high-level)

Install and set up the CLI:

brew install mongodb-atlas-cli
atlas setup

Then, you can script resource creation (projects, clusters, users, etc.) for reproducible production setups. For an enterprise-grade workflow, pair the CLI with CI/CD pipelines or use Terraform / CloudFormation modules.

---

3. Choose and configure network access: IP access list vs private endpoints

For a production MongoDB Atlas cluster, you must decide how clients will reach the database. The two main options are:

• IP access list (public endpoints)
• Private endpoints (VPC/VNet-integrated, private connectivity)

You can use them together, but many production environments move toward private endpoints only for stronger network isolation.

3.1. Using IP access lists for production

IP access lists restrict who can reach your Atlas cluster over public internet endpoints.

Typical use cases:

• Early-stage production where private endpoints aren’t yet set up
• Admin tools and scripts run from known corporate IP ranges
• Hybrid access while migrating to private endpoints

Best practices:

• Add only the specific IP addresses or narrow CIDR ranges that need access:
  • App server IPs / NAT gateways
  • Bastion hosts / jump boxes
  • Corporate VPN egress IPs for admins
• Avoid 0.0.0.0/0 in production (open to the world).
• Regularly rotate and review IP entries.

Where to configure in Atlas UI:

1. Choose your organization and then your production project.
2. In the sidebar, click Database & Network Access under the Security heading.
3. Go to the Network Access or equivalent tab (naming may vary slightly).
4. Add entries for:
   • Single IPs (e.g., 203.0.113.10)
   • CIDR ranges (e.g., 203.0.113.0/24)

3.2. Using private endpoints for production

Private endpoints connect your Atlas clusters directly to your cloud provider’s private network (VPC or VNet), ensuring traffic doesn’t traverse the public internet.

Benefits:

• Increased security and compliance
• Simpler firewall policy (treat Atlas like any other internal service)
• Better alignment with zero-trust networking and enterprise standards

High-level steps (conceptual):

1. Enable private endpoints in Atlas for your project and cluster’s region.
2. Create a private endpoint in your AWS VPC, Azure VNet, or GCP equivalent.
3. Approve and link the cloud-side endpoint in the Atlas UI.
4. Update your application configuration to:
   • Use the private endpoint-specific connection string
   • Ensure security groups / network rules allow outbound traffic to Atlas via the endpoint

Production guidance:

• For new production applications, plan on private endpoints as your primary connectivity.
• Optionally keep a restricted IP allow list for:
  • Emergency fallback
  • Temporary access for migrations or external tooling

---

4. Create production-ready database users and roles

Database users in Atlas are separate from Atlas console users. They are the credentials your applications and tools use to connect to the databases.

Key facts from Atlas:

• You can create a maximum of 100 database users per Atlas project.
• You must manage database users via:
  • Atlas UI
  • Atlas CLI
  • Atlas Administration API
  • Supported integrations (Terraform, Kubernetes Operator, CloudFormation)
• If you create or modify users directly on the cluster, Atlas rolls back any user modifications.

4.1. Accessing the Database & Network Access page

To manage production database users:

1. In Atlas, select your organization.
2. Select your production project from the Projects menu.
3. In the sidebar, click Database & Network Access under the Security heading.
4. Select the Database Users tab.

This is your central place to define how applications and DBAs authenticate to the database.

4.2. Choose the right authentication method

Atlas supports several authentication mechanisms for database users:

• Password

  • Simplest and most common for application users.
  • Use strong, randomly generated passwords.
  • Store securely in a secret manager (AWS Secrets Manager, HashiCorp Vault, etc.).

• X.509 Certificates

  • PKI-based; ideal for environments that already issue and rotate certificates.
  • Strong option for server-to-server auth in highly regulated environments.

• AWS IAM

  • Integration with AWS IAM roles for authentication.
  • Reduces the need to distribute long-lived database passwords.
  • Aligns well with cloud-native, identity-based access strategies.

Production recommendation: For new applications, use passwords or AWS IAM depending on your cloud stack and security requirements; consider X.509 for specialized PKI-heavy environments.

4.3. Designing production user roles and privileges

Atlas provides built-in roles and specific privileges that cover a subset of MongoDB commands suitable for production. While these don’t expose every low-level operation, they are sufficient for most application and administrative workflows.

Key principles:

• Least privilege: Application users should have only the access they need.
• Separate roles for:
  • Application runtime (app-prod)
  • Maintenance/ops (maintenance-user)
  • Analytics / BI (reporting-user)
• Avoid using broad admin roles (like atlasAdmin or fully privileged roles) for application connections.

Common patterns:

1. Application user (per app, per environment)

   • Role: read/write on the specific application database
   • Example: readWrite on my_app_db

2. Read-only reporting user

   • Role: read on selected databases
   • Used by BI tools or analysts

3. Maintenance/operations user

   • Role: combination of roles that allow index management and schema migrations
   • Not used by the application itself; only by operational tools or DBAs

Remember: Because Atlas roles support a specific subset of commands, if you need advanced or unusual privileges, consult Atlas documentation on built-in roles and unsupported commands in M10+ clusters before designing your access pattern.

4.4. Creating database users in the Atlas UI

From the Database Users tab:

1. Click Add New Database User.
2. Choose authentication type:
   • Password
   • X.509
   • AWS IAM (if configured)
3. Assign roles:
   • Use built-in roles (read, readWrite, etc.) scoped to specific databases.
   • Avoid giving cluster-wide privileges unless strictly required.
4. Optionally, restrict the user to a specific cluster in the project.
5. Save and securely distribute the credentials or IAM settings to the application.

---

5. Automate production setup with CLI or IaC

For consistency, compliance, and easier scaling, automate your production setup using:

• MongoDB Atlas CLI
• HashiCorp Terraform provider for Atlas
• AWS CloudFormation resources
• Atlas Kubernetes Operator

Automation benefits:

• Version-controlled definitions for:
  • Organizations, projects, and teams
  • Clusters and backing storage
  • Network access (IP allow lists, private endpoints)
  • Database users and roles
• Easier replication across environments (dev → staging → prod)
• Reduced risk of manual misconfiguration

A typical IaC workflow:

1. Define a production project and cluster configuration in Terraform or CloudFormation.
2. Add resources for:
   • IP access entries or private endpoints
   • Database users with appropriate roles
3. Apply the configuration through CI/CD whenever you need to spin up or update a production environment.

---

6. Putting it all together: baseline production checklist

For a new production MongoDB Atlas cluster, verify the following:

Organization / project

• You have a dedicated organization (or a clear org-level structure).
• my-app-prod is an isolated project containing only production resources.
• Project members have minimal Atlas roles required for their job.

Network access

• IP access list:
  • Only specific IPs / CIDRs required for production access are allowed.
  • No 0.0.0.0/0 in production.
• Private endpoints:
  • Configured and approved in the target cloud VPC/VNet.
  • Applications are using the private connection strings.
  • Security groups / firewalls allow outbound traffic to Atlas via the endpoint.

Database users / roles

• Database users created via Atlas UI, CLI, API, or IaC (not directly on the cluster).
• Application users:
  • Separate per app and per environment (no shared prod credentials).
  • Scoped roles (e.g., readWrite on the app database only).
• Maintenance and reporting users:
  • Have appropriate but limited privileges.
  • Are not used by application runtime.
• You are within the 100 database users per project limit.

Automation

• Atlas CLI and/or Terraform / CloudFormation are in place for repeatable setup.
• Configuration is stored in source control and deployed through CI/CD.

By deliberately structuring your Atlas organization and projects, locking down IP access or using private endpoints, and defining clear, least-privilege production users and roles, you create a strong security and operational baseline for your new MongoDB Atlas production cluster that’s easier to scale, audit, and automate.