Crossplane

Turns a Kubernetes cluster into a control plane for infrastructure: you declare a bucket or a database as a Kubernetes object, and controllers create it and keep putting it back if it drifts.

CNCF · Graduated

What it is: Infrastructure as code
Type: Open source
Made by: Cloud Native Computing Foundation
Foundation: Cloud Native Computing Foundation, graduated, joined June 2020. Part of the Linux Foundation
License: Apache 2.0
Facts checked: 13 October 2026

What it is

Crossplane runs as controllers in a Kubernetes cluster. A provider, installed as a package, adds managed resources: ready-made custom resources such as an S3 Bucket or an RDS Instance. Each has a controller that calls the cloud’s API to make the real resource match the object’s spec, using credentials named in a ProviderConfig. It doesn’t stop after creating it: the controller polls the resource, and if someone changes it in the console, the next reconcile corrects the drift. The poll interval can be set per resource with an annotation.

Composition is how a platform team publishes its own APIs. A CompositeResourceDefinition declares a new kind, such as App or Database, and a Composition runs a pipeline of functions, written in YAML, KCL, Python or Go, that returns the resources to create for it. Crossplane 2.0 (August 2025) made composite and managed resources namespaced by default, let a composition include any Kubernetes resource such as a Deployment next to an RDS instance, dropped the separate claim objects, and added Operations for one-off, scheduled or event-driven jobs. Crossplane is a CNCF graduated project.

Why teams pick it

Continuous reconciliation: drift is corrected on the next poll rather than the next time someone runs an apply, and stable resources can be polled less often
Platform teams offer their own APIs (an App, a Database) without writing a controller, and users reach them with kubectl, Kubernetes RBAC and namespaces
Fits the Kubernetes toolchain: Argo CD or Flux sync it from git, and it works with Helm, Kyverno, Open Policy Agent, Prometheus and Backstage
Vendor-neutral under the CNCF and Apache 2.0, including the AWS, Azure and GCP providers Upbound donated in 2023

Watch out for

Needs a Kubernetes cluster (the getting-started guide asks for at least 2 GB of RAM), and that cluster becomes critical infrastructure
Big providers add many CRDs: provider-aws-ec2 alone installs about 200, at roughly 3 MiB of API server memory each, unless you activate only the ones you use
Operations, managed resource definitions and activation policies are still alpha features in v2
Hard to learn: in 2023 the project itself called the path to a production-ready control plane difficult, and debugging means following objects and events across Crossplane, provider and function pods

The Crossplane family

1 technologies built from or on Crossplane

Built on it

UpjetOpen sourceA code generator and runtime that turns a Terraform provider into a Crossplane provider, so Terraform’s resource code sits behind Kubernetes-style managed resources.

Alternatives

What all infrastructure as code have in common →Compare side by side →

AWS Cloud Development Kit (CDK)AWSDefine AWS infrastructure in TypeScript, Python, Java, C# or Go; the CDK turns it into CloudFormation templates and CloudFormation deploys them.

AWS CloudFormationAWSAWS’s own infrastructure-as-code service: describe resources in a JSON or YAML template and CloudFormation creates them as one stack, in order, and rolls back on failure.+1 AWS Serverless Application Model (SAM)

EncoreOpen sourceA backend framework for TypeScript and Go in which services declare the databases, topics, buckets and cron jobs they need as typed objects in code; Encore reads those declarations and runs them locally or provisions them in your AWS or GCP account.

GrizzlyArchivedOpen sourceGrafana Labs’ deprecated grr command line tool for keeping Grafana dashboards, alert rules and data sources as YAML, JSON or Jsonnet files and pushing them to Grafana.

HashiCorp PackerCommercialBuilds machine images (AMIs, Azure and Google images, VMware, Docker) from one HCL template, so every server starts already configured.HCP WaypointCommercialHashiCorp’s hosted internal developer platform: developers create apps and add databases from templates that run Terraform modules in HCP Terraform.

NitricOpen sourceA multi-language framework in which code asks for APIs, buckets, queues, topics and databases through an SDK; at deploy time Nitric collects those requests and a provider plugin turns them into AWS, Google Cloud or Azure resources, through Pulumi or generated Terraform.

OpenTofuOpen sourceThe open-source fork of Terraform, created after HashiCorp’s 2023 licence change: same HCL, same providers, tofu instead of terraform.

