kcp-dev/kcp: Kubernetes-like control planes for many isolated tenants

What kcp solves that namespaces do not

A Kubernetes cluster gives you one API server, one set of CRDs, and namespaces as the isolation unit. Namespaces are names, not boundaries. Every tenant shares the same CRD definitions, the same API surface, and the same cluster-scoped objects. kcp takes a different position: the isolation unit is the workspace, and each workspace behaves like its own cluster with its own API surface. The README describes the project as a control plane for many independent, isolated clusters known as workspaces, and says it exists so that API service providers can offer APIs centrally using multi-tenant operators while users consume those APIs inside their own workspaces.

The audience is narrow and specific. The README names SaaS service providers who need a massively multi-tenant platform, cloud providers, and enterprise IT departments offering APIs internally. If you run one cluster for one product team, kcp is not aimed at you. If you run a platform where hundreds or thousands of tenants each need their own API objects, their own RBAC, and their own CRDs, that is the case the project was built for.

Workspaces, workspace types, and where the API servers live

The mechanism is a hierarchy of workspaces served by one kcp process. The README points readers at the Concepts and Tenancy Guide for workspaces, workspace types and APIs, and the repository layout backs that up: the code lives under pkg/, cmd/ and staging/, with staging holding the kcp-dev modules that go.mod pulls in, including kcp-dev/apimachinery, kcp-dev/client-go, kcp-dev/logicalcluster, kcp-dev/sdk and kcp-dev/virtual-workspace-framework. The logicalcluster module is the naming hint: a workspace is addressed as a logical cluster, which is why clients need kcp-aware machinery rather than plain client-go.

Two consequences follow from that design. First, the API surface is not fixed. Workspace types let a platform team decide what a given class of tenant is allowed to create, so a tenant can bind CRDs into its own workspace without affecting anyone else. This is the part that ordinary namespaces cannot do, and it is the reason the project exists. Second, the control plane is decoupled from workloads. The README is explicit that in May 2023 the project was restructured and the components related to workload scheduling, including the syncer, plus the transparent multi cluster code, were removed because of a lack of interest and maintainers, with the pre-removal code preserved on the main-pre-tmc-removal branch. Anyone who remembers kcp as a way to spread workloads across clusters is working from an older description. Today it is an API and tenancy layer, and the README does not document a supported path for pushing objects down into a workload cluster.

Installing kcp and reading the workspace tree

The README gives two routes. Users are pointed at the Setup and Quick Start guide at docs.kcp.io for downloading and running kcp. Developers build from source with Go. The go.mod file states a minimum supported Go version of 1.26.0 and a build version of 1.26.4, and the Dockerfile builder stage uses the golang:1.26.4 image, so the two are kept aligned deliberately. The repository also ships hack/verify-go-versions.sh, which the go.mod comment says checks that every version reference across the codebase matches the maintained versions.

The from-source path in the README is two commands. The first starts the control plane:

go run ./cmd/kcp start

That runs the kcp binary from the repository. The README then shows a second terminal where you point kubectl at the admin kubeconfig that the process writes and list workspaces:

export KUBECONFIG=.kcp/admin.kubeconfig && kubectl get workspaces

What you should see is a list of workspace objects from the kcp API server, not from a Kubernetes cluster you already had. That distinction matters: the admin kubeconfig is kcp's own, and the workspaces it returns are the tenancy tree the rest of your setup will hang from. The README also documents a container build path. The Dockerfile is a multi-stage build with a builder stage based on golang:1.26.4 and an ARG goproxy that defaults to https://proxy.golang.org, which the file says can be overridden with --build-arg goproxy=$(go env GOPROXY).

One practical note the README does not cover: nothing in the repository documentation describes how to upgrade an existing kcp installation from one release to the next. There are three recent releases listed, v0.33.1 and v0.32.5 both dated 2026-09-22 and v0.33.0 dated 2026-09-15, and the repository keeps two release lines alive at once, but the README itself does not document a migration procedure. Treat the release notes as the source, and expect to read them before moving a running installation.

