Crossplane's pitch is good: manage cloud infrastructure the same way you manage everything else in Kubernetes, through declarative manifests and continuous reconciliation, with the API server as your control plane. If your whole platform already lives in Kubernetes and your platform team thinks in CRDs, Crossplane fits the mental model with almost no friction. The composition layer (XRDs and Compositions) lets a platform team publish opinionated, self-service abstractions that application teams consume without touching cloud APIs directly.

The friction shows up when the assumptions don't hold. Crossplane needs a running Kubernetes cluster as its control plane, even when the resources it provisions (a Postgres instance, an object store, a DNS record) have nothing to do with Kubernetes. That cluster is now production infrastructure you patch, upgrade, back up, and secure. Authoring Compositions is more involved than most teams expect, and the layers of abstraction (Claim, XR, Composition, managed resource) take real time to internalize. Teams that evaluated Crossplane and walked away usually cite one of two things: it was too Kubernetes-centric for what they needed, or the operational weight didn't pay for itself.

This guide covers the practical alternatives, grouped by the model they use, with notes on where each one fits and where it doesn't.

Crossplane Alternatives: An Overview

Terraform and OpenTofu

The most common landing spot for teams leaving Crossplane. Both use the same declarative, plan-then-apply model against a state file, and both provision the same cloud resources Crossplane does, without requiring a cluster to host a control plane.

# main.tf: the same S3 bucket Crossplane would model as a managed resource
resource "aws_s3_bucket" "assets" {
  bucket = "acme-assets-prod"
}

resource "aws_db_instance" "orders" {
  identifier        = "orders-prod"
  engine            = "postgres"
  instance_class    = "db.t3.medium"
  allocated_storage = 20
}

The trade you make going from Crossplane to Terraform is continuous reconciliation for a discrete apply model. Crossplane runs controllers that constantly drive the real world toward the declared state; Terraform reconciles only when you run apply. Drift between runs is detected at plan time, not corrected automatically. For many teams that's fine or even preferable, since an unexpected auto-correction can be its own kind of incident. If constant reconciliation was the specific reason you picked Crossplane, this is the property you'll miss.

OpenTofu is the MPL-licensed community fork of Terraform, drop-in compatible for most workflows, and worth choosing if you care about a permissive license or your CI vendor has standardized on it. See OpenTofu vs Terraform for the full breakdown.

Good fit for: teams who want the default IaC tool, the largest provider ecosystem, and no control-plane cluster to operate.

