Crossplane is an open source project that extends Kubernetes so it can provision and manage cloud infrastructure, not just containers, using the same declarative API and control loop model Kubernetes already uses for pods and deployments. It runs as an add-on inside a Kubernetes cluster, and once installed, it lets a team describe a database, a virtual network, or a storage bucket as a Kubernetes object and have Crossplane create and reconcile that real cloud resource. It's maintained under the Cloud Native Computing Foundation, and it's the tool most commonly reached for by platform teams building what's called a control plane for infrastructure. The project started at Upbound, and its governance now sits with the CNCF alongside other well-known cloud native projects, which has helped it attract a broad ecosystem of independently maintained provider packages.
The reason Crossplane exists is that infrastructure-as-code tools built around one-time provisioning runs, apply a plan, wait for it to finish, move on, don't hold state the way applications need it held. Cloud resources drift: someone changes a setting in a console, a policy update alters a permission, a resource gets deleted outside the normal workflow. Tools that only run when triggered can't catch that drift between runs. Kubernetes controllers, by contrast, run continuously, constantly comparing desired state to actual state and correcting the difference, and Crossplane brings that same continuous reconciliation to cloud infrastructure instead of leaving it to periodic runs. This gap matters more than it sounds: in a large organization with hundreds of engineers touching cloud consoles for debugging or one-off fixes, drift isn't a rare edge case, it's a constant background condition that accumulates unless something is actively watching for it.
What distinguishes Crossplane from a typical infrastructure-as-code tool is that it doesn't just provision resources, it lets platform teams define entirely new custom APIs on top of raw cloud primitives. Using a feature called Compositions, a platform team can expose a simple API, say, "give me a production-ready Postgres database," that internally provisions and wires together five or six cloud resources across networking, security, and storage. Developers interact with the simple API; the complexity of the underlying cloud resources stays hidden behind it. That's a fundamentally different model from writing and re-running the same infrastructure-as-code modules by hand, since the abstraction itself becomes a durable, reusable API rather than a script someone has to remember to invoke correctly each time.
By 2026, Crossplane has become one of the more established building blocks in the platform engineering toolkit, particularly for organizations building internal developer platforms that want self-service infrastructure without giving every engineer direct cloud console access. It's frequently paired with a developer portal like Backstage, where the portal provides the request form and Crossplane does the actual provisioning behind the scenes. Its adoption has grown alongside the broader shift toward treating infrastructure as something managed by the same control loop machinery as application workloads, rather than as a separate discipline with separate tooling. A growing number of managed platform products now bundle Crossplane under the hood as their provisioning engine, which means some teams are using it indirectly today without necessarily knowing the name of the tool doing the work.
This page covers how Crossplane's control loop and Composition model work, why organizations choose it over more traditional provisioning tools, where it fits and where it's overkill, and how teams tend to roll it out successfully. The durable idea underneath Crossplane is that infrastructure, like an application, should have a system continuously making sure reality matches intent, and understanding that shift lets a team decide whether their infrastructure problems are really about applying changes correctly, or about correcting drift and abstracting complexity, which is a different and harder problem entirely.
Kubernetes works by continuously comparing the state you've declared to the state that actually exists, and correcting any difference through what's called a reconciliation loop. If a pod dies, Kubernetes notices the actual state no longer matches the desired state and creates a replacement without anyone intervening. Crossplane takes that exact mechanism and applies it to cloud infrastructure: a declared database resource isn't just created once, it's watched continuously, and if its configuration drifts from what was declared, Crossplane reconciles it back. That loop runs on a regular interval regardless of whether anyone has touched the resource recently, so correction happens on Crossplane's own schedule rather than waiting for a person to notice something looks wrong and trigger a fix manually.
This is a meaningfully different operating model from run-based provisioning tools, where infrastructure state gets checked and corrected only when someone explicitly triggers a run. In practice, that gap between runs is where drift accumulates unnoticed: a security group rule changed manually during an incident, a storage setting flipped by an automated compliance scan, a resource resized outside the normal workflow. Continuous reconciliation catches these changes as they happen rather than at the next scheduled apply, which shrinks the window where infrastructure quietly diverges from what's documented. That shrinking window has a direct business consequence: the longer a security misconfiguration sits uncorrected, the more time it has to be exploited, so continuous reconciliation is as much a security control as it is an operational convenience.
Because Crossplane runs inside Kubernetes, it inherits Kubernetes' operational tooling almost for free: role-based access control governs who can create which infrastructure objects, standard Kubernetes events and logs show what Crossplane is doing, and the same monitoring stack watching application pods can watch infrastructure resources too. Teams that already run Kubernetes clusters get infrastructure management folded into tooling they already operate, instead of standing up a separate system with its own access model and its own observability story. This also means engineers who already know how to query Kubernetes objects with familiar command-line tools can inspect infrastructure resource status the same way they'd check on a pod, without learning a completely separate toolset just to see whether a database is healthy.
The tradeoff is that this model requires running and maintaining a Kubernetes cluster specifically to host the control plane, along with the Crossplane controllers and whatever provider plugins are needed for each cloud. That's not a trivial operational cost. Teams take on responsibility for the availability and security of the control plane cluster itself, since if it goes down, the reconciliation loop that keeps infrastructure correct stops running along with it. In practice this means the control plane cluster becomes a piece of tier-one infrastructure in its own right, deserving the same backup, monitoring, and access discipline a team would apply to any system whose outage would block every team depending on it from provisioning or modifying anything.
Crossplane itself doesn't know how to talk to AWS, Azure, or Google Cloud directly; that capability comes from providers, which are separate, installable packages that translate Crossplane's generic resource model into calls against a specific cloud's API. There's a provider for AWS, one for Azure, one for Google Cloud, and providers for other systems entirely, from Kubernetes clusters themselves to SaaS platforms, which means Crossplane can manage more than just infrastructure in the traditional sense. Community and vendor-maintained providers also exist for things like DNS management platforms and observability tools, so a team can, in principle, extend the same declarative model to almost any system that exposes an API worth automating against.
This provider model is what lets a single Crossplane installation manage resources across multiple clouds through one consistent interface. A team running workloads on both AWS and Google Cloud can describe a database on each through the same declarative pattern, even though the underlying API calls Crossplane makes look completely different behind the scenes. That consistency matters most for platform teams trying to give developers one predictable way to request infrastructure, regardless of which cloud a given workload actually lands on, and it becomes especially valuable during a cloud migration, since the developer-facing request pattern can stay identical even while the underlying provider swaps out entirely.
Providers are versioned and installed independently of the Crossplane core, which means a cloud provider can ship support for a new resource type or fix a bug without requiring an upgrade to Crossplane itself. It also means the maturity and completeness of a given provider varies. Some providers cover a cloud's services thoroughly and are actively maintained; others lag behind or cover a narrower surface area, and a team evaluating Crossplane needs to check that the specific resources they care about are actually well supported before committing. This is worth checking concretely rather than assuming: browsing the provider's own resource catalog and open issue list before adoption tells you far more about real coverage than the provider's marketing description does.
Provider credentials also become a real security consideration, since a provider typically holds cloud credentials with enough permission to create and delete real infrastructure. Teams need to think carefully about the blast radius of a compromised or misconfigured provider, the same way they would think about the blast radius of a CI/CD pipeline that holds broad cloud credentials, because the consequences of a mistake are identical: real infrastructure gets created, modified, or destroyed.
Compositions are the feature that separates Crossplane from a simple cloud resource provisioner and turns it into a tool for building an actual internal platform. A Composition lets a platform team define a custom API, for example a `Database` object with a handful of simple fields like size and region, and map that single request internally to a full set of underlying cloud resources: the database instance itself, the network configuration, the backup policy, the security group rules, all created and wired together consistently every time. That consistency is the real payoff: the same Composition applied a hundred times produces a hundred databases that are all configured to the same standard, instead of a hundred slightly different snowflakes shaped by whoever happened to set each one up.
This matters because it inverts who needs to understand the complexity. Without Compositions, every team requesting a production database needs to understand networking, security group rules, backup retention policy, and encryption settings correctly, and get all of it right every time. With a Composition in place, a developer requests a `Database` with two or three fields, and the platform team's expertise about how a compliant, production-ready database should be configured gets applied automatically and identically every time, regardless of who's asking. That shift has a direct business consequence: fewer misconfigured databases in production means fewer security incidents traced back to a forgotten encryption setting or an overly permissive network rule that a rushed engineer never meant to leave open.
Compositions are written using either simple templating or a full-fledged rendering approach, giving platform teams a real programming surface for expressing conditional logic, like provisioning a smaller instance size for a staging environment and a larger, multi-zone instance for production automatically based on a single input field. That flexibility is powerful, but it also means Compositions are genuine software artifacts that need testing, versioning, and code review, not simple configuration files a person writes once and forgets. Teams that treat a Composition like a static config file rather than like application code tend to be the ones surprised when a small, seemingly harmless edit changes behavior for every existing resource built from it.
This is really the heart of why organizations describe Crossplane as a way to build an internal cloud rather than just a provisioning tool. The custom APIs defined through Compositions become the actual interface between the platform team and everyone else, and they can evolve independently of the cloud APIs underneath them. A platform team can change which cloud a Composition provisions against, or restructure the underlying resources entirely, without developers who consume the simplified API ever needing to notice or update anything on their end. That independence is what gives a platform team real room to improve or migrate the underlying infrastructure over time without forcing every downstream team through a disruptive, coordinated change.
Crossplane fits well for organizations building an internal developer platform that wants developers requesting infrastructure through simple, standardized APIs rather than writing infrastructure code themselves or filing tickets to a central ops team. It's a particularly strong fit for teams that are already running Kubernetes at meaningful scale, since they already have the operational muscle to run and secure a Kubernetes cluster, and adding Crossplane to that cluster is a smaller incremental step than it would be for a team with no Kubernetes experience at all. Organizations under real pressure to cut the time between an infrastructure request and a working resource, often measured in days with a ticket-based process, get some of the clearest wins from this fit, since a well-built Composition can turn that wait into minutes.
It's a weaker fit for smaller teams or ones with a modest, fairly static set of infrastructure needs. A five-person startup with two databases and one load balancer gains very little from continuous reconciliation and custom Composition APIs; a straightforward infrastructure-as-code tool applied by hand or through a simple pipeline handles that scale with far less operational overhead. Crossplane's value curve is steep: it pays off when the number of infrastructure requests and the number of requesting teams both grow large enough that a self-service API becomes worth building. Below that threshold, the cost of standing up and securing a dedicated control plane cluster tends to outweigh whatever time it saves compared to a small team just running a handful of infrastructure-as-code modules directly.
It's also important to be clear that Crossplane is not a replacement for a service mesh, a CI/CD system, or an application deployment tool; it manages infrastructure resources, not application rollouts, though it's often used alongside GitOps tools that apply Crossplane resource definitions the same way they apply application manifests. Teams sometimes conflate "we use Kubernetes for infrastructure" with "we no longer need our existing deployment pipeline," which is a mistake; the two solve different problems and typically run side by side.
Crossplane also isn't a good fit as the very first thing a platform team builds. Organizations that succeed with it usually already have some experience with infrastructure-as-code, some existing standards for how infrastructure should be configured, and a real backlog of repeated, painful infrastructure requests before they invest in building Compositions around those patterns. Adopting Crossplane before understanding what your organization's actual repeated infrastructure requests look like tends to produce Compositions nobody uses because they don't match how developers actually ask for things. A useful discipline here is to mine the last quarter's actual infrastructure tickets for the patterns that show up over and over, and build the first Composition around whichever pattern appears most often, rather than guessing at what developers will want.
The rollouts that work start by identifying one or two infrastructure requests that come up constantly and cause real pain, a standard database setup or a standard networking pattern, and building a single, well-tested Composition around exactly that pattern before trying to cover everything. A narrow, reliable Composition that developers actually trust beats a broad, half-finished library of Compositions that developers route around because they don't fully trust the output. Trust, once lost because an early Composition misbehaved, is expensive to rebuild, so it's worth erring toward a smaller, more conservative first release than a broad one that risks an early failure.
Version control and testing discipline matter enormously here, because a Composition bug doesn't just break a build, it can misconfigure real cloud infrastructure across every team that uses it. Teams that treat Compositions with the same rigor as application code, code review, automated testing against a sandbox cloud account, staged rollout, tend to avoid the failure mode where a Composition change silently reconfigures production infrastructure for every consumer at once. Rolling out a Composition change to a small subset of non-critical resources first, then expanding once it's proven stable, catches problems while the blast radius is still small.
Access control needs deliberate design from the start, since Crossplane resources typically live inside the same Kubernetes cluster as the control plane itself, and getting role-based access control wrong can mean a developer requesting a simple database accidentally gets visibility into or control over the underlying provider credentials and raw cloud resources. Separating the developer-facing custom resources from the underlying provider-managed resources, and locking down access to the latter, is a standard and important pattern, often achieved by putting the two categories of resource in different namespaces with different role bindings so the separation is enforced structurally rather than relying on convention alone.
Finally, teams that succeed with Crossplane invest early in observability specifically for the control plane, since a stuck or failing reconciliation loop can leave infrastructure in a partially applied state that's confusing to debug without the right visibility. Dashboards and alerts that surface reconciliation errors, not just whether the Crossplane pods themselves are healthy, give a platform team the early warning it needs before a provisioning failure turns into a developer-facing outage. Setting up alerting on the age of unresolved reconciliation errors specifically, rather than just their existence, also helps a team distinguish a transient blip from a genuine stuck resource that needs a human to intervene.
Crossplane is an open source Kubernetes add-on that extends the Kubernetes API to provision and continuously manage cloud infrastructure, letting platform teams build custom, simplified APIs on top of raw cloud resources.
Not exactly. Terraform applies infrastructure changes when triggered and stops; Crossplane runs inside Kubernetes and continuously reconciles infrastructure against its declared state, correcting drift as it happens rather than at the next run. Some organizations run both, using Terraform for certain foundational infrastructure and Crossplane for the self-service layer developers interact with directly.
Yes, functionally. Crossplane runs as an add-on inside a Kubernetes cluster and relies on Kubernetes' own machinery for its control loop, so teams need at least a control plane cluster to host it, even if that cluster isn't running application workloads itself. Some teams stand up a small, dedicated cluster purely to run Crossplane, separate from any cluster running actual application traffic.
A provider is an installable package that translates Crossplane's generic resource model into real API calls against a specific cloud or system, such as AWS, Azure, Google Cloud, or Kubernetes itself, and each is versioned and maintained independently, so its coverage and quality should be checked before relying on it for anything critical.
A Composition is a definition that maps a simple, custom API, like a request for a database, to a full set of underlying cloud resources that get created and configured together, hiding the underlying complexity from whoever makes the request and enforcing a consistent standard across every resource built from it.
Usually not necessary. Crossplane's value grows with the volume and variety of infrastructure requests across an organization; a small team with a handful of stable resources typically gets more value from simpler infrastructure-as-code tooling and can revisit the decision once request volume and team count actually justify the extra operational overhead.
They're commonly paired: Backstage provides the developer-facing portal and request form, while Crossplane does the actual provisioning and ongoing reconciliation of the infrastructure behind that request, with the two systems connected through the catalog and templates.
Yes. Because cloud-specific logic lives in separate provider packages, a single Crossplane installation can manage resources across AWS, Azure, Google Cloud, and other systems through one consistent declarative interface, which is one of the main reasons multi-cloud organizations adopt it in the first place.
The two biggest risks are treating Compositions as simple configuration rather than tested software, which can misconfigure infrastructure at scale when a bug slips through, and underestimating the operational responsibility of running and securing the Kubernetes cluster that hosts the control plane itself. Both risks are manageable with the same discipline teams already apply to production application code, but only if that discipline is deliberately carried over rather than assumed to apply automatically.