Where kcp is the wrong tool

The removal of the syncer and the transparent multi cluster code is the largest limitation, and it is stated plainly in the README rather than buried. If your requirement is to run a control plane in one place and have workloads land in several Kubernetes clusters, kcp no longer does that, and the branch name main-pre-tmc-removal is where that behaviour now lives. Choosing kcp for workload placement means either adopting a separate tool for the placement half or maintaining code from a branch the project set aside.

The second limitation is client compatibility. Because workspaces are logical clusters, tooling that assumes a single cluster and a single API surface will not work unchanged. The go.mod dependency on kcp-dev/client-go and kcp-dev/apimachinery is the evidence: clients need kcp-aware libraries, and the README's own example is a kubectl invocation rather than a generic client program. If your organisation has a large body of controllers written against upstream client-go, budget for the port.

The third is operational weight. kcp is a control plane with its own API server, its own storage layer (the go.mod file pulls in kcp-dev/embeddedetcd and the etcd v3 client packages), and its own release cadence. Running it is closer to running a small Kubernetes distribution than to installing a library. Teams without someone who can own an API server should think hard before adopting it.

kcp against vcluster and Crossplane

The two comparisons people actually search for are vcluster and Crossplane, and the difference is architectural rather than cosmetic. vcluster takes a Kubernetes cluster and runs a virtual control plane inside a namespace of a host cluster, so each virtual cluster is backed by the host's nodes and storage; the isolation is real but the workload plane is shared with the host. kcp removes the workload plane from the picture entirely. There is no host cluster whose nodes the workspaces sit on, which is why kcp can address a much larger number of tenants and why it cannot place a pod for you.

Crossplane is a different axis. It is a way to model external infrastructure as Kubernetes resources and reconcile them, and the README links a ContainerDays 2025 talk titled Next Generation of Platform Engineering Using kcp and Crossplane, which is the clearest signal in the repository that the two are meant to be combined rather than substituted. Crossplane gives you the resource model and the reconciliation; kcp gives you the tenancy and the per-tenant API surface. Picking between them is a category error. Picking between kcp and vcluster is a real decision, and it comes down to whether your tenants need their own API surface with no shared node pool, or their own cluster on shared nodes.

Licence, maintenance, and what adoption costs

kcp is licensed under Apache-2.0, and the README carries a FOSSA badge pointing at the project's dependency report, which is the place to look if your organisation reviews transitive licences. Apache-2.0 is permissive and includes an explicit patent grant; the repository also contains a DCO file, so contributions are made under a Developer Certificate of Origin rather than a CLA. That combination is friendly to commercial adoption. It is not legal advice, and the FOSSA report is the artefact to hand to whoever reviews licences.

On maintenance, the facts are concrete: the repository is not archived, and the last push was on 2026-09-23. Releases v0.33.1 and v0.32.5 both landed on 2026-09-22, with v0.33.0 on 2026-09-15. The project maintains two Go versions, a minimum and a build version, and enforces the match with a script. It also maintains two release lines, v0.33 and v0.32, in parallel. That is a real cost you inherit: you are tracking a project that expects you to pick a line and follow it, and the README does not tell you how to move between lines. The upgrade cost is the reading, not the command.

Editorial conclusion

Adopt kcp if you are building a multi-tenant API layer and can accept that it is a control plane only: the README states that the syncer and transparent multi cluster code were removed in May 2023, so anything that needs to place pods on your own clusters is out of scope. Skip it if you want a drop-in replacement for a single Kubernetes cluster, or if you need a documented upgrade path, because the README does not describe one. Before committing, run the quickstart and inspect the workspace tree your own tenant model would produce, then read the release notes for v0.33.0 and v0.33.1 to see what changed between the two patch releases. The project's own concepts guide at docs.kcp.io is the authority on workspace types, not this page.

Frequently asked questions

Official sources

1. kcp-dev/kcp on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases