When we started working on Crossplane back in 2018, we had a simple but ambitious goal: bring the elegance of Kubernetes APIs to infrastructure management. Seven years, 3,000+ contributors, and over 100 releases later, we're thrilled to announce Crossplane 2.0—a release that doesn't just represent new features, but rethinks how platform teams approach control planes.
Crossplane 2.0 is the culmination of everything we've learned from watching real-world platform teams scale from managing a handful of cloud resources to orchestrating entire application ecosystems. It's the result of helping folks debug real production issues, iterating on APIs with hundreds of community members, and constantly asking ourselves: "How can we make this simpler?"
What's New in Crossplane 2.0
- Application support - Crossplane 2.0 extends beyond infrastructure to manage applications alongside your cloud resources
- Broader composition capabilities - Compositions can now include any Kubernetes resource, not just Crossplane-defined resources, enabling full-stack abstractions
- Namespaced by default - Composite Resources (XRs) and Managed Resources (MRs) are now namespaced, providing better isolation and aligning with Kubernetes conventions
- Declarative day two operations - The new Operation type supports one-off, scheduled, and event-driven workflows for upgrades, backups, and maintenance
- Managed resource filtering - Install only the managed resources you need instead of getting everything from a provider
The Problem We Set Out to Solve
When we first built Crossplane, we focused on what seemed like the biggest pain point: giving developers self-service access to cloud infrastructure without the operational overhead. The early versions did this well—platform teams could wrap cloud resources like AWS RDS instances in their own APIs, hide the complexity of security groups and subnet configurations, and let developers get infrastructure with simple YAML declarations.
But as we watched teams adopt Crossplane in production, a pattern emerged. Infrastructure was just the beginning. Crossplane v1 let teams move their infrastructure management into Kubernetes with declarative APIs, but applications and infrastructure remained separate concerns. Platform teams could offer self-service APIs for databases and storage, but those APIs couldn't include applications. Teams still had to manage their apps and infrastructure as distinct, disconnected pieces.
The problem was that Crossplane v1's architecture, while powerful, had become overly opinionated. Claims, cluster-scoped resources, and infrastructure-only compositions had also grown complex and created unnecessary friction. We realized we needed to step back and ask: what would Crossplane look like if we designed it today, with everything we've learned?
What We Built
Crossplane 2.0 represents our answer to that question. Here's what's fundamentally different:
Applications Are First-Class Citizens
The biggest change in Crossplane 2.0 is that compositions can now include any Kubernetes resource, not just Crossplane-managed infrastructure. This means you can define a composite resource that provisions a database, configures networking, deploys an application, and sets up monitoring, all in one cohesive abstraction.
For example, a platform team could now offer their development teams a simple "microservice" API that provisions everything needed for a new service:
apiVersion: platform.acme.io/v1
kind: Microservice
metadata:
namespace: team-api
name: user-service
spec:
image: acme/user-service:v1.2.3
database:
engine: postgres
size: medium
ingress:
subdomain: users
Behind the scenes, this creates an RDS instance, configures security groups, deploys the application via a Kubernetes Deployment, creates a Service and Ingress, and even sets up monitoring dashboards. The platform team handles all the complexity; the development team gets exactly what they need.
Namespaces by Default
We've moved away from the cluster-scoped-by-default model that often confused new users. In Crossplane 2.0, both composite resources and managed resources are namespaced by default. This aligns with Kubernetes conventions and makes multi-tenancy much more intuitive.
The old claim/XR duality is gone. Instead, you simply create resources in the namespace where they belong:
apiVersion: example.crossplane.io/v1
kind: Database
metadata:
namespace: frontend-team
name: user-db
spec:
engine: postgres
storage: 100Gi
For the rare cases where you need cluster-scoped resources like shared networking infrastructure, you can still create them, but now it's an explicit choice rather than the default.
Day Two Operations, Declaratively
One of the most exciting additions is the new Operation type. After years of watching teams struggle with operational tasks like backups, upgrades, and maintenance windows, we realized these shouldn't require custom controllers or external cron jobs.
Operations bring the same declarative approach you know from Crossplane to operational workflows:
apiVersion: ops.crossplane.io/v1alpha1
kind: CronOperation
metadata:
name: weekly-db-maintenance
spec:
schedule: "0 2 * * 0" # Sundays at 2 AM
operationTemplate:
spec:
pipeline:
- step: upgrade
functionRef:
name: function-database-upgrade
input:
apiVersion: fn.crossplane.io/v1beta1
kind: UpgradeInput
maxDowntime: 5m
We've also introduced WatchOperation for event-driven automation. Want to automatically trigger a backup when someone deploys to production? Or run maintenance tasks when specific resource conditions change? It's all declarative now.
Install Only What You Need
Installing an AWS provider used to mean getting every single AWS resource type, often 100+ CRDs hitting your API server at once. We knew this was a problem, but finding the right solution proved more complex than it initially appeared. Every approach we considered had significant trade-offs.
Crossplane 2.0 introduces ManagedResourceDefinitions (MRDs) and activation policies. We think they're an elegant solution to this longstanding challenge:
apiVersion: apiextensions.crossplane.io/v1alpha1
kind: ManagedResourceActivationPolicy
metadata:
name: aws-essentials
spec:
activate:
- instances.rds.m.aws.crossplane.io
- buckets.s3.m.aws.crossplane.io
- "*.ec2.m.aws.crossplane.io"
This not only reduces API server load but also makes it clear to your team exactly which cloud resources are available in your platform.
The Journey Here
Building Crossplane 2.0 required some difficult decisions. We deprecated features that seemed important at the time but added unnecessary complexity in practice. We redesigned core APIs based on thousands of hours of community feedback. Most importantly, we focused on making Crossplane feel more like native Kubernetes—because that's what platform teams consistently told us they wanted.
The engineering effort was substantial. We refactored core controllers, redesigned the composition engine to handle arbitrary Kubernetes resources, and built entirely new systems for operations and provider management. But more than the code, this release represents a shift in philosophy: Crossplane isn't just about infrastructure anymore. It's about giving platform teams the tools to build comprehensive developer experiences.
Backward Compatibility and Migration
We know many of you are running Crossplane in production with business-critical workloads. Crossplane 2.0 maintains backward compatibility with the vast majority of v1.x configurations. Your existing compositions, providers, and composite resources will continue to work.
For new projects, we recommend starting with v2 patterns immediately. For existing workloads, you can migrate gradually—there's no rush. The v1 APIs aren't going anywhere, and we'll continue supporting them as the community needs.
What's Next
Crossplane 2.0 is just the beginning. We're already working on enhanced observability features, improved composition debugging tools, and even tighter integration with the broader cloud-native ecosystem. The community roadmap includes exciting work on composition testing frameworks and advanced policy integration.
But perhaps most importantly, we're continuing to listen. The best features in Crossplane 2.0 came directly from community feedback, production war stories, and late-night Slack conversations about what wasn't working. Keep that feedback coming.
Try It Today
Crossplane 2.0 is available now. You can get started with our updated quick start guide, and the full feature documentation is live at docs.crossplane.io.
We're curious to see how you use these new capabilities. After seven years of working on this project, there's nothing more satisfying than watching the community take our tools and create things we never imagined. Whether you're building internal platforms at a Fortune 500 company or experimenting with control planes in your homelab, Crossplane 2.0 enables the kind of full-stack self-service APIs that platform teams have been asking for.
Join us in the Crossplane Slack community, star us on GitHub, and tell us what works and what doesn't. There's more work ahead.