Skip to main content

Configure Public Endpoint

A cluster is reachable only from inside its VPC until you enable Public Endpoint, which gives it a second connection string that works from the internet. Two controls then decide who can use it: the Security Group on the cluster's network, and the IP Allowlist on this tab.

warning

A public endpoint is reachable from anywhere on the internet, not only while you are using it. Enabling one also restarts the service, so plan it outside peak hours and make sure your application reconnects on its own.

Prerequisites​

  • A cluster in Running status. See Create your first database.
  • The public IPv4 address of each client that needs access. The field takes single addresses, not CIDR ranges.
  • A window in which a restart is acceptable, because enabling interrupts existing connections.
  • A Security Group that permits the MongoDB port from each of those addresses. See Connect to database with Floating IP.

How access is controlled​

Two layers sit in front of the public endpoint, and they do different jobs:

  • Security Group — the network rule on the cluster. A client cannot reach the public endpoint at all unless the Security Group permits its address on the MongoDB port.
  • IP Allowlist — the list on this tab. It narrows what the Security Group has already let through.
danger

If the Security Group allows every address, the IP Allowlist stops restricting anything and the database is open to the internet. Point the Security Group at exactly the addresses you put on the allowlist, and change both together.

Enable the public endpoint​

Open the cluster and select the Public Endpoint tab. It is available on all three architectures. Before activation the tab holds only a status and an Enable button.

Public Endpoint tab before activation, showing Inactive status

  1. Click Enable.

  2. Read both notices. The endpoint becomes reachable from the internet, and the operation restarts the service, so connections drop while it runs.

  3. Enter the first access rule. An IPv4 address is required; Description is optional but worth filling in, because it is the only clue to why a rule exists when someone reviews the list months later.

    Enable Public Endpoint dialog with its two notices and the first access rule

  4. Click Add access rule to declare further addresses in the same step, then click Enable.

The status moves to Processing with a progress bar, and the cluster itself shows Updating while the restart runs. Allow a few minutes. When it finishes the status reads Active, and the tab shows the public connection string alongside the allowlist that guards it.

Public Endpoint tab after activation, with the connection string and two allowlist entries

You cannot enable the endpoint without at least one rule — the Enable button stays disabled until the address field holds a valid IPv4 address.

Connect over the public endpoint​

  1. Copy the Public connection string from the tab.
  2. Read the username and password from the cluster's Overview tab. See View database cluster information.
  3. Connect with mongosh, Compass, or a driver, putting the public string where you would otherwise use the private one.
mongosh "mongodb://<USERNAME>:<PASSWORD>@<HOST>:27017/admin?replicaSet=<CLUSTER_ID>"

The string already carries the hosts, the port, and the database name, so credentials are the only thing you add. What it lists depends on how the cluster is built:

ArchitectureThe public string lists
StandaloneThe single node, still carrying the replicaSet parameter
ReplicaSetEvery data-bearing node, with the replicaSet parameter
Sharded ClusterThe mongos routers only, with no replicaSet parameter
tip

A connection that hangs and times out, rather than failing on credentials, is a network block rather than an authentication problem. Check the Security Group first, then the client's current public IPv4 against the allowlist — an office or home address can change without notice.

Add an access rule​

  1. Click Add access rule above the allowlist table.
  2. Fill in the IPv4 address, and a Description if it helps.
  3. Use Add access rule inside the dialog to declare several addresses at once, then click Add.

The field takes a single IPv4 address. A CIDR range is rejected with IPv4 address fails to match the pattern.

Overlapping entries are caught as you type, before you can submit:

Add Access Rule dialog rejecting an address that already exists

Adding a rule is not instant. The operation runs in the background and the new row appears in the allowlist once it completes, which takes a few minutes. Track it under Action logs at the bottom of the tab.

Delete an access rule​

  1. Click Delete rule above the allowlist table.
  2. Tick the rules to remove. The dialog warns that clients depending on them lose access.
  3. Click Delete.

An enabled endpoint must keep at least one rule, and the console enforces that in two places. With a single rule left, the Delete rule button itself is disabled. With several, the dialog opens but its Delete button stays disabled while every rule is selected — clear one tick and it comes back.

Removing the last address would leave the endpoint published but unreachable, which is why the rule exists. To close off access entirely, disable the endpoint instead.

Disable the public endpoint​

  1. Click Disable at the top right of the tab.

  2. Type disable into the confirmation field.

    Disable Public Endpoint dialog asking you to type disable to confirm

  3. Click Disable.

Clients on the public endpoint lose connectivity immediately. Connections over the private VPC endpoint are unaffected, so applications inside the VPC keep working. The status returns to Inactive, the public connection string disappears, and the allowlist goes with it, so re-enabling later means declaring the addresses again.

Keep the exposure small​

The IP Allowlist does not authenticate anyone, and it cannot take back what the Security Group has already opened. Treat the Security Group as the real perimeter, and keep the database credentials as strong as you would for any internet-facing service.

  • Keep the Security Group and the IP Allowlist on the same set of addresses. An address dropped from one list and left in the other is the gap that gets found.
  • Give every rule a Description naming the client it belongs to. A list of bare addresses tells a reviewer nothing.
  • Delete a rule as soon as the client behind it no longer needs access. A stale entry is a door nobody is watching.
  • Disable the endpoint once the work that needed it is finished, rather than leaving it active between tasks.
  • Keep production traffic on the private VPC endpoint. The public endpoint suits external integrations, temporary administrative access, and development or testing.

Next steps​