Crossplane is a Cloud Native Computing Foundation framework for building cloud native control planes without writing code, aimed at platform and infrastructure teams that run Kubernetes and need to orchestrate applications and infrastructure across clouds through declarative APIs.

What it is

Crossplane is a framework for building cloud native control planes without needing to write code. It combines a highly extensible backend that lets a control plane orchestrate applications and infrastructure no matter where they run with a highly configurable frontend that puts the operator in control of the schema of the declarative API it offers. It is written in Go, licensed under Apache-2.0, and is a Cloud Native Computing Foundation project. Its topics place it squarely in the Kubernetes, control-plane, multicloud and infrastructure-as-code space.

The concrete problem it solves is the custom code that a control plane normally requires. Instead of writing and maintaining controllers to reconcile infrastructure, a team extends the backend and configures the frontend schema, so the declarative API surface is theirs to shape. That same framework is what lets one control plane address applications and infrastructure regardless of where they run, which is the multicloud and serverless dimension of the project's topic list. In practice it replaces bespoke control plane code and provider-specific management paths with an extensible backend plus providers, and the README directs bug reports and feature requests to Crossplane itself or the relevant provider.

Key capabilities

• Builds control planes without writing code, using an extensible backend and a configurable frontend.
• Frontend gives control over the schema of the declarative API the control plane offers.
• Backend orchestrates applications and infrastructure regardless of where they run.
• Distributed as a Helm chart, crossplane/crossplane, published on Artifact Hub.
• Documented release cycle with maintained releases from v1.20 through v2.7, each with published release and EOL dates.
• Public roadmap maintained as a GitHub project board, with issues triaged by the maintainer team and milestones given as approximate priority estimates rather than delivery commitments.
• Project health signals including an OpenSSF Best Practices badge, CI status, Go Report Card, and CNCF project status.

Who uses it and how

• Platform teams running Kubernetes that need an internal control plane rather than hand-written controllers.
• Organizations operating across multiple clouds and providers who want one declarative API for applications and infrastructure.
• Teams that must control the schema of the API they expose to their own users, since the frontend is configurable.
• Contributors and adopters who engage through Slack, the regular community meetings, the community calendar, Bluesky, Twitter, LinkedIn, YouTube, or email.
• Users tracking delivery expectations through the public roadmap, where support is shown with reactions and descriptive comments rather than tickets alone.

Getting started

Crossplane's Get Started Docs cover install and resource quickstarts. Installation is via the Helm chart crossplane/crossplane, available on Artifact Hub, with current releases listed on the releases page.

How it compares

The facts provided name no paid products that Crossplane replaces, and they name no similar tools for comparison. It therefore stands alone in this registry listing, with no alternates to contrast on licence, self-hosting, data ownership or cost model.

When to use it — and when not to

A self-hoster must operate Kubernetes and its control plane components, manage providers and their upgrades, and keep pace with the project's release cadence, since v1.20 reaches end of life when v2.5 is released in November 2026 and no longer receives support or maintenance. The README excerpt is heavy on badges, release tables and community links while offering no install commands or architecture detail, so teams should expect to lean on the Get Started Docs and community Slack for onboarding. Teams without Kubernetes operational capacity, or those unwilling to track quarterly releases and EOL windows, should not pick it.