Version 2.4 makes Kubernetes the front door for infrastructure
Crossplane 2.4 lets a platform team publish its own Kubernetes resource types for infrastructure and applications. A developer can create an App, database, or storage object with a small schema, while a composition tells Crossplane which lower-level resources to create. Providers add Kubernetes APIs for external services and continuously compare desired state with what those services report. The attraction is a stable internal API that can hide account details, provider choices, and repeated configuration from its users.
The version 2.4 composition guide demonstrates one App resource producing a Deployment and a Service. Composition functions can express that work with templated YAML, ordinary YAML, CEL, Python, or KCL. That range gives platform authors choices, although it also creates standards work: someone must choose a function model, review packages, publish schemas, and support upgrades. The README's promise of building control planes without writing code is credible for simple cases; larger functions may still be software projects.
What happened when we ran it
Our commit c2a893f checkout installed 576 packages in 90 seconds inside a fresh Debian container with 3 CPUs and 8 GB of RAM. The source tree contained 948 files, about 111,170 lines, and used 22.7 MB before dependencies. Installation completed, and the build succeeded in 138 seconds. That result covers the Go repository in the stated sandbox. It does not cover a Helm installation, provider startup, cloud authentication, or reconciliation against a live external API.
The tests ran for 89 seconds and exited with code 1. The summary reported 86 passed and 3 failed out of 89. Its last lines show several internal packages passing, then github.com/crossplane/crossplane/v2/test/e2e failing after 13.880 seconds, followed by the overall FAIL. The supplied tail does not name the three individual failures or their causes, so we cannot attribute them to permissions, networking, missing services, or Crossplane itself. The complete command did not pass in our sandbox.
A live install needs Kubernetes, Helm 3.2, and cloud credentials
The 2.4 installation guide requires an actively supported Kubernetes release and Helm 3.2.0 or later. Helm creates the crossplane-system namespace and installs the core and RBAC manager pods. The composition quickstart asks for at least 2 GB of cluster memory. A useful installation then adds provider and function packages, so the operational footprint depends on the APIs and composition languages selected rather than the core chart alone. A local Kind cluster is suitable for learning, not proof of production capacity.
Providers make calls to external APIs, which means their credentials and permissions become part of the control plane's security boundary. Crossplane obtains provider packages only from container registries; offline sites need a local registry, and private registries use Kubernetes pull secrets in the Crossplane namespace. Version 2.4 can scale safe-start providers to zero until a managed resource definition is active. That saves idle pods, but operators still own registry access, credential rotation, RBAC, package health, and recovery when reconciliation stops.
Version 2 keeps old resources running but does not migrate their scope
The version 2 upgrade guide says existing version 1 resources can continue in legacy cluster-scoped form. There is no automated tool that converts those resources to the newer namespaced style. Upgrades must begin from v1.20 and move one minor version at a time. Native patch-and-transform composition, ControllerConfig, external secret stores, composite-resource connection details, and the default registry flag are removed, so clusters using them need preparation before the core chart is upgraded.
Crossplane v1.20 reaches end of life in November 2026, according to the current release table. The project supplies an upgrade checker in the v1.20 CLI and conversion commands for two removed APIs. That is better than a vague migration note, though it does not remove the change work. Existing live compositions also need restraint: the guide warns that changing an in-use composition to namespaced provider APIs can disrupt or replace resources, and recommends using the new form for new resources.
Release 2.4 restarts package pods and moves the CLI
Version 2.4 derives package revision names from both digest and metadata generation. On the first reconcile after upgrade, every installed package receives a new revision and its provider or function pods restart. Runtime objects now use server-side apply, which preserves additions Crossplane does not declare while removing fields deleted from a runtime configuration. Teams should stage this release with workload owners because the package restart is expected behavior, even when the core upgrade itself is healthy.
The 2.4 CLI moved from releases.crossplane.io to cli.crossplane.io and changed its binary name from crank to crossplane. The core and CLI version numbers now follow separate schedules. A metric label also changed from ComposedResource to Dependency. These are manageable edits, but they reach installation scripts, firewall allowlists, dashboards, and alerts. The supplied install script already uses the new location; private automation copied from older releases may not.
Two open package bugs can block strict registry policies
Issue 7813 reproduces a dependency collision on Crossplane 2.4.0 when two packages from a private GitLab registry share a long path prefix. Generated Function or Provider names are truncated, leaving only one dependency object and preventing resolution. Issue 7458 covers another policy-sensitive case: provider-family dependencies referenced by SHA-256 digest were not recognized as satisfying a version dependency on 2.3.1. Both issues were open on September 4, 2026, so test your real registry paths and pinning scheme before standardizing them.
GitHub showed 119 open issues and 75 open pull requests on September 4, 2026. The repository had 12,024 stars, 8 CI workflow files, and a push that same day; v2.4.0 had shipped on August 20. That is active maintenance around a large project, and the 194 combined items should not be read as 194 bugs. Crossplane earns a controlled platform trial, with the failed e2e run, provider permissions, and package-upgrade behavior included in the acceptance checks.