Less good fit for: teams who specifically wanted continuous reconciliation, or who want a self-service composition layer that application teams consume without learning HCL (Terraform modules help but aren't as opinionated as Crossplane Compositions).

Pulumi

Pulumi keeps the plan-and-apply IaC model but lets you write infrastructure in TypeScript, Go, Python, or C# instead of HCL. For teams who left Crossplane partly because YAML and CRD authoring felt limiting, real loops, functions, and types are a meaningful upgrade.

// index.ts
import * as aws from "@pulumi/aws";

const bucket = new aws.s3.Bucket("assets", {
  bucket: "acme-assets-prod",
});

const db = new aws.rds.Instance("orders", {
  identifier: "orders-prod",
  engine: "postgres",
  instanceClass: "db.t3.medium",
  allocatedStorage: 20,
});

Pulumi supports self-managed state backends (S3, GCS, Azure Blob) as well as its hosted Pulumi Cloud service, so you're not forced onto a SaaS. It also has a Kubernetes Operator if you want GitOps-style reconciliation, which narrows the gap with Crossplane's model for teams who liked that part.

Good fit for: teams who want general-purpose languages, type checking, and the ability to unit-test infrastructure code, without running a control-plane cluster.

Less good fit for: teams that want a strictly declarative artifact with no imperative escape hatches, or that are avoiding a hosted state service and don't want to operate their own state backend. See Pulumi alternatives for adjacent options.

AWS CDK

If you left Crossplane because you're only on one cloud and multi-cloud was never the point, and that cloud is AWS, the CDK is worth a look. You write typed constructs in TypeScript (or Python, Go, Java), and the CDK synthesizes CloudFormation, which AWS then deploys and manages. No state file to host, no control-plane cluster.

// lib/stack.ts
import { Stack, StackProps } from "aws-cdk-lib";
import { Bucket } from "aws-cdk-lib/aws-s3";
import { DatabaseInstance, DatabaseInstanceEngine } from "aws-cdk-lib/aws-rds";
import { Construct } from "constructs";

export class AppStack extends Stack {
  constructor(scope: Construct, id: string, props?: StackProps) {
    super(scope, id, props);

    new Bucket(this, "Assets", { bucketName: "acme-assets-prod" });

    new DatabaseInstance(this, "Orders", {
      engine: DatabaseInstanceEngine.POSTGRES,
      // ...vpc, instance type, etc.
    });
  }
}

Higher-level CDK constructs (L2 and L3) give you sensible defaults in the way Crossplane Compositions do, but scoped to AWS and expressed in code rather than CRDs. The cost is CloudFormation itself: stack drift, slow rollbacks, and the occasional resource that CloudFormation supports poorly. See AWS CDK vs Terraform and AWS CDK alternatives for the tradeoffs in detail.

Good fit for: AWS-only teams who want typed, reusable constructs and are comfortable with CloudFormation as the execution engine.

Less good fit for: anyone who needs more than one cloud, or who has been burned by CloudFormation's rollback and drift behavior.

Cloud-Native Operators: Config Connector, ACK, ASO

If the part of Crossplane you liked was the Kubernetes-native reconciliation, and you don't need multi-cloud, the cloud vendors ship their own operators that do the same thing with less abstraction:

• Config Connector (GCP) reconciles Google Cloud resources from Kubernetes manifests.
• ACK (AWS Controllers for Kubernetes) does the same for AWS services.
• ASO (Azure Service Operator) does the same for Azure.

# ACK: an S3 bucket as a Kubernetes resource, reconciled by the AWS controller
apiVersion: s3.services.k8s.aws/v1alpha1
kind: Bucket
metadata:
  name: acme-assets-prod
spec:
  name: acme-assets-prod

These keep the continuous-reconciliation model and the "everything is a CRD" ergonomics, and because each is maintained by the cloud provider, coverage of that provider's API tends to track more directly than a third-party layer. You still run a Kubernetes cluster as the control plane, so the operational weight that pushes some teams off Crossplane is still present. What you shed is Crossplane's multi-cloud abstraction and its composition machinery. If you're on exactly one cloud and already run Kubernetes, a vendor operator is often the leaner choice.

Good fit for: single-cloud teams already operating Kubernetes who want native reconciliation without Crossplane's composition layer.

Less good fit for: teams that wanted to stop running a control-plane cluster, or that need one config surface across multiple clouds. See Crossplane vs Terraform for how the operator model compares to plain IaC.

Infrastructure from Code: Encore

The alternatives above all keep infrastructure in a separate layer from application code, whether that's HCL, a Pulumi program, CDK constructs, or CRDs. A different answer, and the one worth considering if you're starting a new backend rather than migrating an existing platform, is to remove the separate layer entirely.

Encore is an open-source infrastructure-from-code framework for TypeScript and Go. You declare the infrastructure your backend needs (databases, Pub/Sub, cron jobs, object storage) directly in the application code, and Encore Cloud provisions the real resources in your own AWS or GCP account.

import { api } from "encore.dev/api";
import { SQLDatabase } from "encore.dev/storage/sqldb";
import { Bucket } from "encore.dev/storage/objects";

// Provisions managed Postgres (RDS on AWS, Cloud SQL on GCP, Docker locally).
const db = new SQLDatabase("orders", { migrations: "./migrations" });

// Provisions an object store (S3 on AWS, GCS on GCP).
const assets = new Bucket("assets");

export const create = api(
  { method: "POST", path: "/orders", expose: true },
  async (req: { customerID: string }) => {
    const row = await db.queryRow`
      INSERT INTO orders (customer_id) VALUES (${req.customerID})
      RETURNING id
    `;
    return row;
  },
);

The same code runs locally with encore run, in a preview environment per pull request, and in production. There's no separate state file and no control-plane cluster. Encore provisions the underlying AWS or GCP services in your own account, so there are no runtime dependencies on Encore in production, and encore build docker produces a standalone image for teams who want to leave.

This is not a like-for-like Crossplane replacement. Crossplane is built for platform teams provisioning arbitrary cloud resources across many services and clouds, and it will keep making sense for that job. What infrastructure from code replaces is the configuration sprawl that grows around an application backend, and it fits best when the "infrastructure" you care about is application-level (databases, queues, secrets, scheduled jobs) rather than fleets of VMs and low-level networking.

Encore is open source (12k+ GitHub stars) and used in production by teams including Groupon.

Good fit for: application teams starting a new backend who want infrastructure derived from their code, running in their own cloud account, without a control plane to operate.

Less good fit for: platform teams whose job is provisioning shared cloud infrastructure unrelated to a specific application, or anyone who needs to model resources across clouds Encore doesn't target.

How to Choose

Move to Terraform or OpenTofu if you want the default, want the largest provider ecosystem, and are happy to stop running a Kubernetes control plane. Accept discrete apply in place of continuous reconciliation.

Move to Pulumi if you want infrastructure in a real programming language with types and tests, and you're comfortable with either a hosted or self-managed state backend.

Move to AWS CDK if you're committed to AWS, never needed multi-cloud, and want typed constructs synthesizing to CloudFormation.

Move to a cloud-native operator (Config Connector, ACK, ASO) if the Kubernetes reconciliation model was the thing you liked about Crossplane, you're on a single cloud, and you're fine keeping a cluster as the control plane.

Adopt infrastructure from code (Encore) if you're building a new application backend, the infrastructure you care about is application-level, and you want it provisioned in your own AWS or GCP account without a separate IaC layer or control plane.

If Crossplane felt too Kubernetes-centric, Terraform, OpenTofu, or Pulumi get you off the cluster while keeping the same general IaC model. If the operational weight was the problem but you liked the reconciliation, a vendor operator is leaner than Crossplane. And if you're starting fresh and the infrastructure is just what your backend needs to run, infrastructure from code removes the layer altogether.

Related Resources

• Crossplane vs Terraform
• OpenTofu vs Terraform in 2026
• Pulumi alternatives
• AWS CDK alternatives
• Encore vs Terraform, CDK, Pulumi, and SST

Frequently asked questions

What are the main alternatives to Crossplane?

The common alternatives are Terraform and OpenTofu (HCL-based IaC), Pulumi (IaC in general-purpose languages), AWS CDK (typed synthesis to CloudFormation), the cloud vendors' own Kubernetes operators (Config Connector, ACK, ASO), and infrastructure-from-code frameworks like Encore. Which one fits depends on whether you want to keep a control plane running, and whether you already operate Kubernetes.

Why do teams move away from Crossplane?

The most common reasons are that Crossplane requires a running Kubernetes cluster as a control plane even when the workloads it provisions have nothing to do with Kubernetes, and that authoring Compositions and XRDs is heavier than teams expect. Teams without existing Kubernetes expertise often find the operational cost hard to justify.

Is Terraform a good replacement for Crossplane?

For most teams that don't already run everything through Kubernetes, yes. Terraform (or OpenTofu) provisions the same cloud resources without requiring a control-plane cluster, has a far larger provider ecosystem, and is the default most engineers already know. You trade Crossplane's continuous reconciliation for a plan/apply model.

Does Crossplane require Kubernetes?

Yes. Crossplane runs as a set of controllers inside a Kubernetes cluster and uses the Kubernetes API as its control plane. Even if you only want to provision an S3 bucket or an RDS instance, you need a cluster to run Crossplane itself.

What is the difference between Crossplane and cloud-native operators like ACK or Config Connector?

All of them are Kubernetes operators that reconcile cloud resources from Kubernetes manifests. Crossplane is multi-cloud and adds composition abstractions (XRDs, Compositions). ACK (AWS), Config Connector (GCP), and ASO (Azure) are single-vendor, maintained by the cloud provider, and generally track that provider's API surface more directly with less abstraction.