Build a Self-Service Infrastructure Portal on Top of Crossplane (2026)

Crossplane’s infrastructure portal isn’t just a dashboard; it’s a dynamic control plane that lets you provision and manage cloud resources using familiar Kubernetes concepts.

Let’s see it in action. Imagine you have a team that needs a PostgreSQL database instance. Instead of them digging through AWS RDS consoles or writing complex Terraform, they can interact with a simple CompositeResourceDefinition (XRD) and CompositeResource (Compo) within Kubernetes.

Here’s a simplified CompositeResourceDefinition for a "Managed PostgreSQL Instance":

apiVersion: apiextensions.crossplane.io/v1
kind: CompositeResourceDefinition
metadata:
  name: managedpginstances.database.example.com
spec:
  group: database.example.com
  names:
    kind: ManagedPostgresInstance
    plural: managedpostgresinstances
  versions:
    - name: v1alpha1
      served: true
      schema:
        openAPIV3Schema:
          type: object
          properties:
            spec:
              type: object
              properties:
                parameters:
                  type: object
                  properties:
                    storageGB:
                      type: integer
                      description: "Size of the PostgreSQL instance in GB."
                    instanceClass:
                      type: string
                      description: "Instance class for the database (e.g., db.t3.medium)."
              required:
                - storageGB
                - instanceClass

This CompositeResourceDefinition defines a new Kubernetes API type: ManagedPostgresInstance. It specifies that users can request a PostgreSQL instance by providing storageGB and instanceClass.

Now, a developer can create a ManagedPostgresInstance like this:

apiVersion: database.example.com/v1alpha1
kind: ManagedPostgresInstance
metadata:
  name: my-app-db
spec:
  parameters:
    storageGB: 100
    instanceClass: db.t3.medium

When this ManagedPostgresInstance is created, Crossplane, using a CompositeResource (Compo) and Composition (which we haven’t shown but is the "how-to" for the Compo), translates this request into actual cloud provider resources. In this case, it might provision an AWS RDS instance.

The magic happens in the Composition. It acts as a blueprint, defining how a ManagedPostgresInstance maps to underlying Managed Resources (like RDSInstance from the provider-aws Crossplane provider).

Here’s a glimpse of what that Composition might look like (simplified):

apiVersion: apiextensions.crossplane.io/v1
kind: Composition
metadata:
  name: rdsinstances.database.example.com
  labels:
    provider: aws
spec:
  compositeTypeRef:
    kind: ManagedPostgresInstance
    group: database.example.com
  resources:
    - name: rdsinstance
      base:
        apiVersion: rds.aws.upbound.io/v1beta1
        kind: Instance
        spec:
          # Default values, can be overridden by Compo parameters
          region: us-east-1
          skipFinalizer: false
          writeConnectionSecretToRef:
            namespace: crossplane-system
      patches:
        - fromFieldPath: spec.parameters.storageGB
          toFieldPath: spec.allocatedStorage
        - fromFieldPath: spec.parameters.instanceClass
          toFieldPath: spec.instanceClass
        - fromFieldPath: metadata.name
          toFieldPath: spec.instanceIdentifier

This Composition tells Crossplane: "When you see a ManagedPostgresInstance, create an AWS RDSInstance. Take the storageGB from the ManagedPostgresInstance’s spec.parameters and put it into the RDSInstance’s spec.allocatedStorage. Do the same for instanceClass."

The developer doesn’t need to know anything about AWS RDS or provider-aws. They just declare their desired state in Kubernetes. Crossplane handles the rest, provisioning the RDS instance, and crucially, creating a Kubernetes secret containing the connection details (username, password, endpoint, port) for that database. This secret can then be easily mounted into application pods.

The key insight is that Crossplane abstracts away the complexity of cloud provider APIs and resource provisioning. It turns your cloud infrastructure into a set of declarative Kubernetes Custom Resources. This allows you to manage infrastructure with the same GitOps workflows and tooling you use for your applications, enabling true self-service for your development teams. You can define a catalog of infrastructure offerings (databases, message queues, Kubernetes clusters, etc.) that developers can consume directly from Kubernetes, without needing direct access to cloud consoles or deep knowledge of infrastructure provisioning tools.

When you create a ManagedPostgresInstance, Crossplane doesn’t just create one cloud resource. It can orchestrate multiple underlying managed resources to fulfill the composite request. For instance, it might create not only the RDS instance but also a subnet group, a security group, and configure parameter groups, all based on the single ManagedPostgresInstance custom resource you declared. This allows for much richer and more complex infrastructure patterns to be defined and consumed as simple, single Kubernetes objects.

The next step is often to explore how to automate the creation of these CompositeResourceDefinitions and Compositions themselves, perhaps using tools like the Crossplane CLI or even other Crossplane resources.