How does Crossplane compare to Terraform for infrastructure management?

Think of the difference like two approaches to keeping your garden healthy. Terraform is like a gardener who visits once a week, takes a photo of the garden, compares it to the blueprint, makes all the changes needed, and leaves until next week. Between visits, weeds can grow, plants can die, and animals can dig holes without anyone noticing. Crossplane is like an automated sprinkler and monitoring system that runs twenty-four hours a day, continuously sensing soil moisture, detecting weeds, and making adjustments in real time. Both approaches result in a healthy garden, but they handle drift and real-time changes very differently.

The most fundamental architectural difference is the reconciliation model. Terraform uses an imperative workflow: you run terraform plan to see what would change, then terraform apply to make those changes. Between runs, Terraform has no awareness of your infrastructure. If someone modifies an RDS instance through the AWS console, Terraform will not notice until the next plan-and-apply cycle, which might not happen for hours or days. Crossplane controllers run continuously inside Kubernetes, checking the state of every Managed Resource every few minutes. If someone manually changes the security group for the payments-api database, Crossplane detects the drift and reverts it within minutes. This continuous reconciliation means your Git repository remains the true source of truth at all times, not just at the moment of the last apply.

State management is another major differentiator. Terraform maintains a state file that records the mapping between your configuration and real cloud resources. This state file is critical and fragile. If it becomes corrupted, gets out of sync, or is lost, you face a painful recovery process involving terraform import for every resource. Teams have spent entire weekends reconstructing state files after S3 backend issues or accidental deletions. Crossplane stores its state in the Kubernetes API server, backed by etcd, which is the same battle-tested system that stores all your application workloads. There is no separate state file to manage, back up, or worry about. The Managed Resources in the cluster are the state, and etcd handles persistence, replication, and backup through the same mechanisms that protect your Deployments and Services.

The developer experience and access model differ significantly. With Terraform, developers need the Terraform CLI installed, access to the state backend, cloud provider credentials on their workstation, and knowledge of HCL, the HashiCorp Configuration Language. With Crossplane, developers interact through kubectl and YAML, tools they already use daily for application deployments. RBAC controls who can create which resources in which namespaces, and credentials are managed centrally through ProviderConfigs rather than distributed to individual developer laptops. For the order-processing-service team, requesting a database is as simple as creating a Claim in their namespace, the same workflow they use to create a Deployment or ConfigMap.

However, Terraform has significant advantages that should not be dismissed. Its ecosystem is massive and battle-tested, with thousands of providers and modules covering virtually every cloud service and SaaS platform. Terraform's plan output gives operators a clear preview of changes before they are applied, which is a safety mechanism that Crossplane's continuous reconciliation does not natively provide in the same way. Terraform is also simpler to get started with because it does not require a Kubernetes cluster as a prerequisite. For teams without existing Kubernetes expertise, or for managing the Kubernetes clusters themselves, Terraform often makes more sense. Many organizations use both: Terraform for foundational infrastructure like VPCs, Kubernetes clusters, and IAM roles, and Crossplane for application-level infrastructure like databases, caches, and queues that the checkout-service and inventory-sync teams provision through self-service.

The choice between Crossplane and Terraform often comes down to organizational context rather than technical superiority. If your organization is Kubernetes-native, has a platform engineering team, and wants to build an Internal Developer Platform with self-service infrastructure, Crossplane fits naturally into that architecture. If your infrastructure team has deep Terraform expertise, a mature CI/CD pipeline for Terraform runs, and manages infrastructure that spans beyond Kubernetes, continuing with Terraform while evaluating Crossplane for specific use cases is a pragmatic approach.