Source-IP access and TLS

Restrict source IPs

The database owner can configure allowed_cidrs with IPv4/IPv6 addresses or CIDR ranges. Bare addresses normalize to /32 or /128; networks are normalized and duplicates removed. An empty list means unrestricted source IPs, not “deny all.”

Use the application’s outbound public address, which can differ from its internal container or server address. Include every intended runtime and migration runner; account for changing egress addresses before deployment.

A valid example body for a documentation-only address is:

{"allowed_cidrs":["203.0.113.10/32"]}

Replace this address with your real egress address. Check allowlist_enforced after saving. MongoDB reports native enforcement; PostgreSQL/Redis enforcement depends on the deployed service. A saved list with allowlist_enforced: false is not an active security boundary. Contact support if enforced network restrictions are required and the flag is false.

Confirm transport security

Use TLS settings appropriate to the returned engine connection configuration and verify the server certificate and hostname. Do not solve a certificate error by disabling verification. Obtain the correct CA configuration or hostname from support if necessary.

Do not infer TLS enforcement from a dashboard lock icon, HTTPS on the management API, or a connection string example. Those say nothing about the separate native database connection. Resolve a non-TLS or permissive advertised configuration before sending sensitive production data.

After changing network policy, test a new connection from the application runtime and an intentionally disallowed address. Keep a recovery route through the dashboard so a mistaken allowlist change can be corrected.