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 (frontier, viability 3.27 / 5)
- Application Database (App DB) (frontier, viability 3.95 / 5)
- Backup Daemon and Head DB (frontier, viability 2.88 / 5, below research gate)
- 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 (frontier, viability 2.88 / 5, below research gate)
- Workforce and Workload Identity Federation (frontier, viability 2.58 / 5, below research gate)
- Kubernetes Operator Deployment (frontier, viability 3.42 / 5)
- 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 (frontier, viability 3.33 / 5)
- Automation Agent (frontier, viability 3.95 / 5)
- Monitoring Agent (frontier, viability 2.58 / 5, below research gate)
- Backup Daemon (frontier, viability 3.45 / 5)
- 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 (frontier, viability 3.30 / 5)
- Multi-Org Scale Patterns (frontier, viability 3.15 / 5, below research gate)
- 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 (3.45), Backup Daemon HA and Failure Domains (3.77), Backup Daemon and Head DB (2.88), Blockstore Snapshot Storage (3.23), Blockstore and Snapshot Stores (4.20), Cloud Manager Free/Standard/Premium Tiers (2.52), Common Failure Modes (3.30), 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), Kubernetes Operator Deployment (3.42), 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), Monitoring Agent (2.58), Multi-Org Scale Patterns (3.15), OpenTelemetry MongoDB Receiver (3.73), Ops Manager Admin API (3.55), Ops Manager Application (3.27), Ops Manager Architecture (3.33), Ops Manager High Availability (4.25), Ops Manager LDAP/Kerberos/SAML/OIDC Federation (2.88), 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), Workforce and Workload Identity Federation (2.58)