Top 6 Crossplane Alternatives in 2026

Crossplane's model is genuinely powerful: define your cloud resources as Kubernetes custom resources, compose them into higher-level abstractions, and let reconciliation keep reality matched to intent. But power is not the reason teams search for alternatives — the search starts when the Composition YAML passes a thousand lines, when a stuck reconciliation takes a day to debug, or when someone notices that the thing developers keep asking for isn't a new abstraction, it's an answer.

This guide covers six alternatives across the three jobs Crossplane gets hired for. (Disclosure: we build Kestrel, one of the tools covered. We've kept the comparisons factual and noted where Crossplane remains the better fit.)

Why teams look for Crossplane alternatives

Three patterns dominate. First, complexity cost: Compositions, XRDs, providers, and the controller machinery are a steep curve, and debugging a reconciliation loop that won't converge is specialist work. Second, the day-2 gap: reconcilers express desired state, but most of a platform team's work is imperative and event-driven — investigate this alert, approve and run this migration, scale this service for the launch and scale it back after. None of that is desired state. Third, the self-service mismatch: what developers experience as self-service is a request path with approvals, verification, and a reply — a workflow — and building that on top of Crossplane means building it yourself.

The 6 alternatives at a glance

1. Kestrel — the operational layer reconciliation can't express

Kestrel replaces the job most teams were really hiring Crossplane for: governed developer self-service. Instead of composing XRDs into an abstraction and building a request path around it, you describe the path itself in plain English — "when a developer requests a new environment, provision the namespace and database through our integrations, gate it on platform-team approval, verify, and reply in Slack" — and the Workflow Agent compiles it into a deterministic workflow.

Getting started is just as direct: existing runbooks and scripts convert the same way through the Workflow Assistant — upload what your team already has and it becomes governed, executable workflows — so day-2 procedures stop living in wikis. There's no provider machinery to install or Compositions to author before the first automation runs.

The execution model is the philosophical opposite of a reconciler — and that's the point. A Crossplane Composition continuously enforces state; a Kestrel workflow runs as an explicit DAG with a beginning, an end, approval gates at judgment points, and a step-by-step record of what happened. For imperative operations — investigations, restarts, scale events, migration gating, incident response — that explicitness is exactly what you want to review, audit, and replay.

Kestrel doesn't reconcile drift — for continuous desired-state enforcement, keep IaC or a control plane underneath. It integrates with them instead: Terraform, Kubernetes, AWS, Argo CD, and 30+ more — a plan-approve-apply Terraform change requested from Slack is a canonical Kestrel workflow. Best for: teams whose Crossplane ambition was self-service and day-2 automation, not drift correction.

You can also use Kestrel from the CLI, MCP server, and SDK. Control planes are consumed by controllers; Kestrel is built to be consumed by engineers and AI agents. The CLI generates and manages workflows from the terminal, the Python SDK defines them as typed code, and the MCP server gives assistants like Claude and Cursor a governed interface to build, run, and inspect workflows. Ask an agent for "a workflow that runs terraform plan on infra PRs, posts the diff for approval, and applies on sign-off" and it can assemble the whole loop through MCP — with the result still fenced, gated, and auditable. That agent-operable surface is a growing part of how platforms get built; see automation for AI agents.

2. Terraform / OpenTofu — the provisioning default

If Crossplane was your provisioning engine, the boring answer is often the right one: Terraform (or its open-source fork OpenTofu) remains the ecosystem default, with the largest provider catalog and talent pool. You give up continuous reconciliation for an explicit plan/apply cycle — which many teams find easier to reason about and gate. The state file and module hygiene are the recurring taxes. Best for: teams that want provisioning breadth and maturity over control-plane semantics.

3. Pulumi — infrastructure as actual code

Pulumi expresses infrastructure in TypeScript, Python, Go, and other real languages — loops, types, tests, and abstractions without a DSL or YAML composition layer. For teams that found Crossplane's Compositions to be programming-in-YAML, Pulumi is the honest version of the same instinct. Its Automation API also embeds provisioning into applications cleanly. Best for: software-engineering-heavy teams building infrastructure abstractions in languages they already know.

4. Kratix — platform-as-a-product framework

Kratix competes with Crossplane on the abstraction-building axis: its Promises are platform APIs that encapsulate everything a capability needs — pipelines, dependencies, scheduling across clusters — rather than composing cloud resources alone. It's opinionated toward treating the platform as a product with versioned contracts. Like Crossplane, it's a framework you build on, not a product you configure. Best for: platform teams designing multi-cluster platform APIs who want stronger product semantics than Compositions.

5. Humanitec — the commercial orchestrator

Humanitec's Platform Orchestrator generates app and infrastructure configuration dynamically per deployment, using Score as the workload spec. It overlaps Crossplane on standardized abstractions but comes as a commercial product with the platform-building opinions included. The trade-off is adopting its model deeply — worthwhile at org scale, heavy for a single team. We compare it in depth in the 5 best platform engineering tools. Best for: enterprises standardizing deployment config across many teams.

6. KRO — composition without the machinery

KRO (Kube Resource Orchestrator) is the newest entrant: define a ResourceGraphDefinition and get a simple custom resource that composes existing Kubernetes resources — including cloud resources via ACK, ASO, or Config Connector — without Crossplane's provider and Composition machinery. It's younger and narrower, but if your Crossplane usage boiled down to "bundle these five resources behind one CR," KRO does that with far less to operate. Best for: Kubernetes-native composition with a minimal footprint.

How to choose

• You wanted governed self-service and day-2 operations — Kestrel, layered over the IaC you already have.
• You need provisioning breadth and maturity — Terraform/OpenTofu; Pulumi if your team prefers real languages.
• You're building platform APIs as products — Kratix on Kubernetes, or Humanitec if you want the opinions delivered commercially.
• You just need resource composition — KRO, with dramatically less machinery.
• You genuinely need continuous reconciliation of cloud resources at scale — keep Crossplane. That core remains excellent; pair it with a workflow layer for everything imperative.

Desired state vs. workflows: a worked example

The clearest way to see the boundary is one scenario handled both ways. A team needs a Postgres instance for a new service. The Crossplane version: define (or reuse) a Composition that abstracts RDS, expose a claim API, have the team commit a claim manifest, and let the control plane provision and reconcile it forever. Elegant — if you've already built the Composition, taught teams the claim format, and staffed the reconciliation debugging.

The Kestrel version: "When a developer requests a Postgres database, collect size and environment, require platform approval for production, create the instance through the AWS integration with our standard parameter group and backup policy, verify it's reachable, and post the connection details to the requester's channel." Same outcome, but the request path — the approval, the verification, the notification — is the artifact, not a wrapper you build around a control plane. And when the day-2 event arrives (the instance needs resizing before a launch, or an alert fires on connection saturation), the same workflow model handles it, because resize-approve-verify is a sequence of steps, not a desired state. Neither model subsumes the other; the mistake is forcing workflow-shaped operations through a reconciler, or rebuilding drift correction in workflows.

Where each alternative breaks first

Since every tool demos well, it's worth knowing the first wall each one hits. Terraform/OpenTofu's wall is the workflow around it: plan/apply is explicit, but the request-approve-apply-verify loop across teams is tooling you assemble from CI, bots, and discipline. Pulumi's wall is organizational — infrastructure-as-real-code is only an advantage for teams that review and test infrastructure like software. Kratix's wall is design effort: Promises are as good as the platform team's API design, and versioning platform APIs is a product-management job someone must own. Humanitec's wall is the standardization prerequisite. KRO's wall is maturity — it's young, and composition of composition (nested abstractions) gets thin quickly. Kestrel's wall is the inverse of Crossplane's: it won't continuously reconcile state, so drift correction belongs to your IaC layer underneath. Knowing which wall you'll hit first — and whether it's a wall or a fence you can live behind — is a better selection method than any feature matrix.

Coexistence: the two-layer pattern that actually works

Most teams reading this won't replace Crossplane outright — they'll right-size it. The stable end state we see is two layers with a clean seam: a declarative layer (Crossplane, Terraform, or KRO) owns resource lifecycles and drift, while a workflow layer owns everything with a beginning and an end — requests, approvals, incident loops, migrations, scale events. The seam is simple to enforce: if the sentence describing the need contains "keep," "always," or "match," it's declarative-layer work; if it contains "when," "then," or "approve," it's workflow work. Kestrel sits naturally on top of either: a workflow can commit a claim manifest or run a Terraform plan-approve-apply cycle, so the declarative layer stays the source of truth for state while humans and agents interact through governed request paths. Teams that draw this seam stop having the "everything must be a Composition" argument entirely — and both layers get simpler.

Frequently asked questions

What is the best alternative to Crossplane?

For provisioning: Terraform/OpenTofu or Pulumi, with KRO for Kubernetes-native composition. For platform abstractions: Kratix or Humanitec. For the governed self-service and day-2 operations most teams were ultimately after: Kestrel.

Why do teams move away from Crossplane?

Composition/XRD complexity, the operational burden of providers and reconciliation debugging, and the realization that developer self-service is workflow-shaped — requests, approvals, verification, replies — which a reconciler doesn't express.

Is Kestrel a replacement for Crossplane?

For desired-state reconciliation, no. For the request paths and imperative operations around provisioning — yes, and it's purpose-built for them: plain-English building, approval gates, resource fencing, and step-level audit trails over your existing IaC and cloud integrations.

Do you need a control plane for platform engineering?

Only once many teams consume standardized, continuously reconciled abstractions. Most platforms' immediate needs — governed requests, approvals, audit, incident automation — arrive faster with a workflow layer over existing IaC. Adopt the control plane when drift demands it.

The bottom line

Crossplane answers "keep this true" — and if that's your problem, it's still a fine answer. But most teams searching for alternatives discovered their problem was "when this happens, do this, with sign-off" — and that's a workflow, not a reconciliation. Put Terraform, Pulumi, or KRO under it as needed; put Kestrel on top for the workflows that actually consume your team's week. Start with the workflows quickstart or browse the docs.