# KubePlus turns a Helm chart into a multi tenant Kubernetes API

> KubePlus is a Kubernetes operator that wraps a containerised application packaged as a Helm chart in a custom resource, then provisions an isolated instance per tenant in its own namespace with policies, quotas, RBAC and licence limits. It is aimed at hosting providers and platform teams that need to delegate operations without handing out cluster admin rights.

**cloud-ark/kubeplus** — Kubernetes Operator for delivering SaaS-style, namespace-isolated multi-tenant application instances on Kubernetes

- Repository: https://github.com/cloud-ark/kubeplus
- Website: https://cloudark.io/
- Stars: 753 · Forks: 96
- Language: Go
- License: Apache-2.0
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/cloud-ark-kubeplus

## The problem with giving everyone a namespace

KubePlus is a Kubernetes operator that enables teams to deliver applications as managed, multi-tenant services, and the README states the problem it addresses in plain terms.

Many teams find that simply deploying a Helm chart is not enough when they need to offer the same application to many tenants or customers. Each tenant typically needs a separate instance with its own namespace, controlled access, resource limits and upgrade paths, and building and maintaining that automation, and doing it safely for non-admin users, can require significant engineering effort.

The approach is to convert a Helm chart into a Kubernetes custom API, a CRD, and manage the full lifecycle of each instance. When a user creates an instance of the custom resource, KubePlus creates a dedicated namespace, applies the appropriate policies and quotas, deploys the underlying Helm release, and tracks all the resources owned by that instance.

The README describes the result as staying within the native API machinery, which is the design constraint that makes the delegation story work. The pattern is called multi-instance multi-tenancy, MIMT, and it is the opposite of the shared model where many tenants sit in one application instance. The named adopters are application hosting providers, platform engineering teams, and B2B software vendors that need to host dedicated instances for different tenants and effectively deliver their application as a managed service.

## Isolation and security come from the same mechanism

The first key feature is isolation, and the mechanism is worth being precise about. KubePlus takes an application Helm chart and wraps it in a Kubernetes API, the CRD, and that API is used to provision application instances on a cluster. Each instance is isolated in a separate namespace, and a safety perimeter is added around those namespaces using Kubernetes network policies and non-shared persistent volumes, so that an instance is isolated from the other instances.

The security feature follows from the same place. Because KubePlus creates custom APIs and controls instance provisioning, it lets service providers delegate service operations without granting full cluster admin rights, which makes it practical to run managed services even on customer-owned clusters or shared environments.

The utility that makes this concrete is the provider kubeconfig. A provider can create a provider specific kubeconfig on a cluster to enable application deployments and management, and can then create a consumer specific, further limited kubeconfig, so that the consumer can self-service the provisioning of their own instances.

Two levels of scoped credential is the whole point. A single admin kubeconfig would make the multi-tenancy story decorative, since the isolation of namespaces means little if every tenant can act as a cluster admin.

## Quotas, metrics and licences on the same CRD

The resource utilisation feature is three things stacked on the same operator.

There are controls to set per-namespace resource quotas, and monitoring of CPU, memory, storage and network traffic at the application instance level. The collected metrics are available in different formats and can be pulled into Prometheus for historical usage tracking.

Then there is licensing. KubePlus supports the ability to define licenses for the CRDs, where a license defines the number of application instances that can be created for that CRD along with an expiry date, and KubePlus prevents creation of application instances if the license terms are not met.

That last piece is unusual and worth flagging. A licence with an instance count and an expiry date, enforced by the operator itself, is a commercial control rather than a technical one, and it means the CRD is not just a convenience wrapper. It is the point at which a hosting business can meter what it sells.

The metrics story is the more everyday one for a platform team, and the pull into Prometheus is what makes per instance usage comparable across tenants rather than anecdotal.

## Upgrades happen by editing the CRD spec

The upgrade mechanism is simple, and simple is the point here.

A running application instance can be updated by making changes to the spec properties of the CRD instance and applying it, and KubePlus will update that instance, which means a helm upgrade of the corresponding Helm release.

There is a second path for a new version of the application. A new version can be deployed by updating the application Helm chart under the existing Kubernetes CRD, or by registering the new chart under a new Kubernetes CRD. If the existing CRD object is updated, KubePlus updates all the running application instances, the helm releases, to the new version of the application Helm chart.

The fan-out is the notable part. One change to a chart rolls forward every tenant instance running it, which is exactly what a platform team wants and exactly what makes a bad chart change expensive. There is no per-tenant hold here, and the README does not describe one.

The customisation feature is the mirror image. The spec properties of the CRD wrapping the application Helm chart are the fields defined in the chart's values.yaml file, so deployments can be customised by specifying different values for those spec properties. The chart's own values file is the schema, and it is a schema you already maintain.

## Installing the operator with a scoped provider kubeconfig

The manual installation starts with a cluster, and for testing the README suggests minikube or kind:

```sh
minikube start
```

```sh
kind create cluster
```

The namespace for the KubePlus deployment is then set as an environment variable:

```sh
export KUBEPLUS_NS=default
```

