MongoDB Atlas

To back up a MongoDB Atlas database, Backup connects to your cluster like any other MongoDB: over the public internet, with TLS, using a standard SRV connection string and a database user. Atlas is managed, so two things need your attention before it works: Atlas blocks all inbound traffic until you allow Backup's egress IP, and you'll want a read-only user scoped for mongodump.

Which connection string

Use the standard SRV connection string — the one Atlas shows under Drivers (formerly "Connect your application"). It looks like:

mongodb+srv://<username>:<password>@<cluster>.<hash>.mongodb.net/?retryWrites=true&w=majority

The mongodb+srv:// scheme uses a DNS SRV record to discover your cluster's replica-set nodes, so you don't list individual hosts. Atlas appends ?retryWrites=true&w=majority by default; those are safe to leave in. Backup accepts this URI as-is. The SRV scheme also implies tls=true, so the connection is encrypted without any extra flag. Atlas requires TLS on every cluster; it is always on. The SRV record resolves to your cluster's nodes, which are reachable over public IPv4.

Find the connection string

1. In the Atlas UI, go to Database and click Connect on your cluster.
2. Choose Drivers (under "Connect to your application").
3. Leave the driver dropdown on the default. Atlas shows the mongodb+srv:// connection string.
4. Copy it. Atlas shows <password> as a placeholder — replace it with the database user's password (URL-encode any reserved characters, for example @ becomes %40).

Paste the URI into Backup's credentials step.

Network access

This is the step that trips people up. Atlas's IP Access List denies all inbound connections by default; nothing connects until the source IP is on the list. You must add Backup's egress IP 18.196.207.101:

1. In the Atlas UI, go to Network Access → IP Access List.
2. Click Add IP Address.
3. In Access List Entry, enter 18.196.207.101/32 (the /32 scopes it to that single address).
4. Add a comment like Norcube Backup egress, then click Confirm.

Wait for the entry to go Active before testing. Don't use 0.0.0.0/0; you only need Backup's one static IP. See network access.

Database user

mongodump needs a database user with read access. In Atlas, go to Database Access → Add New Database User:

• Authentication Method: Password (Atlas uses SCRAM under the hood).
• Set a username and password. These are the credentials that go in the connection string.
• Database User Privileges: grant a read-only built-in role. Read and write to any database → Only read any database (readAnyDatabase on admin) covers a full-cluster dump. To scope it tighter, use Specific Privileges and grant read on just the database you back up.

Read access is all mongodump needs. Don't grant write or admin roles.

Restore tests

Every backup can be restore-tested: Backup replays the archive into a throwaway MongoDB engine and confirms your data comes back. For MongoDB the result is a straight pass/fail — your collections and documents either restore or they don't.

mongodump against Atlas produces a normal dump. --oplog (point-in-time consistency) requires privileges Atlas doesn't grant a standard user, so Backup takes a regular dump, which is exactly what restore-tests. The provider-managed-extension caveat that applies to Postgres platforms like Supabase doesn't apply to MongoDB; there's nothing platform-specific to skip.

From there, it's the standard flow

Backup runs mongodump on your schedule and writes the encrypted archive to storage you control. You can download any backup and restore it with standard MongoDB tools, independent of Norcube. When you're ready, follow connect a database to wire it up.