AKO Independent CRDs

Parent: MongoDB Atlas Infrastructure as Code · Published reference · snapshot 2026-10-01

Depth-first rabbithole dossier for AKO Independent CRDs; source-anchored research pack.

These notes link each claim to its source. A source may be a research report hosted on this site rather than the primary document. 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.

Definitions

**Per claim, the gate is not met for the core content.** The timeline, the mapping and the migration procedures each come from MongoDB alone. No third-party write-up from a practitioner exists in any report. [source]

Structure and components

- M1. In the docs, "independent CRD" means a resource that is attached to an Atlas project by its Atlas ID, so AKO does not need to manage the project itself. — https://www.mongodb.com/docs/atlas/operator/current/ak8so-independent-crd/ - M2. Every independent-capable CRD enforces a CEL rule that exactly one of `projectRef` and `externalProjectRef` is set: "must define only one project reference through externalProjectRef or projectRef". — https://www.mongodb.com/docs/atlas/operator/current/atlasdatabaseuser-custom-resource/ - M3. If `externalProjectRef` is set, `connectionSecret` is mandatory: [source]

How it works

- **A1.** In the docs, "independent" means a resource attaches to its Atlas project **by Atlas ID** (`externalProjectRef`), so AKO does not manage the project itself. [M,H,E,P] https://www.mongodb.com/docs/atlas/operator/current/ak8so-independent-crd/ (inh-src) - **A2.** The v2.6–v2.9 release notes also call standalone CRs that replace `AtlasProject.spec.*` parameters "independent custom resources", even when they use `projectRef`. [H,E] https://github.com/mongodb/mongodb-atlas-kubernetes/releases/tag/v2.8.0 - **A3.** The docs call the second move "migrate parameters to custom resource definit [source]
Report tags: **[M]** mechanism.md · **[H]** history.md · **[E]** edge-cases.md · **[P]** practice.md. **(inh-src)** marks a claim whose only source is the inherited Independent CRDs Guide. Those claims add new content but do not count toward the independent-origin gate. [source]
- The parent extract uses "independent CRDs" for two different things. MongoDB's docs use the term narrowly: a resource is "independent" when it references its Atlas project **by Atlas ID** (`externalProjectRef`) and not through an `AtlasProject` Kubernetes object. https://www.mongodb.com/docs/atlas/operator/current/ak8so-independent-crd/ - The other thing is the 2.6+ move of `AtlasProject.spec.*` *parameters* into **standalone CRDs**. MongoDB's docs call it "migrate parameters to custom resource definitions". https://www.mongodb.com/docs/atlas/operator/current/migrate-parameter-to-resource/ - [source]
1. In the independent model, you manage resources inside an Atlas project with AKO **without** AKO managing the project itself. You link each resource to the project by its Atlas project ID. — https://www.mongodb.com/docs/atlas/operator/current/ak8so-independent-crd/ 2. AKO 2.5.0 first made `AtlasDeployment` and `AtlasDatabaseUser` usable as independent resources. — https://www.mongodb.com/docs/atlas/operator/current/ak8so-changelog/ 3. The external reference type is `ExternalProjectReference` with a single required field, `id` (JSON `id`). — https://raw.githubusercontent.com/mongodb/mongodb-a [source]
8. The CRDs carry two CEL rules. Rule 1: `(has(self.externalProjectRef) && !has(self.projectRef)) || (!has(self.externalProjectRef) && has(self.projectRef))`. Its message is "must define only one project reference through externalProjectRef or projectRef". https://www.mongodb.com/docs/atlas/operator/current/atlasdeployment-custom-resource/ 9. Rule 2: `(has(self.externalProjectRef) && has(self.connectionSecret)) || !has(self.externalProjectRef)`. Its message is "must define a local connection secret when referencing an external project". https://www.mongodb.com/docs/atlas/operator/current/atlas [source]

Measurements and reference values

