Crossplane vs Terraform for Modern Platform Engineering

For years, Terraform has been the undisputed king of infrastructure provisioning. You write some HCL, run an application pipeline, and watch your cloud resources appear. It feels almost magical until you hit real enterprise scale. 🚀

The moment a developer manually tweaks a security group inside the AWS console, your static state file becomes inaccurate. You often do not discover the configuration drift until the next scheduled CI/CD execution fails, or worse, during a critical production outage.

This is the core limitation of traditional Infrastructure as Code. Tools like Terraform and OpenTofu are excellent deployment engines, but they are not true control planes. They rely on a push-based execution model that applies a static plan and then walks away.

As platform engineering teams continue building modern Internal Developer Platforms (IDPs), they are running directly into the architectural limits of this workflow. They need active, continuous management of infrastructure resources, which is exactly why enterprise teams are rapidly migrating toward Crossplane.

The Architectural Divide: Push vs Pull

To understand the growing shift toward platform engineering control planes, we first need to understand how infrastructure state is managed.

With traditional Infrastructure as Code, your CI/CD pipeline triggers a push-based operation. The pipeline authenticates with the cloud provider, checks the stored state file, calculates the difference, applies the changes, and terminates.

If someone modifies those cloud resources five minutes later, your pipeline remains completely unaware until the next manual or scheduled execution.

Crossplane completely flips this architecture by using a pull-based model built natively on Kubernetes. It leverages the Kubernetes reconciliation loop to achieve continuous infrastructure reconciliation.

The platform does not simply apply your infrastructure configuration once. Instead, it continuously watches your live cloud environment. If an engineer manually deletes a database instance or changes an IAM policy, Crossplane immediately detects the drift and automatically restores the infrastructure to its declared state. ⚡

As illustrated in the deployment architecture above, Crossplane effectively transforms your cluster into a Kubernetes universal control plane. Instead of relying on isolated runner VMs executing shell commands, the platform manages cloud APIs directly from inside the Kubernetes control layer itself.

Turning Kubernetes Into a Universal Cloud Control Plane

By installing Crossplane inside a Kubernetes cluster, platform engineers extend the Kubernetes API using Custom Resource Definitions (CRDs). This allows external cloud infrastructure, such as:

• AWS RDS databases
• GCP Cloud Storage buckets
• Azure SQL instances
• IAM roles and policies
• VPC networking resources

to be managed directly through standard Kubernetes YAML manifests.

This model provides major advantages for platform teams trying to balance developer autonomy with enterprise governance.

Instead of forcing developers to learn cloud-provider-specific tooling or write large HCL configurations, platform teams can publish simplified internal infrastructure APIs.

Developers no longer require:

• direct cloud console access
• elevated IAM permissions
• knowledge of provider-specific deployment logic

They simply deploy infrastructure using tools they already understand:

• kubectl
• GitOps controllers
• Internal Developer Portals
• Kubernetes-native workflows

Crossplane XRD Tutorial: Building Internal Self-Service APIs

The real power of Crossplane comes from composability.

Platform engineering teams use Composite Resource Definitions (XRDs) to bundle complex infrastructure patterns into clean, reusable, self-service APIs.

Instead of handing developers massive Terraform modules with dozens of variables, platform teams expose simplified enterprise resources.

For example, imagine defining a custom internal resource called:
CompositePostgresInstance

The platform team first creates the XRD structure:

apiVersion: apiextensions.crossplane.io/v1
kind: CompositeResourceDefinition

metadata:
  name: xpostgresinstances.devopsinside.com

spec:
  group: devopsinside.com

  names:
    kind: XPostgresInstance
    plural: xpostgresinstances

  versions:
    - name: v1alpha1
      served: true
      referenceable: true

      schema:
        openAPIV3Schema:
          type: object

          properties:
            spec:
              type: object

              properties:
                storageGB:
                  type: integer

              required:
                - storageGB

Behind the scenes, the platform team then creates a Composition file that maps this custom API resource to actual cloud infrastructure, such as:

• AWS RDS instances
• Private networking
• Security groups
• Encryption policies
• Backup configurations

Once this abstraction layer is published, application teams can provision a secure production database using an extremely minimal manifest:

apiVersion: devopsinside.com/v1alpha1
kind: PostgresInstanceClaim

metadata:
  name: billing-db
  namespace: team-alpha

spec:
  storageGB: 50

The developer gets a production-ready database within minutes, while the platform engineering team retains full governance over networking, compliance, backups, encryption, and organizational security policies. 🔐

Crossplane vs Terraform: Choosing the Right Tool

Crossplane is gaining significant traction across enterprise platform engineering, but that does not mean Terraform instantly becomes obsolete.

Both tools solve different problems across the infrastructure lifecycle.

For many organizations, the future is hybrid:

• Terraform/OpenTofu handles foundational infrastructure provisioning
• Crossplane manages continuous operational reconciliation and developer self-service APIs

Why Platform Engineering Teams Are Migrating

Modern enterprise infrastructure is becoming too dynamic for static execution pipelines.

As cloud-native architectures scale:

• infrastructure drift increases
• CI/CD pipelines become brittle
• operational overhead grows
• governance complexity explodes

Crossplane solves this by bringing infrastructure management directly into the Kubernetes control plane itself.

Instead of constantly reacting to infrastructure changes, the platform continuously reconciles reality against declared intent. That is a massive architectural shift for modern Internal Developer Platforms. ☁️

The Verdict

Crossplane represents the next evolution of cloud-native platform engineering. By transforming Kubernetes into a universal control plane, organizations gain continuous reconciliation, self-service infrastructure APIs, and dramatically improved operational consistency.

If your platform engineering team is tired of chasing configuration drift, debugging broken CI/CD executions, and maintaining oversized Terraform modules, it may be time to move beyond static Infrastructure as Code toward active infrastructure control planes.