MongoDB Ops Manager and Cloud Manager
Parent: MongoDB Expert Knowledge · Published reference · snapshot 2026-09-08 · skill mongodb-operations-expert/references/mongodb-ops-manager.md
Also known as: MongoDB Ops Manager
↓ Facts as markdownall context files
Ops Manager is MongoDB's self-hosted management platform for on-premises MongoDB deployments. Cloud Manager is the hosted SaaS equivalent (no infrastructure to manage). Both provide:
These notes link each claim to its source. Some citations identify archived research reports that are no longer hosted on this site. A published reference means the content is available; it does not certify independent review or accuracy.Read the editorial policy and follow the sources before relying on a claim.
Overview
- Ops Manager is MongoDB's self-hosted management platform for on-premises MongoDB deployments. Cloud Manager is the hosted SaaS equivalent (no infrastructure to manage). Both provide: [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-ops-manager/#overview]
- Automation: Declarative goal-state management of MongoDB clusters (topology, version, config) [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-ops-manager/#overview]
- Monitoring: Real-time metrics, alerts, and dashboards [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-ops-manager/#overview]
- Backup: Continuous oplog-based backup with PITR [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-ops-manager/#overview]
App Database Sizing
- The App DB stores Ops Manager's own state. Sizing: [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-ops-manager/#app-database-sizing]
- Small (< 50 MongoDB processes): 3-node RS, M10 equivalent (8 GB RAM) [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-ops-manager/#app-database-sizing]
- Medium (50-500 processes): 3-node RS, M30 equivalent (32 GB RAM) [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-ops-manager/#app-database-sizing]
- Large (500+ processes): 5-node RS or sharded cluster [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-ops-manager/#app-database-sizing]
- App DB HA: Always use 3-node replica set. Single-node App DB = single point of failure for Ops Manager. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-ops-manager/#app-database-sizing]
MongoDB Agent
- A single binary that handles automation, monitoring, and backup for all MongoDB processes on the host. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-ops-manager/#mongodb-agent]
Automation (Declarative Goal State)
- Ops Manager maintains the desired topology in the automation config JSON. The Agent continuously reconciles actual state to match the goal state. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-ops-manager/#automation-declarative-goal-state]
- Example: Add a replica set via API [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-ops-manager/#automation-declarative-goal-state]
Backup Daemon
- Backup Daemon runs on a dedicated host. It: [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-ops-manager/#backup-daemon]
- Reads from oplog of source MongoDB (via agent) [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-ops-manager/#backup-daemon]
- Writes snapshots to configured store [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-ops-manager/#backup-daemon]
- Maintains PITR window by tailing the oplog [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-ops-manager/#backup-daemon]
- Place the Backup Daemon close to the data (low latency to both source MongoDB and snapshot store). [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-ops-manager/#backup-daemon]
Immutable S3 Snapshots (Object Lock)
- Enable S3 Object Lock on the S3 bucket to prevent snapshot deletion: [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-ops-manager/#immutable-s3-snapshots-object-lock]
Air-Gap Deployments (Local Mode)
- In air-gapped environments, Ops Manager must serve MongoDB binaries from a local mirror: [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-ops-manager/#air-gap-deployments-local-mode]
- Download MongoDB Community/Enterprise binaries and place in the local versions directory for Agent to use. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-ops-manager/#air-gap-deployments-local-mode]
Kubernetes Operator Integration
- Ops Manager provides a Kubernetes Operator (MongoDB Kubernetes Community Operator) for managing MongoDB deployments inside Kubernetes: [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-ops-manager/#kubernetes-operator-integration]
Live Migration to Atlas
- Ops Manager supports initiating a Live Migration to Atlas: [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-ops-manager/#live-migration-to-atlas]
- Link Ops Manager to Atlas: Atlas UI → Live Migrate → Link to Ops Manager [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-ops-manager/#live-migration-to-atlas]
- Select source cluster: Choose the Ops Manager project and cluster [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-ops-manager/#live-migration-to-atlas]
- Configure Atlas target: Atlas project, cluster tier, region [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-ops-manager/#live-migration-to-atlas]
- Start migration: Ops Manager agent pulls data into Atlas [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-ops-manager/#live-migration-to-atlas]
- Cutover: Same mongosync-based cutover process [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-ops-manager/#live-migration-to-atlas]
Datadog
- Ops Manager pushes MongoDB metrics to Datadog for unified observability. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-ops-manager/#datadog]
PagerDuty
- Configure in Ops Manager UI → Alerts → PagerDuty integration. Maps Ops Manager alert categories to PagerDuty incident severity. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-ops-manager/#pagerduty]
Splunk
- Export Ops Manager logs via syslog or file-based log forwarding. Configure Splunk Universal Forwarder on Ops Manager hosts. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-ops-manager/#splunk]
Ops Manager Upgrade Path
- Backup App DB before upgrade [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-ops-manager/#ops-manager-upgrade-path]
- Check compatibility matrix: Ops Manager version → MongoDB Agent version → MongoDB server version [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-ops-manager/#ops-manager-upgrade-path]
- Upgrade Ops Manager application (rolling upgrade supported for multi-node OM deployments) [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-ops-manager/#ops-manager-upgrade-path]
- Upgrade MongoDB Agents on all hosts (Ops Manager prompts for agent upgrade) [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-ops-manager/#ops-manager-upgrade-path]
- Verify: Check agent connectivity status in Ops Manager UI [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-ops-manager/#ops-manager-upgrade-path]
Anti-Patterns
- Single-node App DB: Ops Manager becomes unavailable if App DB node fails; always use 3-node RS [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-ops-manager/#anti-patterns]
- Backup Daemon on the MongoDB host: Backup creates I/O; place on dedicated host [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-ops-manager/#anti-patterns]
- Air-gap without pre-downloading all required MongoDB binaries: Automation will fail if the Agent can't find the requested version locally [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-ops-manager/#anti-patterns]
- Not using immutable S3 snapshots for compliance: Object Lock prevents accidental or malicious deletion of backup data [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-ops-manager/#anti-patterns]
- Manual edits to MongoDB configs outside Ops Manager automation: Ops Manager will reconcile these back to the goal state on next agent heartbeat [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-ops-manager/#anti-patterns]
References
- Ops Manager Documentation [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-ops-manager/#references]
- Cloud Manager Documentation [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-ops-manager/#references]
- MongoDB Kubernetes Operator (Community) [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-ops-manager/#references]
- Ops Manager Backup [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-ops-manager/#references]
- Ops Manager Authentication [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-ops-manager/#references]
Where this helps
- Running MongoDB in an air-gapped or heavily regulated data center where Atlas isn't an option, but automation, monitoring, and backup are still needed. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
- Planning a phased migration off self-managed MongoDB to Atlas, using the Live Migration integration instead of a from-scratch mongosync setup. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
- Sizing the App Database correctly before deploying at scale, so the management platform itself doesn't become the single point of failure it's meant to prevent. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
- Wiring alerts into an existing on-call stack (PagerDuty, Datadog, Splunk) so self-managed MongoDB gets the same alerting coverage Atlas provides out of the box. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
Project ideas
- Build an automation-config drift detector that diffs the declared goal-state JSON against what the Agent reports as actual state, flagging manual config edits before the next reconciliation silently reverts them. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
- Set up an air-gapped MongoDB binary mirror and pre-download workflow so new cluster deployments and version upgrades don't fail because the Agent can't find the requested version locally. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
- Implement immutable backup snapshots by enabling S3 Object Lock on the Backup Daemon's target bucket, satisfying a compliance requirement that backups can't be deleted even by a compromised admin account. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
- Build a Live Migration-to-Atlas runbook that walks through linking the source, selecting the cluster, and the mongosync-based cutover procedure. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
Common mistakes
- Running a single-node App Database, which makes the whole management platform unavailable the moment that one node fails — always deploy a 3-node replica set for the App DB. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
- Placing the Backup Daemon on the same host as a monitored MongoDB process, adding backup I/O contention to a host that's already serving production traffic. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
- Making manual configuration edits directly on a MongoDB host instead of through automation — the Agent reconciles the host back to the declared goal state on its next heartbeat, silently reverting the change. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
- Deploying to an air-gapped environment without pre-downloading every MongoDB binary version automation will need, causing deployment or upgrade failures the Agent can't resolve locally. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
Known issues
- Version support policy only covers the current version and the two before it (N, N-1, N-2), and the MongoDB Agent must be at or above that version — an outdated Agent can silently block newer automation features. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
- The App Database stores the platform's own operational state, separate from the MongoDB deployments it manages, so sizing it correctly is a distinct capacity-planning exercise from sizing the managed clusters themselves. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
- Upgrading requires checking a compatibility matrix across three moving parts — platform version, Agent version, and MongoDB server version — before starting a rolling upgrade. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
- Backup Compliance and Object Lock must be configured explicitly; without immutable S3 snapshots enabled, backup data remains deletable, which fails many compliance regimes' backup-integrity requirements. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
Children
- Ops Manager Application
- Application Database (App DB) (frontier, viability 3.95 / 5)
- Backup Daemon and Head DB
- MongoDB Agent (Automation, Monitoring, Backup) (frontier, viability 3.95 / 5)
- Goal-State Automation Configuration (frontier, viability 4.35 / 5)
- Continuous Backup with PITR (frontier, viability 3.88 / 5)
- Blockstore Snapshot Storage (frontier, viability 3.23 / 5)
- S3-Compatible Snapshot Storage with Object Lock (frontier, viability 3.60 / 5)
- Filesystem Snapshot Storage (frontier, viability 3.05 / 5, below research gate)
- Local Mode and Air-Gap Deployments (frontier, viability 4.05 / 5)
- Version Manifest Mirroring (frontier, viability 3.58 / 5)
- Ops Manager LDAP/Kerberos/SAML/OIDC Federation
- Workforce and Workload Identity Federation
- Kubernetes Operator Deployment
- Cloud Manager Free/Standard/Premium Tiers (frontier, viability 2.52 / 5, below research gate)
- Live Migration to Atlas via mongosync (frontier, viability 3.90 / 5)
- Migration Host Provisioning (frontier, viability 3.77 / 5)
- Source Oplog Window Sizing for Migration (frontier, viability 3.98 / 5)
- PagerDuty/Datadog/Splunk Integration (frontier, viability 3.45 / 5)
- OpenTelemetry MongoDB Receiver (frontier, viability 3.73 / 5)
- Enterprise Advanced Licensing (frontier, viability 2.90 / 5, below research gate)
- Ops Manager High Availability (frontier, viability 4.25 / 5)
- Cross-DC App DB Placement (frontier, viability 4.17 / 5)
- Backup Daemon HA and Failure Domains (frontier, viability 3.77 / 5)
- Ops Manager Architecture
- Automation Agent (frontier, viability 3.95 / 5)
- Monitoring Agent
- Backup Daemon
- Blockstore and Snapshot Stores (frontier, viability 4.20 / 5)
- Ops Manager Admin API (frontier, viability 3.55 / 5)
- LDAP and Federation (frontier, viability 3.38 / 5)
- Upgrade Procedures (frontier, viability 3.63 / 5)
- Common Failure Modes
- Multi-Org Scale Patterns
- Air-Gap and Local Mode
- Live Migration to Atlas (frontier, viability 3.45 / 5)
Frontier under this node: Application Database (App DB) (3.95), Automation Agent (3.95), Backup Daemon HA and Failure Domains (3.77), Blockstore Snapshot Storage (3.23), Blockstore and Snapshot Stores (4.20), Cloud Manager Free/Standard/Premium Tiers (2.52), Continuous Backup with PITR (3.88), Cross-DC App DB Placement (4.17), Enterprise Advanced Licensing (2.90), Filesystem Snapshot Storage (3.05), Goal-State Automation Configuration (4.35), LDAP and Federation (3.38), Live Migration to Atlas (3.45), Live Migration to Atlas via mongosync (3.90), Local Mode and Air-Gap Deployments (4.05), Migration Host Provisioning (3.77), MongoDB Agent (Automation, Monitoring, Backup) (3.95), OpenTelemetry MongoDB Receiver (3.73), Ops Manager Admin API (3.55), Ops Manager High Availability (4.25), PagerDuty/Datadog/Splunk Integration (3.45), S3-Compatible Snapshot Storage with Object Lock (3.60), Source Oplog Window Sizing for Migration (3.98), Upgrade Procedures (3.63), Version Manifest Mirroring (3.58)