| Pass | Focus | New atomic claims | Running total | New-info rate | |---|---|---|---|---| | 0 | independent-CRD page | 9 | 9 | 100% | | 1 | migration guide, IPAL/DBUser/Deployment schemas, changelog 2.5–2.11 | 20 | 29 | 69% | | 2 | GitHub issues #2869/#2001/#2234, releases 2.9/2.14/2.17, generated CRDs | 13 | 42 | 31% | [source]
Verdict: **BUDGET_EXHAUSTED (soft stop)**, not SATURATED-DEPTH. Only one pass came in under 5%. One more pass looks likely to pay off: reading the `AtlasDatabaseUser`/`AtlasDeployment` independent examples and the GitHub PRs that added `ProjectDualReference`, to settle D4 and D5. [source]
Saturation: **BUDGET_EXHAUSTED (soft stop), not SATURATED-DEPTH.** New-information rate per pass: P0 docs 14/14 = 100%; P1 changelog + migration 10/24 ≈ 42%; P2 Go source 6/30 = 20%; P3 annotations/deletion 3/33 ≈ 9%; P4 third-party sweep 1/34 ≈ 3%. One more pass would likely still pay off. It would need a reconcile-time lab test (D4/D5) or the AKO controller source for subresource handlers, not more doc reading. [source]

Problems, failure modes and limitations

