# crossplane: turning a Kubernetes cluster into a cloud control plane

> The Cloud Native Computing Foundation project that lets platform teams manage cloud infrastructure as Kubernetes custom resources, and the release cadence that says whether you should pin it or chase it.

**crossplane/crossplane** — The Cloud Native Control Plane

- Repository: https://github.com/crossplane/crossplane
- Website: https://crossplane.io
- Stars: 12,140 · Forks: 1,275
- Language: Go
- License: Apache-2.0
- Published: 2026-10-06 · Updated: 2026-10-06 · Language: en
- Canonical page: https://hysenlabs.com/projects/crossplane-crossplane

## The premise is a control plane you do not have to write

The README's opening paragraph makes a narrow claim, and it is worth staying inside it. Crossplane is a framework for building cloud native control planes without needing to write code, with a highly extensible backend that orchestrates applications and infrastructure regardless of where they run, and a configurable frontend that puts you in control of the schema of the declarative API it offers.

Two halves come out of that sentence. The backend is the reconciliation machinery, the part that turns a desired state into an actual state on a cloud provider's API and then keeps watching for drift. The frontend is the API surface, the custom resource definitions that platform engineers write YAML against. Most of the confusion people have with Crossplane comes from mixing those two up and then expecting the Terraform behaviour from the first and the Kubernetes behaviour from the second.

The project's positioning is deliberately narrow. This is not a general provisioning engine that happens to run in a cluster, and it is not a Terraform replacement with a Kubernetes skin. It is infrastructure as code expressed in the Kubernetes resource model, where the resource lifecycle, the reconciliation loop and the API server are all things you already have if you run Kubernetes. That inheritance is the whole appeal: no separate state backend, no lock contention between two people editing the same file, and permissions that come from RBAC instead of a separate policy system.

It is a Cloud Native Computing Foundation project, which is not a marketing line so much as a governance structure. The repository carries the expected charter document set: CHARTER.md, GOVERNANCE.md, CODE_OF_CONDUCT.md, CODEOWNERS, DCO and SECURITY.md. The presence of DCO means contributions require a sign-off rather than a copyright assignment, and the presence of AI_POLICY.md suggests the maintainers have thought about generated code in a project this size.

## Release channels and the dates that decide your upgrade policy

The README publishes a support window table, and it is the most operationally useful thing in the document. It lists maintained releases alongside upcoming ones, with end-of-life dates running about eighteen months out from each release date.

```text
|  v1.20  | May 21, 2025 | Nov 2026 |
|  v2.2   | Feb 18, 2026 | Nov 2026 |
|  v2.3   | May 21, 2026 | Feb 2027 |
|  v2.4   | Aug 20, 2026 | May 2027 |
|  v2.5   |   Nov 2026   | Aug 2027 |
|  v2.6   |   Feb 2027   | Nov 2027 |
|  v2.7   |   May 2027   | Feb 2028 |
```

Two entries in that table deserve attention. First, v1.20 and v2.2 share the same end-of-life month of November 2026, and the README states plainly that when v2.5 ships in that month, v1.20 reaches end of life and stops receiving support or maintenance entirely. If you are on v1.20 today, you have a hard deadline roughly fourteen months out from the last push date of September 2026, and a second major version boundary to cross before you get there.

Second, the project ships on a quarterly rhythm rather than semver as most people read it. The gaps between the listed releases are three months each: May 2025, February 2026, May 2026, August 2026, November 2026, February 2027, May 2027. An eighteen month support window on a quarterly train means you will run some version of it indefinitely, which is a very different upgrade experience from a library where you upgrade on your own schedule.

The README also flags the roadmap's own caveat, which is unusually candid for a project document: milestones assigned to roadmap issues are intended to give a sense of overall priority and expected order of delivery, and should be considered approximate estimations and not a strict commitment to a specific delivery timeline. The roadmap is a GitHub project board, triaged by the maintainer team on an as needed basis and updatable at any time.

## Three patch releases, one fix, three dependency bumps

The release feed shows v2.4.1, v2.3.6 and v2.2.6 all published within three seconds of each other on 2026-09-15, which is the clearest signal in the repository that maintenance is disciplined rather than reactive.