The kubectl plugins are unpacked from the release assets and put on the PATH, and the README gives the sequence of steps as navigating to the releases page, clicking Assets, copying the link address of the kubeplus-kubectl-plugins tarball, downloading it with wget, making a plugins directory, moving the archive into it, extracting it with tar and adding the current directory to PATH.

The provider kubeconfig is then created with the provider-kubeconfig.py utility, which is run from a Python virtual environment with pyyaml and requests installed from the repository's requirements.txt:

```sh
apiserver=`kubectl config view --minify -o jsonpath='{.clusters[0].cluster.server}'`
python3 provider-kubeconfig.py -s $apiserver -x <cluster_name> create $KUBEPLUS_NS
deactivate
```

The operator itself is then installed with a Helm chart, and the README shows the chart URL with the version pinned in the file name, kubeplus-chart-4.2.1.tgz, pulled straight from the operatorcharts repository with a raw=true query parameter.

## What the repository contains beyond the operator

The top level of the repository is broader than a single operator binary, and the directory names describe the surrounding platform.

There is a platform-operator directory, an operator-analysis directory, a mutating-webhook directory, an mcp-server directory, a consumerui directory, plugins, deploy, scripts, tests and examples. The examples are grouped into features, getting-started, graphs, managed-service and multitenancy.

Some of those names carry meaning. An operator-analysis directory suggests tooling for inspecting what the operator is doing to a cluster, which for a multi tenant platform is how you debug a tenant's instance without cluster admin rights. There is also an mcp-server directory, whose purpose the repository does not document here.

There are also documents that signal how seriously the project treats adoption. Operator-FAQ.md, Operator-Maturity-Model.md, Comparison.md, ADOPTERS.md, Guidelines.md, MAINTAINERS.md, a Contributing.md, a code-of-conduct.md and a Vagrantfile for local development.

The maturity model document is the one to read first if you are evaluating this for production, because it is the project's own statement of where it is.

## Where KubePlus is the wrong shape

The main reason not to use KubePlus is that it solves a problem you may not have. If you deploy one application for one audience, the Helm chart is the whole deployment, and a custom resource that creates a namespace per tenant buys nothing.

The second reason is the requirement that the application is containerised and packaged as a Helm chart. A legacy application that is not in that shape cannot be wrapped by this operator without first being made into a chart.

The third is operational weight. You are installing an operator, a CRD scheme, a mutating webhook and a pair of scoped kubeconfigs into a cluster, and the benefit is delegation. If your tenants are internal teams you already trust with a namespace, you are paying for a control plane you do not need yet.

What KubePlus gives you in exchange is genuinely valuable in one situation: customers you do not trust with cluster access, each of whom needs their own isolated instance of the same application, with metering and upgrade paths you control. In that situation the alternatives are to hand out admin rights, which is worse, or to build the same custom resource handling yourself.

The last caution is the version spread. The release history includes a v4.0.0 in November 2024, plugin releases in March 2025 and March 2026, and the install instructions point at a 4.2.1 chart, so the operator and its plugins are versioned separately and you need to keep them matched.

## Conclusion

KubePlus suits a hosting provider or platform team that already packages its application as a Helm chart and now needs to hand out isolated instances to tenants, because it automates namespace creation, policy enforcement, RBAC mapping and the upgrade path inside the Kubernetes API. It is the wrong tool for a single shared deployment, where the overhead of a custom resource per instance buys nothing, and it is the wrong tool if the application is not containerised or not Helm packaged. Before adopting it, install it against a kind or minikube cluster, run the provider kubeconfig utility as documented, and check the Operator-Maturity-Model document in the repository to see where the operator currently sits.

## FAQ

### What is KubePlus and what problem does it solve?

KubePlus is a Kubernetes operator that converts an application packaged as a Helm chart into a custom API, then provisions an isolated instance per tenant in its own namespace, applying network policies, resource quotas and RBAC, and managing the Helm release lifecycle. It is aimed at hosting providers and platform teams that need multi tenant instances without granting cluster admin rights.

### How do I install KubePlus?

Create a minikube or kind cluster for testing, set KUBEPLUS_NS for the namespace, unzip the kubeplus-kubectl-plugins archive from the releases page onto your PATH, create a provider kubeconfig with the provider-kubeconfig.py utility in a Python virtual environment, and then install the operator with the Helm chart.

### Can KubePlus limit how many application instances a tenant creates?

Yes. KubePlus supports defining licenses for the CRDs, where a license defines the number of application instances that can be created for that CRD and an expiry date, and KubePlus prevents creation of application instances when the license terms are not met.

## Sources

- [cloud-ark/kubeplus on GitHub](https://github.com/cloud-ark/kubeplus)
- [License: Apache-2.0](https://github.com/cloud-ark/kubeplus/blob/master/LICENSE)
- [Project website](https://cloudark.io/)
- [README](https://github.com/cloud-ark/kubeplus/blob/master/README.md)
- [Releases](https://github.com/cloud-ark/kubeplus/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/cloud-ark-kubeplus