Crossplane
A Kubernetes-based control plane framework that lets platform teams define their own APIs and have controllers continuously reconcile cloud and in-cluster resources toward a declared state.
- Category: App Definition & GitOps
- CNCF maturity: Graduated
- Language: Go (
go 1.25.10, modulegithub.com/crossplane/crossplane/v2) - License: Apache-2.0
- Repository: crossplane/crossplane
- Documented at commit:
56aace77(2026-06-19,main, afterv2.3.2)
What it is
Crossplane runs on top of a Kubernetes API server and turns it into a control plane for infrastructure and applications. It does not keep its own state file. Desired and observed state both live as custom resources in etcd, and controllers reconcile them continuously. This differs from the single apply model of Terraform or Pulumi, where a CLI run computes a diff against a stored state file (see the Pulumi comparison).
The core abstraction is composition. A platform team defines a CompositeResourceDefinition (XRD) to create a new resource type, then writes a Composition that maps each instance of that type to a pipeline of functions. The functions produce the actual managed and Kubernetes resources. The result is a self-service API that application teams consume without touching the underlying cloud providers.
Crossplane v2 (August 2025) removed the older patch-and-transform mechanism and made composition entirely function-based. Each function is a separate gRPC service, so compositions can be written in YAML, KCL, Python, Go, or other languages. v2 also lets a composition include any Kubernetes resource, not only Crossplane managed resources.
When to use it
- You want a platform engineering layer where application teams provision infrastructure through APIs you design, with role-based access and validation enforced by Kubernetes.
- You need continuous drift correction. Because reconciliation never stops, out-of-band changes to managed resources get reverted toward the declared state.
- You already run Kubernetes and want resource state in etcd rather than in separate state files with locks.
- You want to compose cloud resources and in-cluster workloads (for example a database operator's
Clusterplus aDeployment) behind one API.
It is a weaker fit when you do not run Kubernetes, or when your team lacks Kubernetes operational knowledge and only needs occasional one-shot provisioning. In those cases a CLI tool such as Terraform or Pulumi has a lower entry cost (see platformengineering.org).
In this deep-dive
- History: origin, milestones, and why it exists.
- Architecture: components and how requests flow.
- Adoption & Ecosystem: who runs it and what surrounds it.
- Internals: the code paths that matter, read from source.
- Getting Started: install and a first working setup.
Sources
- crossplane/crossplane repository
- Announcing Crossplane's CNCF Graduation
- CNCF announces graduation of Crossplane
- Crossplane on CNCF projects
- Crossplane is now a CNCF Incubating project
- cncf/toc#1397 Crossplane Graduation Application
- What's New in v2
- What's Crossplane?
- Functions
- Compositions
- Get started
- Pulumi vs. Crossplane
- Terraform vs Pulumi vs Crossplane
- Introducing function-kro: YAML+CEL Composition
- crossplane/crossplane ADOPTERS.md
- GitHub API repos/crossplane/crossplane