Crossplane developers build and maintain cloud infrastructure control planes using Crossplane's Kubernetes-native IaC framework — defining Composite Resource Definitions that abstract cloud resources behind internal APIs tailored to developer teams, writing Compositions that map those internal APIs to actual cloud provider resources (AWS, GCP, Azure), and operating the Crossplane-managed cluster that provisions and reconciles cloud infrastructure from Kubernetes manifests that teams commit to Git. At remote-first technology companies, they serve as the platform engineers who unify infrastructure management under the Kubernetes API server — eliminating the gap between application deployment (Kubernetes) and infrastructure provisioning (Terraform or ClickOps) by making RDS databases, S3 buckets, IAM roles, and GKE clusters just another Kubernetes resource that GitOps tools like Flux and ArgoCD can manage alongside application workloads.
What Crossplane developers do
Crossplane developers install and configure providers — deploying the Crossplane Helm chart and applying provider manifests like apiVersion: pkg.crossplane.io/v1; kind: Provider; metadata: name: provider-aws; spec: package: xpkg.upbound.io/upbound/provider-aws:v1.x to install the AWS provider CRDs; configure provider credentials — creating ProviderConfig objects that reference Kubernetes secrets or IRSA/Workload Identity annotations for cloud credentials, with spec.credentials.source: Secret referencing aws-creds for static keys or InjectedIdentity for AWS IRSA pod identity; create managed resources — applying apiVersion: s3.aws.upbound.io/v1beta1; kind: Bucket; metadata: name: my-bucket; spec: forProvider: region: us-east-1; providerConfigRef: name: aws-config to provision an S3 bucket managed by Crossplane's reconciler; define Composite Resource Definitions (XRDs) — writing apiVersion: apiextensions.crossplane.io/v1; kind: CompositeResourceDefinition; metadata: name: xpostgresqlinstances.database.example.com; spec: group: database.example.com; names: kind: XPostgreSQLInstance; claimNames: kind: PostgreSQLInstance; versions: ... to create an internal API type for PostgreSQL instances; write Compositions — defining apiVersion: apiextensions.crossplane.io/v1; kind: Composition with resources or mode: Pipeline that map XRD fields to managed resource fields using patches, transforms, and fromFieldPath/toFieldPath mappings; implement Composition Functions — using mode: Pipeline with functionRef: name: function-patch-and-transform and composing function-auto-ready, function-go-templating, or custom KCL/CEL functions for complex provisioning logic that exceeds what static patches support; create Claims — allowing developers to provision infrastructure by applying apiVersion: database.example.com/v1alpha1; kind: PostgreSQLInstance; metadata: name: my-db; namespace: my-team; spec: parameters: storageGB: 20; region: us-east-1 which Crossplane resolves to a full RDS instance via the Composition; manage composite resource versioning — defining multiple XRD versions with conversion webhooks and schema evolution strategies that allow Compositions to evolve without breaking existing Claims; use Upbound Marketplace providers — installing family providers like provider-aws-s3, provider-aws-rds, and provider-aws-iam separately to reduce CRD count and memory usage compared to monolithic providers; implement Configuration packages — bundling XRDs and Compositions into apiVersion: meta.pkg.crossplane.io/v1; kind: Configuration packages pushed to OCI registries so internal platform teams can publish reusable infrastructure blueprints consumable with a single Configuration manifest; use the crossplane CLI — running crossplane beta render claim.yaml composition.yaml functions.yaml to locally render and debug what a Composition would produce without deploying to a cluster; and integrate with GitOps — managing Crossplane manifests through ArgoCD ApplicationSets or Flux Kustomizations so all cloud infrastructure changes go through pull requests and automated reconciliation.
Key skills for Crossplane developers
- Providers: Provider CRD; ProviderConfig; credential sources (Secret/IRSA/WorkloadIdentity)
- Managed Resources: forProvider; providerConfigRef; atProvider; deletionPolicy; annotations
- XRDs: CompositeResourceDefinition; spec.group; claimNames; versions; schema (OpenAPI v3)
- Compositions: mode (Resources/Pipeline); resources[]; patches; transforms; fromFieldPath/toFieldPath
- Composition Functions: function-patch-and-transform; function-go-templating; KCL; CEL; custom functions
- Claims: namespace-scoped; XRC spec/status; connection secrets; binding to CompositeResource
- Packages: Configuration; Provider packages; OCI registry; pkg.crossplane.io/v1
- Upbound providers: provider-aws family; provider-gcp; provider-azure; provider-kubernetes
- crossplane CLI: crossplane beta render; crossplane beta validate; trace; beta xpkg
- GitOps integration: ArgoCD; Flux; Composition manifests in Git; PR-driven infra changes
Salary expectations for remote Crossplane developers
Remote Crossplane developers earn $110,000–$178,000 total compensation. Base salaries range from $92,000–$148,000, with equity at technology companies where infrastructure provisioning velocity, developer self-service for cloud resources, and the consistency of cloud infrastructure across environments directly determine platform team leverage and operational reliability. Crossplane developers with production control planes managing hundreds of cloud resources across multiple accounts with comprehensive XRD-based developer APIs, sophisticated Composition Function implementations handling multi-cloud or complex dependency ordering requirements, and demonstrated developer self-service improvements that eliminated infrastructure ticket queues command the strongest premiums. Those with Crossplane combined with deep AWS or GCP provider internals expertise and Kubernetes operator development experience earn toward the top of the range.
Career progression for Crossplane developers
The path from Crossplane developer leads to senior platform engineer (broader scope across the complete internal developer platform including CI/CD pipelines, developer portals, and observability), infrastructure architect (designing the multi-cloud resource management strategy, provider selection, and organizational control plane topology), or cloud native engineer (specializing in the Kubernetes ecosystem for infrastructure automation across operators, service meshes, and policy engines). Some Crossplane developers specialize into internal developer platforms, building the Backstage or Port integrations that expose Crossplane's infrastructure APIs as self-service catalog actions with approval workflows and cost estimates. Others transition into cloud platform product management, leveraging deep infrastructure API design experience to define the roadmap for the internal developer platform that enables application teams to provision infrastructure without deep cloud expertise. Crossplane developers who contribute to the Crossplane project — building providers, improving Composition Functions, or contributing to the core reconciler — participate in one of the most ambitious Kubernetes ecosystem projects.
Remote work considerations for Crossplane developers
Building Crossplane-based infrastructure control planes for distributed platform and application teams requires XRD schema design discipline, Composition testing practices, and provider credential isolation standards that prevent distributed engineers from creating Claims with direct forProvider overrides that bypass the Composition's standardization, writing Compositions without local render testing that fail only after provisioning partially complete cloud resources, or sharing ProviderConfig credentials across team namespaces without audit trail. Crossplane developers at remote companies establish the XRD schema completeness standard — requiring that all XRD spec.parameters fields have descriptions, validation constraints (minLength, minimum, enum), and sensible defaults for optional fields — because distributed developers who consume XRDs without descriptions or validation discover valid-looking configurations that Crossplane silently accepts but the cloud provider rejects at resource creation time; enforce the Composition render-test requirement — requiring that Composition changes are validated with crossplane beta render locally and in CI against representative claim inputs before merging — because Compositions with patch path errors or transformation bugs fail silently at apply time, producing partially provisioned cloud resources whose cleanup requires manual intervention; define the ProviderConfig isolation policy — requiring that each team or environment gets a dedicated ProviderConfig referencing its own cloud credentials with the minimal IAM permissions for that team's resources — because shared ProviderConfigs grant all teams access to each other's provider credentials and produce audit logs that cannot attribute resource creation to a specific team; and establish the deletionPolicy standard — requiring that production Claims explicitly set deletionPolicy: Orphan for stateful resources (databases, storage buckets) — because the Crossplane default deletionPolicy: Delete permanently destroys the managed cloud resource when the Kubernetes object is deleted, and distributed engineers who delete namespaces containing PostgreSQL Claims cause immediate data loss.
Top industries hiring remote Crossplane developers
- Platform engineering teams at technology companies building internal developer platforms where Crossplane's Kubernetes-native API surface enables application teams to provision databases, message queues, and object storage through familiar
kubectl applyworkflows integrated with existing GitOps pipelines - Cloud consulting and managed services companies building reusable infrastructure blueprints as Crossplane Configuration packages that clients install to provision standardized, policy-compliant cloud infrastructure across their accounts
- Financial services and regulated industries using Crossplane's declarative, auditable manifests to satisfy infrastructure change management requirements — every cloud resource change is a Git commit with author, timestamp, and approval history, compared to Terraform state files or console click trails
- Multi-cloud software companies using Crossplane to abstract cloud provider differences behind unified internal APIs so application teams use the same PostgreSQL Claim regardless of whether the underlying implementation is AWS RDS, Cloud SQL, or Azure Database
- SaaS companies building multi-tenant infrastructure using Crossplane to provision per-tenant cloud resources (databases, namespaces, secrets) programmatically from their provisioning API, with Crossplane serving as the control plane that creates and deletes tenant infrastructure through Kubernetes API calls
Interview preparation for Crossplane developer roles
Expect XRD questions: design a CompositeResourceDefinition for a managed database that accepts storageGB, region, and tier parameters — what the XRD spec with version schema and claimNames looks like. Composition questions ask how you'd map the XRD's tier field to different RDS instance types — what a patch with a map transform (small → db.t3.micro, large → db.r5.xlarge) looks like. Managed resource questions ask how you'd provision an S3 bucket with versioning enabled using a Crossplane managed resource — what the apiVersion: s3.aws.upbound.io/v1beta1 manifest and forProvider looks like. Claim questions ask what happens when a developer applies a PostgreSQLInstance Claim — the sequence of XRD → Composition → managed resource creation. GitOps questions ask how you'd manage Crossplane Compositions in ArgoCD so infrastructure changes require a PR — what the ArgoCD Application pointing to the infrastructure repo looks like. Composition Function questions ask when you'd use function-go-templating instead of static patches — when conditional resource creation or list iteration requires logic beyond what map transforms support.
Tools and technologies for Crossplane developers
Core: Crossplane (crossplane/crossplane Helm chart); crossplane CLI; kubectl crossplane plugin; Upbound Universal Crossplane (UXP). Providers: upbound/provider-aws (+ family packages: -s3, -rds, -iam, -eks); upbound/provider-gcp; upbound/provider-azure; crossplane-contrib/provider-kubernetes; crossplane-contrib/provider-helm; provider-terraform. Provider config: ProviderConfig; credentials.source (Secret/IRSA/InjectedIdentity/OIDCTokenFile); AWS IRSA; GCP Workload Identity; Azure Workload Identity. Managed resources: forProvider; atProvider; providerConfigRef; managementPolicies; annotations.crossplane.io/external-name; deletionPolicy. XRDs: CompositeResourceDefinition; claimNames; spec.versions; openAPIV3Schema; defaultCompositionRef; connectionSecretKeys. Compositions: mode: Resources/Pipeline; resources[]; base; patches (FromCompositeFieldPath/ToCompositeFieldPath/CombineFromComposite/PatchSet); transforms (map/string/convert/math/regexp); readinessChecks. Composition Functions: function-patch-and-transform; function-auto-ready; function-go-templating; function-kcl; function-cel-filter; FunctionIO; custom function development (Go SDK). Claims: composite resource claims (XRC); namespace-scoped; spec.resourceRef; connection secrets; status.conditions. Packages: Configuration; meta.pkg.crossplane.io/v1; crossplane.yaml; OCI image (xpkg); Upbound Marketplace. crossplane CLI: crossplane beta render; crossplane beta validate; crossplane beta xpkg build/push; crossplane beta trace. GitOps: ArgoCD + Crossplane; Flux GitRepository + Kustomization; PR-driven infra; infra monorepo. Alternatives: Terraform (non-Kubernetes, mature ecosystem); Pulumi (imperative IaC, stronger programming model); AWS CDK; Helm for app config; Operator SDK (custom operators).
Global remote opportunities for Crossplane developers
Crossplane developer expertise is in strong and growing global demand, with Crossplane's position as the leading Kubernetes-native infrastructure control plane framework — graduated as a CNCF project, backed by Upbound with enterprise support, and adopted by platform engineering teams at companies including GitLab, Deutsche Telekom, and Confluent — creating consistent demand for engineers who understand both Crossplane's Composition model and the internal developer platform design that makes self-service infrastructure safe for application teams. US-based Crossplane developers are in demand at cloud-native technology companies, platform engineering teams at large enterprises, and cloud consulting firms building reusable infrastructure patterns for clients. EMEA-based Crossplane developers are particularly well-positioned given Crossplane's strong European community presence — Crossplane is prominently featured at KubeCon Europe, several EMEA telcos and financial institutions have adopted it for regulated infrastructure provisioning, and its declarative, auditable approach aligns with European IT governance practices. Crossplane's continued development — Composition Functions enabling Turing-complete provisioning logic, the Upbound managed control plane service, and the growing provider ecosystem covering databases, networking, and identity services — ensures sustained demand as Kubernetes becomes the universal control plane for both applications and infrastructure.
Frequently asked questions
What is the difference between a Managed Resource, a Composite Resource, and a Claim in Crossplane? A Managed Resource (MR) is the lowest-level Crossplane object — a 1:1 representation of a single cloud API resource. kind: Bucket in s3.aws.upbound.io/v1beta1 represents one AWS S3 bucket; applying it creates that bucket and Crossplane reconciles its spec to the cloud API indefinitely. MRs are cluster-scoped and expose the full cloud API surface through forProvider. A Composite Resource (XR) is a higher-level object defined by an XRD that abstracts multiple MRs behind a simpler interface. kind: XPostgreSQLInstance might create an RDS instance, a security group, and an IAM user — the developer doesn't see the individual MRs. XRs are cluster-scoped. A Claim (XRC) is the namespace-scoped projection of a Composite Resource — it has a simpler schema (kind: PostgreSQLInstance without the X prefix), lives in a team's namespace, and binds 1:1 to an XR created in the root namespace. Claims are the intended interface for application teams: they provision infrastructure through namespace-scoped objects without needing cluster-wide access, while platform engineers control the Compositions that define what actually gets provisioned.
How does Crossplane differ from Terraform and when should you choose each? The core difference is the control loop: Terraform applies a plan and exits; Crossplane runs continuously and reconciles drift. Terraform's terraform apply generates a plan, applies it, writes state, and terminates — if someone manually changes the S3 bucket's lifecycle policy in the console, Terraform doesn't know until the next plan. Crossplane's reconciler watches every managed resource's actual cloud state against spec every few minutes and re-applies diverged resources automatically, providing drift detection without additional tooling. Choose Crossplane when: infrastructure is tightly coupled with Kubernetes (GitOps pipelines already manage Kubernetes resources, application teams should provision databases through kubectl), you want continuous drift correction, or you're building an internal developer platform with self-service claims. Choose Terraform when: teams have deep Terraform expertise and large existing HCL codebases, infrastructure spans non-Kubernetes environments (VMs, network hardware), or you need multi-cloud modules that the Terraform Registry provides with broad community support. The two complement each other: some organizations use Terraform for foundational account-level infrastructure (VPCs, DNS zones) and Crossplane for application-level resources (databases, queues, storage).
How do Composition Functions differ from patch-and-transform Compositions, and when do you need them? Classic Compositions use mode: Resources with declarative patches and transforms — static field path mappings, string format transforms, and map-based value translations. This covers most use cases: mapping a Claim's tier field to an RDS instance class via a map transform, formatting a bucket name by combining the Claim name with a fixed prefix, or converting a string to an integer. Composition Functions (mode: Pipeline) enable arbitrary Go, KCL, CEL, or templating logic for cases that static patches cannot express: conditionally creating resources based on claim fields (create a read replica only if tier=production), iterating over a list field to create multiple resources (provision one security group rule per CIDR in a list), computing derived values (calculate IOPS as 3× storage size), or orchestrating dependent resource creation order with status checks. Functions are compiled Go programs or interpreted scripts packaged as OCI images, called sequentially in a pipeline with FunctionIO as the data exchange format. Start with mode: Resources + function-patch-and-transform for simple Compositions; introduce function-go-templating or function-kcl when you hit the limits of static patches.