Crossplane: When IaC Meets Kubernetes — Can It Replace Terraform?

Terraform Has Done Its Job — But There's a Catch

Terraform has dominated the Infrastructure as Code space for nearly a decade. HCL is familiar, the provider ecosystem spans 3000+ integrations, and the plan → apply workflow is intuitive. But in 2023, HashiCorp changed its license from MPL to BUSL — a shock that pushed many teams toward the OpenTofu fork.

However, license isn't the only issue. Terraform is a standalone CLI tool. It runs outside your cluster. State management requires a remote backend with locking. And most importantly: Terraform doesn't "live" alongside your infrastructure — it only runs when you invoke it.

Meanwhile, Kubernetes has become the default deployment platform. So the question becomes: why not use Kubernetes itself to manage infrastructure?

That's exactly what Crossplane does. And in November 2025, Crossplane officially achieved CNCF graduation — joining the ranks of Kubernetes, Prometheus, and Helm.

What Is Crossplane?

Crossplane is a Kubernetes operator — you install it in your cluster, and it transforms your cluster into a control plane for provisioning cloud infrastructure. Instead of running terraform apply, you run kubectl apply to create RDS databases, S3 buckets, or IAM roles.

apiVersion: rds.aws.upbound.io/v1beta1
kind: Instance
metadata:
  name: my-database
spec:
  forProvider:
    region: ap-southeast-1
    dbInstanceClass: db.t3.micro
    engine: postgres
    allocatedStorage: 20
    masterUsername: admin
    passwordSecretRef:
      name: db-password
      key: password
      namespace: crossplane-system

And just like that, you have an RDS instance — managed by the Kubernetes control loop, continuously reconciling to ensure the actual state matches your desired configuration.

Core Difference: Control Plane vs CLI Tool

• Terraform: You run a command → Terraform compares state file with reality → creates/updates resources. Then it "sleeps" until your next run.
• Crossplane: You declare resources in YAML → Crossplane continuously monitors and adjusts. Someone manually deleted that S3 bucket? Crossplane recreates it automatically.

This is the difference between imperative runs and continuous reconciliation.

CNCF Graduation: A Major Milestone

In November 2025, Crossplane became a graduated CNCF project — the highest maturity level, alongside Kubernetes, Prometheus, and Envoy. To earn this status, Crossplane has:

• Over 3,000 contributors from 480+ companies
• More than 70 public adopters including Nike, Nokia, Grafana, NASA, SAP, and IBM
• Completed 2 comprehensive security audits
• Earned the OpenSSF Best Practices badge
• Shipped over 100 releases with a clear LTS policy
• Ranked #13 out of 231 CNCF projects by PR authors — top 10%

These aren't just marketing numbers — they signal that Crossplane is truly production-ready.

Crossplane vs Terraform: When to Use Which?

1. Approach

• Architecture: Terraform is a standalone CLI. Crossplane is a Kubernetes operator.
• Language: Terraform uses HCL. Crossplane uses YAML.
• State: Terraform uses a centralized state file. Crossplane uses etcd via the K8s API.
• Reconciliation: Terraform reconciles on-demand. Crossplane reconciles continuously.
• License: Terraform is BUSL. Crossplane is Apache 2.0.
• Ecosystem: Terraform has 3000+ providers. Crossplane's ecosystem is growing rapidly.

2. Developer workflow

Terraform: Write HCL → terraform plan → review → terraform apply → merge PR. You need a CI/CD pipeline for automation, a remote state backend (S3 + DynamoDB, or Terraform Cloud), and state locking to prevent race conditions.

Crossplane: Write YAML → kubectl apply → done. No separate pipeline, no state file, no locking. Kubernetes handles everything.

For developers already comfortable with Kubernetes, Crossplane significantly reduces cognitive load. One API (kubectl) for both application and infrastructure.

3. When to use Crossplane

• Your team already runs Kubernetes and is comfortable with the ecosystem
• You're building an internal developer platform (IDP)
• You want developers to self-service provision resources without learning Terraform
• You need continuous reconciliation (automatic drift correction)
• You want truly open-source (Apache 2.0, no license surprises)

4. When to stick with Terraform

• You're managing foundational infrastructure (VPCs, IAM, EKS clusters)
• Your team doesn't use Kubernetes or doesn't want to operate a cluster
• You need the mature provider ecosystem (3000+ providers)
• You've invested heavily in Terraform modules and existing workflows
• You rely on terraform plan to review changes before applying

5. The hybrid approach: Use both

The most common pattern today isn't "pick one" — it's use both for what they do best:

• Terraform provisions foundational infrastructure: VPCs, subnets, IAM roles, EKS clusters, security groups
• Crossplane manages resources inside the cluster: RDS databases, S3 buckets, cache clusters, message queues, service accounts

This is the pattern recommended by Upbound (the company behind Crossplane) and adopted by many production teams.

Composition: Crossplane's Real Superpower

Terraform has modules. Crossplane has Compositions. This feature lets you define custom abstract APIs for your infrastructure:

apiVersion: apiextensions.crossplane.io/v1
kind: Composition
metadata:
  name: postgres-instance
spec:
  compositeTypeRef:
    apiVersion: database.example.com/v1alpha1
    kind: XPostgreSQL
  resources:
    - base:
        apiVersion: rds.aws.upbound.io/v1beta1
        kind: Instance
        spec:
          forProvider:
            engine: postgres
            dbInstanceClass: db.t3.micro
            allocatedStorage: 20

Then, your developers simply request:

apiVersion: database.example.com/v1alpha1
kind: PostgreSQL
metadata:
  name: my-app-db
spec:
  size: small
  backupRetention: 7

Crossplane automatically "compiles" this simple request into a full RDS instance with the right security groups, subnet groups, and parameter groups — all following policies defined by the platform team.

This is the foundation of platform engineering: the platform team defines the "paved road," and developers walk on it without needing to know infrastructure details.

Limitations and Considerations

No tool is perfect. Crossplane has some caveats:

• Debugging is harder: When a resource fails to provision, logs are in the Crossplane pod — not always easy to find
• Learning curve: You need to know Kubernetes before learning Crossplane. YAML is more verbose than HCL
• Composition overhead: For small teams, writing Compositions for every resource type can be over-engineering
• Provider coverage: While growing fast, the number of providers is still significantly less than Terraform
• Drift detection visibility: Crossplane auto-corrects drift (good), but sometimes you want to know about drift before it's fixed (requires additional tooling)

Key Takeaways for Developers

If you're a developer transitioning into DevOps/SA:

• Crossplane isn't replacing Terraform — not within the next 1-2 years. But it's redefining how we think about IaC
• Learn Crossplane if you're doing platform engineering or your team uses Kubernetes heavily
• Keep Terraform if you manage multi-cloud foundational infrastructure or your team doesn't use Kubernetes
• The hybrid pattern (Terraform for foundation + Crossplane for workload resources) is the pragmatic choice for most teams today
• CNCF graduation is a strong signal: Crossplane is production-ready, not a "cool toy" anymore

One question to think about: your team already uses Kubernetes to deploy apps — why not use it to provision infrastructure too?

---

This post was created with AI assistance (Amy 🌸). Content has been reviewed by the author.