| Parent says | Primary sources say | |---|---| | "Starting with v2.6", subobjects moved out | The rollout was staggered across 2.5, 2.6, 2.7, 2.8 and 2.9 (F1–F9) [M,H,E,P] | | Moved items include "database users … teams" | `AtlasDatabaseUser` was never an `AtlasProject` subobject (F2). Teams are not in the migration table and are not deprecated (G1, G3) [M,H,E,P] | | Independent CRDs are "referenced by `projectRef`" | The docs use "independent" for `externalProjectRef`. Standalone CRDs accept either reference (A1–A3) [M,H,E,P] | | "Operator alternates" between subobject and CRD | Disputed: se [source]
- **H1.** Each project allows at most one `AtlasIPAccessList`. Issue #2869 (AKO 2.11.0) reports that the CR reconciling last wins and deletes entries created by the other CRs. It was closed "not planned". E1 explains why. As a result, the parent's claim that independent CRDs "split RBAC across namespaces" fails for IP lists. [M,H,E,P] https://github.com/mongodb/mongodb-atlas-kubernetes/issues/2869 - **H2.** Because `entries` requires at least one item (`MinItems=1`), you cannot clear a project's IP list by applying an empty `AtlasIPAccessList`. [P] same source as B4 - **H3.** Issue #2001 (open [source]
- **X1. What "independent" means.** - Docs concept page: it means `externalProjectRef` (A1). - Release notes: any standalone CR that replaces a parameter (A2). - Both usages are current. - **X2. When the change started.** - The migration guide says "Beginning with … version 2.6" for all six parameters. https://www.mongodb.com/docs/atlas/operator/current/migrate-parameter-to-resource/ - The changelog dates independent mode to 2.5 and the CRDs and deprecations to 2.6, 2.7, 2.8 and 2.9. https://www.mongodb.com/docs/atlas/operator/current/ak8so-changelog/ - **X3. Field name: `externalProjectRef.id [source]
- C1. The parent says independent CRDs arrived "starting with v2.6". The changelog shows a staggered rollout: `AtlasDeployment` and `AtlasDatabaseUser` became independent in 2.5.0; `AtlasPrivateEndpoint` and `AtlasCustomRole` in 2.6.0; `AtlasIPAccessList` in 2.7.0; `AtlasNetworkPeering` and `AtlasNetworkContainer` in 2.8.0. — https://www.mongodb.com/docs/atlas/operator/v2.11/ak8so-changelog/ - C2. `AtlasThirdPartyIntegration` became an independent CRD in v2.9.0, and that release deprecated `AtlasProject.spec.integrations`. — https://github.com/mongodb/mongodb-atlas-kubernetes/releases/tag/v2.9 [source]
- G1. Since v2.14, AKO ships CRDs generated from the Atlas Admin API OpenAPI spec. — https://github.com/mongodb/mongodb-atlas-kubernetes/releases/tag/v2.14.0 - G2. The docs say the existing CRD set (which includes the hand-written independent CRDs) "Will be deprecated in a future release". They say generated CRDs "Will become the standard for managing Atlas resources through Atlas Kubernetes Operator". This contradicts the parent's framing of independent CRDs as the "preferred" end state. — https://www.mongodb.com/docs/atlas/operator/v2.14/generated-crds-overview/ - G3. "Generated CRDs are **n [source]
- **In scope:** what "independent CRD" means in AKO, which resource kinds support it, the release in which each kind gained support, the `projectRef`/`externalProjectRef`/`connectionSecret` mechanism, the deprecation of the `AtlasProject.spec.*` parameter form, the migration procedure, and documented failure modes. - **Out of scope:** Terraform, the CLI, Pulumi, CloudFormation and CDK. Also out: AKO dry-run as a feature, Service Account auth beyond its link to `connectionSecret`, and other AKO CRDs studied for their own sake. - **Tooling limit:** Firecrawl and Bash were denied in this session. [source]
- **I1.** Since v2.14, AKO ships CRDs generated from the Atlas Admin API OpenAPI spec. [E] https://github.com/mongodb/mongodb-atlas-kubernetes/releases/tag/v2.14.0 - **I2.** The docs say the existing hand-written CRD set "Will be deprecated in a future release", and generated CRDs "Will become the standard". [E] https://www.mongodb.com/docs/atlas/operator/v2.14/generated-crds-overview/ - **I3.** Generated CRDs are not compatible with the existing set. One Atlas resource cannot be managed by both. [E] same source as I2 - **I4.** The generated `IPAccessListEntry` holds one entry per resource. It [source]
1. **Deprecation version.** The migration guide says all subobjects were deprecated in 2.6 (C3). The changelog and release notes say 2.6 to 2.9 (C1, C2). Both are official. The per-release changelog is more specific and is probably the more accurate one. 2. **Whether multiple `AtlasIPAccessList` CRs should merge.** A user expected merge behavior (#2869). The docs and maintainers keep one authoritative list per project ("closed as not planned"). No visible maintainer rationale was captured. 3. **Status of issue #2001.** The GitHub issue list shows it closed 2025-01-13. The issue page excerpt di [source]
- C1. The docs define the "independent CRD" model this way: AKO manages resources in an Atlas project without managing the project itself. You associate a resource "with an Atlas project directly by its Atlas ID." Source: https://www.mongodb.com/docs/atlas/operator/current/ak8so-independent-crd/ - C2. The stated purpose: "use different programmatic infrastructure management systems for your projects, while you use Atlas Kubernetes Operator to manage more frequently-altered resources such as database users or individual deployments." Source: https://www.mongodb.com/docs/atlas/operator/current/a [source]
31. Parameter → CRD migration has five steps: (1) annotate the `AtlasProject` with `mongodb.com/atlas-reconciliation-policy: "skip"`, (2) delete the parameter from the `AtlasProject`, (3) create the new CRD, (4) wait for sync, (5) remove the skip annotation. https://www.mongodb.com/docs/atlas/operator/current/migrate-parameter-to-resource/ 32. The doc warns about skipping the annotation: AKO keeps reconciling. With deletion protection disabled, it can remove the Atlas project, or block while trying to remove a project that still has subresources. https://www.mongodb.com/docs/atlas/operator/cur [source]
37. **2.5.0** added per-resource local credentials and made `AtlasDeployment` and `AtlasDatabaseUser` usable as independent resources. https://www.mongodb.com/docs/atlas/operator/current/ak8so-changelog/ 38. **2.6.0** added the `AtlasPrivateEndpoint` and `AtlasCustomRole` CRDs. https://www.mongodb.com/docs/atlas/operator/current/ak8so-changelog/ 39. **2.7.0** added `AtlasIPAccessList` and deprecated IP lists on `AtlasProject`. https://www.mongodb.com/docs/atlas/operator/current/ak8so-changelog/ 40. **2.8.0** added the `AtlasNetworkPeering` and `AtlasNetworkContainer` independent resources and [source]
11. Six `AtlasProject` parameters are deprecated in favour of standalone CRDs: `customRoles`→`AtlasCustomRole`, `privateEndpoints`→`AtlasPrivateEndpoint`, `projectIpAccessList`→`AtlasIPAccessList`, `networkPeers`→`AtlasNetworkPeering`, `networkPeers.containerId`→`AtlasNetworkContainer`, `integrations`→`AtlasThirdPartyIntegration`. Existing parameter configs keep working until a future removal. — https://www.mongodb.com/docs/atlas/operator/current/migrate-parameter-to-resource/ 12. Per the changelog: 2.6.0 added `AtlasPrivateEndpoint` and `AtlasCustomRole`; 2.7.0 added `AtlasIPAccessList` and d [source]
- **G1.** The migration table lists exactly six mappings, and teams are not among them [M,H,E,P] https://www.mongodb.com/docs/atlas/operator/current/migrate-parameter-to-resource/: - `customRoles`→`AtlasCustomRole` - `privateEndpoints`→`AtlasPrivateEndpoint` - `projectIpAccessList`→`AtlasIPAccessList` - `networkPeers`→`AtlasNetworkPeering` - `networkPeers.containerId`→`AtlasNetworkContainer` - `integrations`→`AtlasThirdPartyIntegration` - **G2.** `cloudProviderAccessRoles`→`cloudProviderIntegrations` is a field change within the same CR, not a new CRD. [M,H] https://www.mongodb.com/docs/atlas/ [source]
- C9. **v2.5.0 (2024-10-29).** "AtlasDeployment can now be used as an independent resource" and "AtlasDatabaseUser can now be used as an independent resource, meaning you can manage Atlas Database Users without also managing the Project." This was the first independent mode, and it had nothing to do with `AtlasProject` subobjects. Source: https://github.com/mongodb/mongodb-atlas-kubernetes/releases/tag/v2.5.0 and https://www.mongodb.com/docs/atlas/operator/current/ak8so-changelog/ - C10. **v2.6.0 (2024-12-20).** "Private Endpoints can now be optionally configured as an independent custom resou [source]
- C17. The official migration table lists exactly six mappings: `spec.customRoles`→`AtlasCustomRole`, `spec.privateEndpoints`→`AtlasPrivateEndpoint`, `spec.projectIpAccessList`→`AtlasIPAccessList`, `spec.networkPeers`→`AtlasNetworkPeering`, `spec.networkPeers.containerId`→`AtlasNetworkContainer`, `spec.integrations`→`AtlasThirdPartyIntegration`. Teams are not listed. Source: https://www.mongodb.com/docs/atlas/operator/current/migrate-parameter-to-resource/ - C18. The migration guide says: "Beginning with Atlas Kubernetes Operator version 2.6, various resource configurations that previously too [source]
- C22. If you omit the skip annotation, AKO keeps reconciling the parent. If deletion protection is disabled, deleting the `atlasProject` can remove the Atlas project. AKO can also block while it tries to delete a project that still has active subresources. Source: https://www.mongodb.com/docs/atlas/operator/current/migrate-parameter-to-resource/ - C23. Each project allows only one instance of a given third-party integration type, whether it comes from `spec.integrations` or from an `AtlasThirdPartyIntegration`. The two forms cannot coexist for the same type. Source: https://www.mongodb.com/do [source]
14. If `projectRef` is set, the reconciler fetches the `AtlasProject` object. If `projectRef.namespace` is empty, it defaults to the referring resource's namespace. It then calls `GetProjectByName` with the `AtlasProject`'s `spec.name`. https://raw.githubusercontent.com/mongodb/mongodb-atlas-kubernetes/main/internal/controller/reconciler/project.go 15. If the `AtlasProject` is missing, resolution fails with `ErrMissingKubeProject` ("error getting AtlasProject: %w"). The code does not check that the referenced `AtlasProject` is Ready. https://raw.githubusercontent.com/mongodb/mongodb-atlas-kube [source]
8. Credential precedence: a resource's `spec.connectionSecret.name` overrides `AtlasProject.spec.connectionSecretRef.name`, which overrides the global operator credentials. — https://www.mongodb.com/docs/atlas/operator/current/ak8so-independent-crd/ 9. A resource with `externalProjectRef` cannot inherit API credentials from a parent project. — https://www.mongodb.com/docs/atlas/operator/current/atlasipaccesslist-custom-resource/ 10. Operational implication: each namespace that holds independent resources needs its own Atlas credential Secret, because Kubernetes Secrets are namespace-scoped. Th [source]
15. Each Atlas project supports at most one `AtlasIPAccessList` resource. Multiple such resources for the same project conflict. — https://www.mongodb.com/docs/atlas/operator/current/atlasipaccesslist-custom-resource/ 16. AKO uses the Project IP Access List API to "create new IP access lists or replace existing ones". — https://www.mongodb.com/docs/atlas/operator/current/atlasipaccesslist-custom-resource/ 17. `AtlasIPAccessList.spec.entries` is required with `MinItems=1`. You cannot clear a project's list by applying an empty `AtlasIPAccessList`. — https://raw.githubusercontent.com/mongodb/mon [source]
27. MongoDB's stated benefit: splitting project management from subresource management lets you give users, deployments and the project to different people or teams. — https://www.mongodb.com/docs/atlas/operator/current/ak8so-independent-crd/ 28. Cost of that split: credentials move from one `AtlasProject` secret to one secret per resource or namespace (claims 8–10). Secret rotation and least-privilege scoping become per-team work. — derived from https://www.mongodb.com/docs/atlas/operator/current/ak8so-independent-crd/ and https://github.com/mongodb/mongodb-atlas-kubernetes/issues/215 29. `ex [source]

Comparisons and alternatives

- **F1.** **2.5.0 (2024-10-29):** per-resource local credentials, and `AtlasDeployment` and `AtlasDatabaseUser` usable as independent resources. The independent-deployment PR #1773 merged 2024-10-14. [M,H,E,P] https://github.com/mongodb/mongodb-atlas-kubernetes/releases/tag/v2.5.0 - **F2.** `AtlasDatabaseUser` was never an `AtlasProject` subobject, so the first independent mode was unrelated to the subobject deprecation. [H] - **F3.** **2.6.0 (2024-12-20):** `AtlasPrivateEndpoint` and `AtlasCustomRole`, described as "optionally" independent. The custom-role PR #1913 merged 2024-11-19. [M,H] ht [source]
- E1. **One `AtlasIPAccessList` per project.** "Each Atlas project supports at most one `AtlasIPAccessList` resource. If you define multiple `AtlasIPAccessList` resources for the same project, they conflict with one another." — https://www.mongodb.com/docs/atlas/operator/current/atlasipaccesslist-custom-resource/ - E2. In practice, each `AtlasIPAccessList` CR is treated as the authoritative list. The CR that reconciles last overwrites the Atlas access list and deletes entries that other CRs created. This was reported on AKO 2.11.0 and closed "not planned". — https://github.com/mongodb/mongodb- [source]
- **C1. Two concepts were merged into one.** MongoDB's docs use "independent CRD" for a *reference model*: a resource points at an Atlas project by Atlas ID (`externalProjectRef`) instead of at an `AtlasProject` Kubernetes object. AKO 2.5.0 introduced this for `AtlasDeployment` and `AtlasDatabaseUser`. Separately, from 2.6 onwards, `AtlasProject.spec.*` parameters were split into standalone CRDs. The parent text treats both as "independent CRDs referenced by projectRef". The standalone CRDs actually accept **either** `projectRef` **or** `externalProjectRef`. — https://www.mongodb.com/docs/atla [source]
- **D1. Two meanings of "independent".** - *Sense A (docs concept page):* independent means `externalProjectRef`. The resource targets an Atlas project that this AKO instance does not manage (C1). https://www.mongodb.com/docs/atlas/operator/current/ak8so-independent-crd/ - *Sense B (release notes v2.6–v2.9):* "independent custom resource" means a standalone CR that replaces an `AtlasProject.spec` parameter, even when it uses `projectRef` (C10–C14). https://github.com/mongodb/mongodb-atlas-kubernetes/releases/tag/v2.8.0 - The migration guide's `AtlasCustomRole` example uses `projectRef`, which [source]
In scope: what MongoDB calls "independent CRDs" in the Atlas Kubernetes Operator, plus the related move of `AtlasProject.spec.*` subobjects into standalone CRDs. That covers the reference model (`projectRef` vs `externalProjectRef`), credential handling, validation rules, migration procedure, conflict and deletion behaviour, and the operational trade-offs. [source]
Out of scope: the full AKO CRD catalogue, Terraform/Pulumi/CFN, dry-run mode as a feature, Service Account vs API key auth as a topic, and the MongoDB Community/Enterprise Operator. [source]
- **`externalProjectRef.id` vs `.projectId`.** Source (`json:"id"`) and the `AtlasDeployment` reference say `id`. The `AtlasIPAccessList` page example uses `externalProjectRef.projectId`. The source wins, so the IP-list example looks wrong. https://raw.githubusercontent.com/mongodb/mongodb-atlas-kubernetes/main/api/v1/externalreference.go vs https://www.mongodb.com/docs/atlas/operator/current/atlasipaccesslist-custom-resource/ - **`keep` policy key.** The migration guide's `AtlasCustomRole` example sets `mongodb.com/atlas-reconciliation-policy: keep` as a *label*. In code, `keep` is a value of [source]
- Hosts used: www.mongodb.com, github.com, raw.githubusercontent.com, kubernetes.io. Four hosts, so the "≥3 sources on different hosts" bar is met. - **Publisher independence is only partly met.** Three of the four hosts are MongoDB-authored (docs, repo, source). kubernetes.io is the only independent publisher, and it corroborates only the admission-validation mechanism (claims 11–12). - No third-party practitioner write-up of externalProjectRef was found. - The disconfirming search turned up internal contradictions instead: doc vs source, and the changelog vs the parent extract (listed above) [source]
- **D1. When the split started.** The migration page says the six parameters moved "starting with Atlas Kubernetes Operator version 2.6" (https://www.mongodb.com/docs/atlas/operator/current/migrate-parameter-to-resource/). The changelog dates `AtlasIPAccessList` to 2.7.0 and peering/container to 2.8.0 (https://www.mongodb.com/docs/atlas/operator/current/ak8so-changelog/). The parent fact repeats "v2.6" for all of them. The release that added `AtlasThirdPartyIntegration` was not found. - **D2. External ref field name.** The Go source and the independent-CRD page use `externalProjectRef.id` (htt [source]

Facts and statements

Run: /rabbithole, 2026-10-01. Concept: "AKO Independent CRDs" (Atlas Kubernetes Operator). [source]
Run: /rabbithole, 2026-10-01. Concept: **AKO Independent CRDs** (child of *MongoDB Atlas Infrastructure as Code*). [source]
IN: the independent-CRD model of the Atlas Kubernetes Operator (AKO): `projectRef` / `externalProjectRef` semantics, `connectionSecret` rules, the subobject → independent migration, conflicts between the two models, deletion behavior, per-CRD cardinality limits, and the version history of each independent CRD. OUT: sibling AKO topics (dry-run, Terraform, generated-CRD internals beyond their relation to independent CRDs), the parent IaC domain, and the MongoDB Community/Enterprise Operator. [source]
1. Independent CRDs let AKO manage resources in an Atlas project without AKO managing the project itself. The resource is tied to the project "directly by its Atlas ID". https://www.mongodb.com/docs/atlas/operator/current/ak8so-independent-crd/ 2. In source, the shared reference struct is `ProjectDualReference`. Its comment says it "encapsulates the common constructs to refer to a parent project; by either a Kubernetes reference or an external ID, which also requires access credentials". https://raw.githubusercontent.com/mongodb/mongodb-atlas-kubernetes/main/api/v1/projectref.go 3. `ProjectDua [source]
Excluded as inherited: the Independent CRDs Guide (https://www.mongodb.com/docs/atlas/operator/current/ak8so-independent-crd/) and the seven shared-cache files (none were used). [source]
- AKO dry-run mode, including how it reports conflicts - Generated or OpenAPI CRDs (v2.14+) - Service Account credentials in `connectionSecret` (2.15.0) - Deletion protection and `atlas-resource-policy` - `AtlasTeam` lifecycle - `cloudProviderAccessRoles`→`cloudProviderIntegrations` [source]
The parent says that **starting with v2.6** network peering, database users, integrations and teams moved out of `AtlasProject.spec.*` into independent CRDs. The primary sources contradict this in four places: [source]
AKO dry-run mode (v2.8.0, public preview); AKO Service Account auth for `connectionSecret` (v2.15.0); AKO deletion protection / `atlas-resource-policy`; OpenAPI-generated CRDs (v2.14.0); `cloudProviderAccessRoles`→`cloudProviderIntegrations`. [source]
In scope: how an Atlas Kubernetes Operator (AKO) resource attaches to an Atlas project without an `AtlasProject` parent. That covers the `ProjectDualReference` fields, the validation invariants, how the operator resolves the project and credentials, how ownership and deletion work, the move from `AtlasProject.spec.*` parameters to standalone CRDs and how that migration works, the version timeline, and known limits. [source]
At least 3 independent sources: **met, but weakly on independence.** I used 3 hosts: mongodb.com (docs + changelog), github.com / raw.githubusercontent.com (MongoDB's own source and issue tracker), and the redhat-openshift-ecosystem catalogue PR. Two of them are MongoDB-authored. I found no third-party practitioner write-up on independent CRDs. The search for a disconfirming source turned up internal inconsistencies in MongoDB's own docs instead (D1–D3), and they are recorded above. [source]
The gate is **narrowly met at origin level: 3 origins.** 1. **MongoDB:** the other docs pages, changelog, releases, source code, REST API and pkg.go.dev. 2. **The Kubernetes project:** supports C4 and C5 only. 3. **Outside GitHub issue reporters (#265, #2869, #2001, #2234):** support H1, H3, F8 and F11. [source]
- **E1.** The `AtlasIPAccessList` controller compares its spec with Atlas using `collection.MapDiff`. It **deletes Atlas entries that are not in its spec** and keeps no last-applied annotation. [M] https://raw.githubusercontent.com/mongodb/mongodb-atlas-kubernetes/main/internal/controller/atlasipaccesslist/state.go - **E2.** The docs say AKO uses the Project IP Access List API to "create new IP access lists or replace existing ones". [P] https://www.mongodb.com/docs/atlas/operator/current/atlasipaccesslist-custom-resource/ - **E3.** The legacy `AtlasProject` paths for IP lists, peering and cus [source]
The OpenShift catalogue PR sits on an independent host, but its content is MongoDB's bundle, so it counts only as weak support for F10. [source]
The gate is met with caveats. The report uses 3 source hosts: `mongodb.com` (official docs), `github.com` (releases plus third-party user bug reports), and `pkg.go.dev` (Go API index). Disconfirming sources were found and used (E2, E12, G2, D1). Caveats: `github.com` releases and `pkg.go.dev` are MongoDB-authored artifacts. The GitHub issues are the only non-MongoDB voices. No independent third-party blog or talk on this concept turned up. Firecrawl and shell access were denied, so this run did not read raw CRD YAML or controller source. The shared parent cache was not used: its one AKO-adjace [source]
1. The split was staggered across v2.6, v2.7, v2.8 and v2.9 (claims C10–C14). It did not happen in one release. 2. `AtlasDatabaseUser` was never an `AtlasProject` subobject. In v2.5 it gained the separate *independent* (external-project) mode (C9). 3. Teams are not in the official parameter-to-CRD migration table (C17). 4. "Independent CRD" has two meanings in MongoDB's own sources. The disagreements section covers this (D1). [source]
- C20. Parameter→CRD migration has five steps: (1) annotate the `AtlasProject` with `mongodb.com/atlas-reconciliation-policy: "skip"`; (2) delete the parameter from the parent; (3) create the new CR, using `projectRef` with name and namespace; (4) wait for AKO to sync; (5) remove the skip annotation. Source: https://www.mongodb.com/docs/atlas/operator/current/migrate-parameter-to-resource/ - C21. Moving a resource to the external-project mode follows a separate four-step procedure. You skip-annotate the parent and repoint the reference to an Atlas project ID. You then wait for sync. Optionally [source]
The gate is **only partly met.** Five source origins were used: mongodb.com docs, GitHub release notes, GitHub source code, the GitHub REST API, and one GitHub issue by an outside user. Four of the five are controlled by MongoDB. The only non-MongoDB voice is the issue #265 author. No independent third-party writeup (blog, conference talk, vendor comparison) covers the external-project mode or the parameter-to-CRD split. A non-MongoDB search returned only the unrelated Ariga "Atlas Kubernetes Operator" for schema migrations (https://atlasgo.io/integrations/kubernetes), which is a name collisio [source]
22. The `AtlasIPAccessList` controller diffs its spec directly against Atlas with `collection.MapDiff`. It adds entries that are missing and **deletes Atlas entries absent from its spec**. It uses no last-applied annotation. https://raw.githubusercontent.com/mongodb/mongodb-atlas-kubernetes/main/internal/controller/atlasipaccesslist/state.go 23. This full-ownership diff explains the documented rule that each project supports "at most one `AtlasIPAccessList` resource", and that multiple resources for one project "conflict with one another". https://www.mongodb.com/docs/atlas/operator/current/at [source]
43. AKO does not support Atlas "Infinite Database" clusters in public preview. The independent-CRD page notes this. https://www.mongodb.com/docs/atlas/operator/current/ak8so-independent-crd/ 44. In `projectRef` mode, resolution goes through the `AtlasProject`'s `spec.name`, not an ID (claim 14). In `externalProjectRef` mode, the stable Atlas ID is used. Inference: only external mode survives a project rename without a Kubernetes edit. https://raw.githubusercontent.com/mongodb/mongodb-atlas-kubernetes/main/internal/controller/reconciler/project.go [source]
Researched 2026-10-01. Docs version observed: Atlas Kubernetes Operator (AKO) v2.17 ("current"). [source]
Out of scope: sibling CRDs' full field specs, Terraform/Pulumi/CFN, the parent IaC domain, and the MongoDB Community/Enterprise Operator. [source]
21. Independent-model migration: (1) annotate the `AtlasProject` with `mongodb.com/atlas-reconciliation-policy: "skip"`; (2) change each child from `spec.projectRef.name` to `spec.externalProjectRef.id` and add `connectionSecret`; (3) wait for the status to sync; (4) either delete the `AtlasProject` or remove the annotation if other children still use it. — https://www.mongodb.com/docs/atlas/operator/current/ak8so-independent-crd/ 22. Parameter-to-CRD migration: (1) apply the skip annotation **and** delete the parameter block; (2) create the standalone CRD; (3) wait for the sync; (4) remove th [source]
Handoffs (not pursued, siblings): AKO dry-run mode for conflict detection; Atlas Service Account auth in AKO (2.15.0); `AtlasTeam` / teams lifecycle. [source]

Related concepts

Independent — is a part of AKO Independent CRDs
AKO — is a part of AKO Independent CRDs
CRDs — is a part of AKO Independent CRDs

Children

No children recorded.

← the whole tree · 3D view· how to read this page