// the find
crossplane/crossplane
The Cloud Native Control Plane
Crossplane is a Kubernetes-native control plane framework that lets you define and manage cloud infrastructure through CRDs and a composition system, without writing controllers. It's aimed at platform teams who want to build internal developer platforms on top of Kubernetes, abstracting away cloud-specific APIs into organization-defined schemas.
- The composition functions model (pipeline of gRPC-based functions) is a genuinely clever escape hatch from the limitations of the original patch-and-transform system — lets you write real logic in any language without forking the core
- Package management is solid: providers, functions, and configurations ship as OCI images with dependency locking, versioning, and signature verification via cosign support in ImageConfig
- Active CNCF project with a real release cadence (quarterly minor releases, documented EOL dates), public roadmap tracked in GitHub Projects, and a v1-to-v2 migration path that isn't just 'rewrite everything'
- Design docs are committed directly to the repo under /design, so you can trace why decisions were made rather than hunting through years of GitHub issues
- The learning curve is brutal — you need to understand XRDs, XRs, Claims, Compositions, Functions, Providers, and their revision objects before you can do anything useful; onboarding a new team member is a multi-day exercise
- Composition debugging is still painful in practice: when a composite resource gets stuck, the error messages are often buried in provider pod logs or function runner logs, and the status conditions on the XR are frequently too vague to act on without cross-referencing multiple objects
- Provider sprawl is a real operational burden — a non-trivial AWS setup might run 10+ provider pods each with their own CRDs, RBAC, and resource consumption; at scale this hammers the API server with CRD count and watch pressure
- The v1-to-v2 migration (breaking changes to composition pipeline semantics and XRD schema) means teams on v1.20 are in extended-support limbo — the migration tooling and documentation are still catching up to the actual API changes