What is Crossplane?
Crossplane extends Kubernetes so that cloud infrastructure can be described the same way workloads are. A database, a bucket, a network, a managed service: each becomes a Kubernetes resource you create with the tools you already use. It is a CNCF graduated project.
The consequence that matters is not the syntax. It is that Kubernetes then does what Kubernetes does with everything else: it keeps checking that reality matches the description, and corrects it when it does not.
How that differs from Terraform
Both let you describe infrastructure in files and keep them in git. The difference is what happens after you apply.
Terraform runs. You execute it, it compares your description against a state file, makes changes, and stops. Between runs nothing is watching. If someone changes a setting in a cloud console, the infrastructure is now different from the description, and it stays different until the next run tells you.
Crossplane reconciles. A controller runs continuously. The same manual console change is noticed and corrected without anyone running anything.
That produces the practical differences teams actually feel:
- No state file. The cluster holds the state, so the whole category of problems around state storage, locking and corruption does not arise.
- Drift correction rather than drift detection. The gap between "we found out" and "it is fixed" closes.
- One control plane for workloads and their infrastructure. An application and the database it needs are described together, deployed together, and torn down together.
This is not a claim that Crossplane is better than Terraform. It is a different model, and a lot of what is written about it obscures that the choice is between "run a tool" and "run a control plane".
The part that is the actual point
Crossplane's real use is not replacing your Terraform files with YAML files. It is that a platform team can define its own resource types.
You build a resource called, say, a production database, which encodes your organization's decisions: which provider, which region, backups on, encryption on, the naming convention, the tags finance requires. Developers then ask for one of those, and they cannot get the parts wrong because the parts are not exposed.
That is a self-service platform with guardrails, and it is the thing worth building. Everything above is the mechanism.
When it fits
- A platform team exists. Someone has to define and maintain those resource types. Crossplane gives that team reach; it does not replace it.
- Kubernetes is already the center of gravity. If your teams live in kubectl and GitOps, this extends what they already know rather than adding a second toolchain.
- Developers need infrastructure without tickets, and the organization is not willing to give them raw cloud console access.
- Drift is a real problem, because people do change things by hand and always will.
When it does not
No platform team, or no Kubernetes. Crossplane on a cluster nobody runs confidently is a second hard thing on top of a first hard thing. Terraform in a pipeline is the smaller answer, and often the right one.
A handful of long-lived resources. If infrastructure changes twice a year, continuous reconciliation solves a problem you do not have.
A mature Terraform practice that works. Modules, review, a pipeline, people who know it. Migrating that to a new model has a real cost and needs a real reason. "It is newer" is not one.
What running it involves
- The providers are the surface. Each cloud provider is its own component with its own release cadence and its own coverage gaps. Check that the specific resources you need are actually supported before committing.
- Your resource definitions are software. Compositions get versioned, reviewed and migrated, and someone owns them. This is the work; the install is not.
- Blast radius. A control plane that can create infrastructure can also delete it. Deletion policies and access control are day-one decisions, not day-ninety ones.
- The cluster becomes load-bearing. If Crossplane manages your infrastructure, the cluster it runs on is infrastructure everything else depends on.
Where VSHN fits
VSHN is an official Crossplane vendor and has run it in production since 2021. We design and operate Crossplane platforms on Swiss cloud providers, including the composition design that decides whether developers get a usable self-service API or another abstraction they route around. Our comparison page sets it against Terraform and the alternatives in more detail.
If you are weighing a migration from Terraform, the question worth answering first is whether you want a self-service platform at all, since that is what justifies the move. Without it, the two tools are closer than the marketing suggests.