Multi-Org Scale Patterns
Parent: MongoDB Ops Manager and Cloud Manager · Published reference · snapshot 2026-10-23 · skill mongodb-cohort-6a1c409b355b
↓ Facts as markdownall context files
Source-anchored research for Multi-Org Scale Patterns. Run status: COMPLETED.
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.
How it works
- A project boundary does not restrict an Organization Owner: that role has Project Owner access to every project in its organization even when explicitly assigned a weaker project role. Global roles extend equivalent privileges across all organizations and projects, so multi-org governance must account for global administrators. (low confidence) [source]
- Operator configuration makes the organizational mapping explicit through Ops Manager baseUrl, orgId and projectName plus an API credential Secret. Treat these mappings as deployment configuration when standardizing project provisioning across application teams. The cited examples use the legacy Enterprise Kubernetes Operator and require version-specific review before reuse. (medium confidence) [source]
- Specify and review the target organization and project explicitly when predictable placement matters. The operator documentation describes project creation for a missing name and organization creation when orgId is an empty string; Kinekube warns that a mistyped project name can silently create a new project. (high confidence) [source]
How-to and procedures
- Use separate projects when network-separated environments prevent monitoring all hosts with a single agent. Each project has its own monitoring, backup and automation context; projects can also separate deployments in the same network. (low confidence) [source]
- Use teams to assign project access repeatedly: an Ops Manager user can belong to multiple organizations, projects and teams, and a team can be assigned to multiple projects with project-specific roles. Ops Manager accounts are distinct from database users. (medium confidence) [source]
Comparisons and alternatives
- A concrete application separation pattern appears in Sharptree’s MAS 8 tutorial: one maximo organization contains separate ibm-sls and ibm-mas projects, with separate operator ConfigMaps and credential Secrets. Both ConfigMaps carry the same orgId and Ops Manager baseUrl but different projectName values. This is a historical implementation example rather than evidence of large-fleet capacity. (medium confidence) [source]
Facts and statements
- Ops Manager groups deployments into projects and projects into organizations. Organizations provide a central place to manage teams and assign their access to projects; this hierarchy supports shared administration of multiple application teams. (high confidence) [source]
- Project consolidation couples database security administration. Managed MongoDB users and roles are synchronized to all deployments in the project; separating applications into projects avoids sharing this managed-user scope. The general project-security coupling appears in the Red Hat operator integration explanation as well as MongoDB documentation. (medium confidence) [source]
- Do not interpret project security coupling as requiring every deployment to have identical database users. Ops Manager documents an Enforce Consistent Set option: YES removes unmanaged users and roles, whereas NO permits deployment-local unmanaged users and roles while managed users and roles remain synchronized. (low confidence) [source]
- Moving a project between organizations requires Organization Owner access in both organizations. Ops Manager removes project users who do not belong to the target organization, so organizational restructuring can change project membership. (low confidence) [source]
- A 2020 Go-client issue records an Ops Manager user depending on name-filtered organization listing while the cited client ListOptions exposed only pagination. This is historical evidence that fleet automation must verify client support for needed API filters; it does not establish a current client defect. (low confidence) [source]
- For Kubernetes provisioning, a ConfigMap identifies the management endpoint, organization ID, and optionally the project name; an API-credential Secret supplies access. The operator creates a named project if it does not exist. This mapping is documented and demonstrated in the Kinekube walkthrough. (high confidence) [source]
- The Kubernetes project-ConfigMap documentation restricts deployment to one MongoDB resource per project, citing project-level database authentication configuration. Separately, Nutanix recommends one project per NDB-managed deployment while explicitly stating that Ops Manager itself supports multiple deployments per project. Treat these as distinct scopes. (high confidence) (verified as of 2026-10-14) [source]
- A reusable Kubernetes provisioning pattern omits projectName so the operator derives each project name from the deployed resource name. This reuses the ConfigMap while keeping separate project mappings. (low confidence) [source]
- For creation inside an existing organization, the operator documentation requires Organization Project Creator privileges. Kinekube uses that role for the provisioning API key. This supports a narrower project-creation pattern than copying Organization Owner credentials from a lab. (high confidence) [source]
- Organization boundaries retain higher-level administrator access: Organization Owner receives Project Owner access throughout its organization, and global roles extend equivalent privileges across organizations. Sharptree’s lab assigns Organization Owner to application API keys; copying that example therefore grants organization-wide project authority. (high confidence) [source]
- Nutanix documents an integration pattern in which one Ops Manager hosts multiple registered databases and one NDB instance integrates with multiple Ops Manager instances. This demonstrates possible management partitioning, but supplies no measured organization-count capacity. (low confidence) [source]
Children
- Project partitioning by application and network boundary (frontier)
- Cross-organization access governance (frontier)
- Declarative organization and project provisioning (frontier)
- Project naming and organization placement (frontier)
- Delegated project provisioning (frontier)
- Cross-organization administrator privileges (frontier)
Frontier under this node: Cross-organization access governance, Cross-organization administrator privileges, Declarative organization and project provisioning, Delegated project provisioning, Project naming and organization placement, Project partitioning by application and network boundary