Composite resources & compositions

Bundle many resources into one API.

Managed resources are low-level — a real service needs a database plus a subnet group plus a security group plus a parameter group, and you do not want every developer wiring those five MRs by hand. A Composition bundles a set of managed resources into a single higher-level unit, and a Composite Resource (XR) is an instance of that unit. The composition is the template; the XR is one provisioned stack of the underlying resources.

apiVersion: apiextensions.crossplane.io/v1
kind: Composition
metadata: { name: postgres-aws }
spec:
  compositeTypeRef: { apiVersion: acme.io/v1alpha1, kind: XPostgresInstance }
  resources:
    - name: db
      base:
        apiVersion: rds.aws.upbound.io/v1beta1
        kind: Instance
        spec: { forProvider: { engine: postgres, instanceClass: db.t3.micro } }
    - name: subnet-group
      base: { apiVersion: rds.aws.upbound.io/v1beta1, kind: SubnetGroup, ... }
    - name: sg
      base: { apiVersion: ec2.aws.upbound.io/v1beta1, kind: SecurityGroup, ... }

Patching values through

A composition is not static — it patches values from the composite down into the base resources, so a size or region set once on the XR flows into every underlying MR. This is how one input (“size: large”) becomes the right instance class on the database and the right settings elsewhere. The composition encodes your organization’s opinion about how a Postgres instance should actually be built.