PulumiOpen sourceInfrastructure as code in TypeScript, Python, Go, C#, Java, YAML or HCL: a program declares resources, and Pulumi’s engine diffs them against saved state and calls the cloud APIs through providers.

Serverless FrameworkCommercialA CLI that turns one serverless.yml file of functions and the events that trigger them into a CloudFormation stack, and deploys it with your code to AWS Lambda.

SpaceliftCommercialA hosted or self-hosted platform that runs Terraform, OpenTofu, Pulumi, CloudFormation, Kubernetes and Ansible changes from Git, with plans on pull requests, approvals and guardrails written as OPA policies, and workers you can run in your own network.

SSTOpen sourceA TypeScript framework that defines a whole app, from Next.js front end to functions, containers and databases, in one config file and deploys it to your own AWS or Cloudflare account.

TerraformCommercialThe most widely used infrastructure-as-code tool: declare resources in HCL, review a plan, and apply it through provider plugins.

WingPreviewOpen sourceA programming language for the cloud that puts infrastructure and the code that runs on it in one program: the compiler turns it into Terraform for AWS, Azure or Google Cloud plus JavaScript for the functions, and can also run it all in a local simulator.

How it fits with other technologies

What Crossplane uses

What uses Crossplane

Upjetbuilds the AWS, Azure and GCP providers ofCrossplaneInfrastructure as code

Install the AWS S3 provider, then declare a bucket as a namespaced managed resource · yaml

apiVersion: pkg.crossplane.io/v1
kind: Provider
metadata:
  name: crossplane-contrib-provider-aws-s3
spec:
  package: xpkg.crossplane.io/crossplane-contrib/provider-aws-s3:v2.0.0
---
apiVersion: s3.aws.m.upbound.io/v1beta1
kind: Bucket
metadata:
  namespace: default
  generateName: crossplane-bucket-
spec:
  forProvider:
    region: us-east-2

See it in a real stack

No architecture uses Crossplane yet. Drop it into the playground and wire it up yourself.Open playground →

Where it came from2018–2025

By 2018 Kubernetes had become the standard way to run containers portably, but most workloads also leaned on managed databases, queues and buckets, each behind its cloud’s proprietary API. Running those services on Kubernetes yourself with operators brought the operating burden back. Upbound’s founders argued for “a new portability layer on top of existing managed services”: a control plane with one declarative API across providers.

Bassam Tabbara, Illya Chekrygin and Jared Watts introduced Crossplane on December 4, 2018 as an “open source multicloud control plane”. It reused the unmodified Kubernetes API server and etcd, and the first design had resource claims and classes, so developers asked for a database and administrators decided how it was provisioned, plus a scheduler meant to place workloads across clouds. It joined the CNCF as a sandbox project in 2020 and moved to incubating in 2021.

Over time the focus moved from multicloud portability to platform engineering. In September 2023 Upbound donated its Upjet framework and its AWS, Azure and GCP providers to the project, which widened its charter to providers and developer tooling. Crossplane 2.0 (August 12, 2025) dropped claims and cluster-scoped defaults, saying v1 “had become overly opinionated”, and on November 6, 2025 the CNCF announced its graduation, counting more than 3,000 contributors from over 450 organizations and over 100 releases.

Why it’s built this way

Build on the Kubernetes API server instead of a new one: The team expected the model to feel familiar to the cloud native community and to reuse its tools, UIs and language bindings, so it could focus on multicloud problems “instead of reinventing machinery”.
Reconcile continuously instead of plan and apply: A control plane configures software and then watches it for its whole life, so drift from the desired state is corrected automatically without involving an admin.
Composition as a pipeline of functions: Writing a Kubernetes controller for every custom API is hard to get right; functions return declarative configuration and let teams express the logic in YAML, KCL, Python or Go.
Namespaced resources by default in v2: Claims and cluster-scoped resources had “created unnecessary friction”; namespaces match Kubernetes conventions and make multi-tenancy simpler.

Timeline

2018
Introduced by Upbound on December 4 as an open source multicloud control plane
2020
Joins the CNCF as a sandbox project
2021
Becomes a CNCF incubating project
2023
Upbound donates Upjet and its AWS, Azure and GCP providers; the charter expands
2025
Crossplane 2.0 on August 12; CNCF graduation announced on November 6

Sources11 · facts checked 13 October 2026

Improve this page on GitHub