Each release body opens with the same scoping sentence: a patch release scoped to fixing issues reported by users of a given minor version and fixing security related issues in Crossplane and its dependencies. Then the same substantive fix appears in all three, each backported to its own branch and each citing the original pull request number.

The fix itself is a genuine reliability bug and its description is worth reading closely, because the failure mode is the kind that eats a platform team's afternoon. An outgoing package revision could fail to relinquish control of the package's custom resource definitions, which left the incoming revision permanently unhealthy with a cannot establish control of object error. The provider's pod would never be created, so that provider could do no work, and recovery required manual intervention: either deleting the stale revision or editing the CRD's owner reference by hand. The change makes package revisions directly take control from the revision they replace, so the hand-off succeeds without intervention.

Read that as a warning about what provider upgrades mean in practice. A provider upgrade is not a rolling restart of a stateless deployment, it is a change of ownership over a cluster-scoped set of CRDs, and if the sequencing logic is wrong then the resource type stops being served entirely. That is exactly the class of bug worth backporting to three maintenance branches simultaneously.

The dependency bumps are the other half. Across the three releases the Go toolchain moves to 1.26.7, google.golang.org/grpc moves to v1.83.2, and golang.org/x/crypto moves to v0.56.0, each with a distinct pull request number per branch, to pick up upstream fixes including the gRPC advisory GHSA-2v4p-qf9q-27wj. The lock files are refreshed as well, and v2.4.1 additionally bumps crossplane-runtime.

## The dependency tree says how much Kubernetes this is wearing

The go.mod is where the architectural bet shows up as version numbers. The module path is github.com/crossplane/crossplane/v2, the Go directive is 1.26.7, and there is a single replace directive pointing the API module at a local path:

```text
module github.com/crossplane/crossplane/v2

go 1.26.7

replace github.com/crossplane/crossplane/apis/v2 => ./apis
```

The direct dependency list is the interesting part, because it is a Kubernetes control plane dependency list rather than an application list. k8s.io/api, k8s.io/apimachinery and k8s.io/client-go all sit at 0.35.3, while k8s.io/apiextensions-apiserver and k8s.io/apiserver sit at 0.35.0. sigs.k8s.io/controller-runtime is at 0.23.1, which is the standard controller framework.

Three entries there are unusual enough to be deliberate. github.com/alecthomas/kong is a command line parser, which tells you the project has real operator-style binaries rather than only a library surface. github.com/robfig/cron/v3 suggests scheduled evaluation, which is what a composition revision or a managed resource reconciler needs. github.com/sirupsen/logrus as an indirect dependency points at logging through a path that predates the structured logging defaults most Kubernetes projects have moved to.

The test dependencies are just as telling. sigs.k8s.io/e2e-framework and sigs.k8s.io/kind are direct requirements, which means the project's own tests run against a disposable Kubernetes cluster created in a container. That is a meaningful commitment for a project whose whole thesis is that it is the control plane: it is testing itself the way it expects you to deploy it.

Supply chain tooling is present too. sigstore and cosign appear as indirect requirements, and in-toto is in the tree, so image provenance verification is part of the build rather than an afterthought bolted on later.

## Providers, SIGs and the shape of the surrounding community

Crossplane's own repository is only half of the story, because the other half is the provider ecosystem. The README refers to opening an issue against Crossplane or the relevant provider, and the contributing links point at a separate release repository, which tells you the provider release cadence is not the same process as the core one. ADOPTERS.md exists for public user listings, and the README explicitly invites users to add themselves.

That provider split has consequences for anyone evaluating the project. Your dependency surface is the core control plane plus every provider you install, and those two update on different schedules. A provider that trails the core by a minor version is not necessarily broken, but it is a compatibility question you inherit and maintain, and the release bodies above show exactly why that matters: a provider revision upgrade can strand a resource type if the control plane gets the sequencing wrong.

The community structure is unusually formal for a project of this age. There are fourteen Special Interest Groups listed, and the README is careful about what they are: discussion groups that bring together members with shared interests, with no decision making authority or ownership responsibilities, serving purely as collaborative forums. The list itself is a map of where the project's friction actually lives.

