Crossplane: The Control Plane That Kept Deleting Its Own Best Ideas

September 2018: three months of private "conductor"

The crossplane/crossplane repository was created on September 8, 2018, and the first commit is disarmingly honest: "docs: first README to start project conductor", by Jared Watts. Two days later a follow-up commit "Emphasize that conductor is a codename for the project" — the name Crossplane hadn't been chosen yet. The founding team worked at Upbound, the Seattle company Bassam Tabbara had incorporated in late 2017. Tabbara's pedigree matters for the architecture: he had created Rook — the storage orchestrator that made "run Ceph from a Kubernetes CRD" mainstream — after a career spanning Symform, Quantum, and Microsoft. Upbound's thesis was that the same trick should work for cloud infrastructure itself: not a CLI with a state file, but a control plane reconciling desired state against AWS, GCP, and Azure the way kubelet reconciles pods.

The early commit log is two people wiring cloud APIs into that idea. Illya Chekrygin (ichekrygin) built the AWS provider machinery and the RDS client in late September 2018; Jared Watts (jbw976) added GCP Cloud SQL support with a stated goal that now reads as prophetic or naive depending on your scars: "GCP and Cloud SQL support for supporting Wordpress connection to database." The first demo of the project that would underpin Nike's internal platform was a WordPress deployment asking for a database through Kubernetes YAML.

The public unveiling came on December 4, 2018, the same day as the v0.1.0 release — Watts later confirmed the date in the project's first birthday post, claiming ownership of both the first commit and the first star. The launch hit Hacker News at 185 points — a warm but not thunderous reception for a project pitching "the open source multicloud control plane" at the exact moment the industry had decided multicloud was a marketing term. The v0.1.0 feature list was the whole thesis in embryo: resource claims, resource classes, managed EKS/AKS/GKE clusters, RDS and CloudSQL instances — every one of them a custom resource reconciled by controllers.

Here is what a developer actually wrote in December 2018 — real YAML from the v0.1.0 tree, a CloudSQL instance with no Terraform, no state file, no plan:

What made this different from every "Kubernetes for X" project before it was the claim mechanism layered on top: a platform team defines a class ("small postgres"), a developer claims one, and Crossplane provisions the cloud resource and hands back connection details in a Secret. Self-service infrastructure without ticket queues was the pitch — the same pitch every internal developer platform makes today, which is precisely why this 2018 curiosity is now load-bearing infrastructure. We compare the two models in depth in our Crossplane vs. Terraform guide.

1. The v0.x identity churn — shipping features that were already doomed

Read the v0.x release notes in sequence and you can watch a project argue with itself. v0.3.0 (September 2019) introduced Stacks, a packaging system for distributing cloud support. v0.12.0 (June 2020) deprecated claims — the launch feature — with removal scheduled for v0.15. v0.13.0 (October 2020) deleted Stacks in favor of a new package manager and merged the composition types into the XRD. Every mechanism the project told you to build your platform on in 2019 was gone before v1.0 in December 2020. Early adopters rode three breaking redesigns in two years, and the project's own v1.0 notes acknowledged the debt: the stability promise existed because nothing before it had been stable.

The charitable reading is that v0.x was honest iteration on a genuinely new abstraction, in public, at a time when "platform engineering" wasn't a budget line yet. The uncharitable reading is that the project treated its early adopters as a design studio. Both are true, and the surviving API design — XRDs, compositions, the package manager — is better than everything it replaced. But if you adopted Crossplane in 2019 on the claims model, you rewrote your platform three times to follow it.

2. The Great Deletion — v2.0 removes the abstractions that made Crossplane famous

Most projects treat backward compatibility as sacred. Crossplane's v2 treated it as a cost line. The v2 announcement is candid about the motivation: five years of watching platform teams work around the cluster-scoped resource model and the claims indirection produced "a more streamlined experience" — by deleting the indirection. Composite resources and managed resources went namespaced by default. Compositions gained the ability to include any Kubernetes resource — not just Crossplane-managed infrastructure — which quietly dissolves the boundary between "infrastructure control plane" and "application control plane." Claims, deprecated back in 2020, finally died. All of a composite resource's Crossplane-specific machinery moved under a single spec.crossplane block:

That resourceRefs list pointing at a plain apps/v1 Deployment is the whole v2 story: the abstraction now composes stock Kubernetes objects, which means the same control plane can own your namespace, your app, and your cloud resources. The upgrade path, however, is not streamlined — the upgrade guide mandates stepping through every minor release sequentially because each one performs CRD migrations in the API server. Skip a minor and your stored resources may be unreadable.

Then there is the launch itself. The v2.0.0 release notes open with a warning that blocking issues surfaced after extended post-release testing, directing users to install v2.0.2 from the stable channel instead. Publishing a major release whose own notes say "do not install this exact version" is unusually honest, and unusually awkward for a project six weeks from graduation review. It is also a real data point against rushing a .0 upgrade on day one.

3. Composition Functions — deleting the engine in favor of the pipeline

The quietest major deletion happened across v1.x. Composition logic began life embedded in the core: patches and transforms applied by Crossplane's own reconciler. Composition Functions arrived in v1.11 (alpha, January 2023), were rearchitected into a scalable pipeline in v1.14 (November 2023, 700+ commits — the largest release in project history), and graduated with pipeline mode as default in v1.17 (August 2024). Today you can write composition logic in Python or KCL and run it as a separate container the core calls over gRPC, instead of expressing everything in the patch-and-transform YAML dialect. The old engine still works — it was reimplemented as the function-patch-and-transform function — but the architectural center of gravity moved: Crossplane's core now only orchestrates, it no longer owns templating.

