Why use an Agent for Atlas access?
A home server or self-hosted application may receive a different public IPv4 after a network change. An Atlas IP Access List entry for the previous address no longer permits connections from the new address. Edgekeeper uses the Agent at that server location to drive a targeted access-list update.
This manages network access only. Database users, passwords and application connection strings remain separate. MongoDB Atlas is an independent plan permission from DNS automation.
Connect a project and choose a baseline
- Install the Docker Agent on the server or network that needs database access.
- Open MongoDB Atlas in your workspace and add an integration with the project and API credentials.
- Assign the correct online Agent.
- Set the baseline IPv4 to the exact old address you intend Edgekeeper to replace, including an existing manually added address if appropriate.
- Test the connection, synchronize, and inspect Activity for the outcome.
A baseline authorizes replacement of that specific address. Do not use a shared access entry as the baseline if other servers still depend on it. Unrelated manually created entries are not a general cleanup target.
The safe rotation sequence
- The Agent reports its current public IPv4.
- Edgekeeper adds the new exact /32 access-list entry.
- It waits for Atlas to report the entry ACTIVE.
- It removes the eligible old baseline or managed entry and advances the tracked baseline.
If the new entry is not active, the old entry must not be removed yet. Check Activity rather than assuming a submitted request is already complete. Rotation can still take time; this is not a guarantee of uninterrupted database connections.
Verification and deployment boundaries
Agent IP changes trigger synchronization. Periodic verification can be set to 15, 30 or 60 minutes; the recommended default is 30 minutes. Scheduling uses staggering and API backoff, so a configured interval is not an exact execution deadline.
Atlas Administration API access restrictions are separate from the database IP Access List. If API source-IP restrictions apply, authorize the Edgekeeper service’s outbound address for the API.
Avoid a circular dependency: if Edgekeeper stores its own database in an Atlas cluster whose only permitted source IP it must update, a service IP change can prevent Edgekeeper from reaching the database needed to perform that update. Provide stable permitted egress, a separate network path, or an independent recovery mechanism.