`sig-v2-migration` tells you the v1 to v2 transition is still generating work. `sig-composition-functions` and `sig-composition-environments` cover the composition pipeline. `sig-observe-only` is worth attention if you want to run Crossplane in a mode that models resources without touching a cloud account. `sig-deletion-ordering` deals with the hard problem of tearing down resources that depend on each other, and `sig-upjet` covers the code generation path that most modern providers use. `sig-secret-stores` and `sig-prod-readiness` are the two you would want to read before a production rollout.

Meetings happen every four weeks on Thursday at 10:00am Pacific Time, with the schedule published on a community calendar.

## What the repository is actually made of

The file tree is worth reading for what it contains and what it does not. There is no application code directory, no frontend and no web assets beyond a banner image. What there is, is a control plane laid out the way you would expect one: an apis directory that the replace directive points at, a cluster directory, a cmd directory for binaries, internal packages, proto definitions with buf configuration for gRPC, and a test directory.

Three directories tell you something specific. The proto directory with buf.gen.yaml and buf.yaml means Crossplane exposes a real gRPC surface rather than relying only on the Kubernetes API server, which is how composition functions communicate with the control plane. The security directory implies image verification and signing as first class concerns, consistent with the sigstore dependencies. The design directory holds design documents, so the architectural arguments are recorded in the repository rather than only in chat.

Tooling around the edges is Nix based. flake.nix, flake.lock, nix.sh and a nix directory suggest the project pins its development environment, which is how a large Go project avoids the drift that makes a build work on one maintainer's laptop and fail on another. There is a .golangci.yml for linting, a .coderabbit.yaml for automated review, generate.go as a generation entry point, install.sh for a curl-based install, and RELEASE.md documenting the release process that the README points at a separate repository for.

What is absent is as informative as what is present. There is no Dockerfile in the tree, no Helm chart, and no examples directory anywhere in the repository. Installation is delegated to the documentation and to Artifact Hub rather than to the repository, and that is a reasonable division of labour for a project whose install story is a Helm release into a cluster you already operate. It also means there is no quickstart in the README itself, so if you want the shortest possible path you will need to go to the external docs.

## Conclusion

Crossplane is one of the few projects where the boring operational signals are more informative than the feature list. Twelve thousand stars and a Cloud Native Computing Foundation charter say the ecosystem will be around for the v3 era, while a 200 issue backlog, a three-way patch release drop and a v1.20 end-of-life date inside the same quarter tell you to treat the moving minor releases as a stream rather than a set of pins. Read the release table before you design your upgrade policy, because the project's own support windows decide that for you, and pick your provider family before you commit, since composition and management policies sit close to the provider surface.

## FAQ

### What is crossplane used for?

Crossplane is used to manage cloud infrastructure and applications through declarative Kubernetes APIs. A control plane runs in your cluster, providers extend it to a specific cloud, and you describe the resources you want as custom resources so that reconciliation, drift correction and access control all happen through the Kubernetes model you already operate.

### Is crossplane better than terraform?

It depends on what problem you are solving. Terraform is a general purpose provisioning tool with a large provider ecosystem and a familiar workflow. Crossplane fits situations where you already run Kubernetes, where you want infrastructure managed as custom resources with RBAC, audit and reconciliation handled by the cluster, and where resources are consumed as an API by other teams rather than applied from a workstation.

### What is a crossplane?

In the project's own framing, a crossplane is the plane you fly between clusters and clouds. In practice the name refers to the framework: a Cloud Native Computing Foundation project for building cloud native control planes without writing code, with an extensible backend for orchestration and a configurable frontend for the schema of the API it serves.

### Is crossplane a Kubernetes controller?

It is more than that. Crossplane builds on sigs.k8s.io/controller-runtime and installs custom resource definitions, so controllers are the mechanism, but the project ships a control plane that owns package revision lifecycle, provider installation and composition, which is a wider responsibility than a single controller loop.

## Sources

- [crossplane/crossplane on GitHub](https://github.com/crossplane/crossplane)
- [License: Apache-2.0](https://github.com/crossplane/crossplane/blob/main/LICENSE)
- [Project website](https://crossplane.io)
- [README](https://github.com/crossplane/crossplane/blob/main/README.md)
- [Releases](https://github.com/crossplane/crossplane/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/crossplane-crossplane