This is the same play Kubernetes ran with container runtime interfaces and CSI, and it landed for the same reason: the core team could not out-innovate the ecosystem inside one binary. The cost is an extra moving part in every control plane — a function pipeline is a set of containers you now operate — but the win is that composition stopped being a dialect you learn and became a program you write.

4. The maintenance matrix — quarterly majors and four live branches

Graduation didn't slow the cadence; it multiplied it. Crossplane ships a minor release every quarter, keeps three majors in support simultaneously, and still patches the v1.20 line. On September 15, 2026 the project published v2.4.1, v2.3.6, v2.2.6, and v1.20.13 — four branches, one day. The security posture is genuinely good (v2.4.0 added vulnerability-scannable release artifacts and ships Go toolchain fixes; v2.4.2 patched a ServiceAccount ownership bug where package revisions did not correctly hand control over), but the operational math for adopters is unforgiving: sequential mandatory upgrades through every minor, on a quarterly clock, forever.

Who actually built it

The contributor concentration is the honest headline. Nic Cope (negz) leads with roughly 2,500 commits — about a fifth of the repository's history — followed by Daniel Mangum (hasheddan, ~1,400, now emeritus) and Jared Watts (~885). The current six-person maintainer roster in OWNERS.md is five Upbound employees and Bob Haddleton of Nokia. Emeritus maintainers include the founder, Bassam Tabbara, and both early driver-authors, Chekrygin and Watts (Watts remains active). The graduation press release's "3,000+ contributors, 450+ organizations" is true and impressive — but the commit-count distribution says the core is still, structurally, an Upbound product with a community shell that has grown a real load-bearing ring around it.

The governance counterweight

The project's answer to that concentration is a two-tier model that is more interesting than most CNCF governance documents. The steering committee has five elected seats on staggered two-year terms, chosen by Condorcet ranking, with a hard cap of two members per organization. The current committee includes Bassam Tabbara and Jared Watts (Upbound), Bob Haddleton (Nokia), Brian Lindblom (Apple), and Joel Cooklin (Nike) — meaning the majority of the project's steering body now works for companies that use Crossplane rather than the company that makes it. End users holding governance seats is the structural tell that a control plane project has stopped being a vendor's roadmap and started being infrastructure. Apple and Nike do not join steering committees of things they can afford to lose.

The Terraform inheritance

Crossplane's provider story began as its weakest flank — hand-written controllers per cloud — and was quietly resolved by inheritance. Since upjet appeared in May 2022, Crossplane providers have largely been compiled from Terraform upstreams: the generated provider embeds the Terraform plugin binary and translates between the Kubernetes API and Terraform's schema machinery. The practical consequence is that Crossplane's real API coverage equals Terraform's — hundreds of providers, thousands of resources — at the cost of a translation layer and a codegen lag between an upstream release and the corresponding provider build. The community crossplane-contrib organization (76 live repositories, 42 of them providers) is where that long tail lives.

The commercial arc

Upbound's path is a textbook single-vendor OSS arc: found the project (2017-2018), raised a $9M Series A led by GV, a $60M Series B led by Altimeter in November 2021, then a managed control plane product GA'd in 2023 that runs Crossplane as a hosted multi-tenant service. In June 2026 it launched Modelplane — an open source control plane for AI inference fleets — with language that is a deliberate replay: "do for AI inference what Crossplane did for cloud infrastructure." The graduation press release itself leaned into the same trajectory, framing Crossplane's declarative model as the substrate "intelligent agents" can safely operate by "targeting outcomes instead of executing instructions." When the founding company of a graduated project starts applying the pattern to the next platform shift, that is the clearest available signal the first one worked. (For the license-angst counterfactual, see our Terraform tale and OpenTofu tale — Crossplane's Apache-2.0 never wavered, which is one crisis this project never had.)

Seven years in, Crossplane's trajectory is unambiguous: it won the argument that infrastructure belongs in the Kubernetes reconciliation loop, and the CNCF graduation — sandboxed in 2020, incubating in 2021, graduated in October 2025 — is the institutional stamp on it. The adoption list (Nike, Autodesk, NASA Science Cloud, Elastic, SAP, IBM) is the kind enterprise buyers ask for, and the steering committee's end-user majority is a governance moat most single-vendor projects never build.

Honest weaknesses, unchanged: the upgrade treadmill is real — quarterly minors, mandatory sequential migration, four live branches to track, and a v2.0.0 whose own notes told you not to install it. Composition still has the steepest learning curve in the platform-engineering toolchain; functions made it more powerful, not simpler. The upjet-generated provider layer inherits Terraform's API surface with a codegen lag, so bleeding-edge cloud features arrive late and sometimes rough. And the project's history of deleting its own best ideas is charming in retrospect and exhausting in prospect: nothing in today's API guarantees the parts you build on survive the next major, only that the project's migration guides will be thorough.

Who should skip it: teams without a platform function — if nobody owns abstractions full-time, a control plane whose core loop is designing and maintaining them becomes an abandoned API layer, which is worse than Terraform sprawl because it looks governed. Teams smaller than roughly a dozen engineers will spend more time operating Crossplane than the infrastructure it manages. And anyone mid-migration elsewhere should finish that first; v2's sequential upgrade path punishes half-migrated estates.

Who should standardize on it: platform teams building an internal developer platform on Kubernetes who want infrastructure, applications, and policy under one reconciliation model and one audit surface — especially now that v2 compositions can include any namespaced Kubernetes resource, and the graduation announcement's agent-era framing ("humans and intelligent agents request environments through APIs rather than scripts or tickets") describes a design that already exists. The pattern that started as a WordPress demo is now the load-bearing abstraction of the platform-engineering era — and, if Modelplane is any indication, about to be replayed against the GPU fleet. The one thing history guarantees is that some of what you build on it will be deleted; the reconciliation loop underneath is the part that survives.