# Loft: virtual clusters and a sleep mode that scales the bill down

> Loft is a Kubernetes platform built around virtual clusters, lightweight clusters that run inside a namespace on a host cluster, with projects and spaces above them for organisation and access control. The feature that catches the eye is sleep mode, which scales replica-controlled resources to zero and is advertised as cutting cloud costs by up to seventy percent.

**loft-sh/loft** — Namespace & Virtual Cluster Manager for Kubernetes - Lightweight Virtual Clusters, Self-Service Provisioning for Engineers and 70% Cost Savings with Sleep Mode

- Repository: https://github.com/loft-sh/loft
- Website: https://loft.sh/docs/introduction
- Stars: 850 · Forks: 82
- Language: Go
- License: NOASSERTION
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/loft-sh-loft

## What the platform is

Loft describes itself as a Kubernetes platform for managing virtual clusters, multi-tenancy and cluster sharing, offering a single pane of glass for connecting clusters, deploying virtual clusters, configuring user access and reducing operational costs. Built on Kubernetes, it lets teams share cluster resources while keeping isolation and self-service capabilities. The repository itself is small in listing terms, with an api directory, a chart directory for the Helm chart, a hack directory for developer scripts, an appstore directory, a change log configuration and the README. The project is Go, the default branch is master, and the licence field carries a custom classification GitHub cannot label, which is consistent with a product that also ships a commercial licence key.

## The hierarchy: projects, clusters, spaces, virtual clusters, apps

The feature list is the taxonomy and it is worth walking in order. Projects are the highest organisational unit, logically grouping resources by team or division, with role-based access controls. Clusters connect to and manage multiple physical Kubernetes clusters, deploying spaces, virtual clusters and apps as needed. Virtual clusters are the core idea: lightweight virtual Kubernetes clusters that run inside a namespace within the host physical cluster, described as ideal for development, testing and production workloads. Apps are defined and deployed with configurable parameters across clusters, spaces and virtual clusters, using Kubernetes manifests, bash scripts, Helm charts and more. That last point is the difference between a platform and a cluster manager, because the application definition is a first-class object rather than something you apply by hand.

## Sleep mode, auto delete and inactivity detection

The cost reduction tools are the part with the clearest business case. Sleep mode puts Kubernetes namespaces to sleep by setting replicas to zero for all replica-controlled resources, which the README says reduces cloud costs by up to seventy percent. Auto delete configures automatic deletion for inactive virtual clusters, and inactivity detection automatically detects and responds to namespace inactivity. The distinction between the three is worth being precise about, because they have very different consequences. Scaling to zero is reversible, since the namespace still exists and can be woken, whereas deletion is not, so an auto-delete policy is a data retention decision as much as a cost decision. And inactivity detection is the trigger, which means the detection window has to be longer than any realistic working session or you will delete an environment somebody was still using.

## Multi-tenancy and GitOps

Multi-tenancy is provided through granular RBAC at project, space and virtual cluster levels, which is the mechanism that makes delegation to engineers workable, since each level can carry its own access rules. The GitOps story is that all resources are defined as Custom Resource Definitions, so the platform's own objects can be committed to a repository and reconciled rather than applied by hand. There is also a RESTful API described as comprehensive and OpenAPI 3.0 compliant for programmatic access and automation, and an api directory at the repository root is where that contract lives. The combination of CRDs and a documented API is what would let an organisation treat Loft itself as a managed artefact rather than as something installed once and forgotten.

## Installing it with the vCluster CLI

The prerequisites are a Kubernetes cluster at version 1.20 or later with administrator access, Helm 3.10 or later, and kubectl. A LoftLabs licence key is also required, obtained from sales. The recommended installation path is the vCluster CLI, and the README gives the commands.

```bash
# Download and install vCluster CLI
# macOS (Intel/AMD)
curl -L -o vcluster "https://github.com/loft-sh/vcluster/releases/latest/download/vcluster-darwin-amd64" && \
  sudo install -c -m 0755 vcluster /usr/local/bin && rm -f vcluster

# Verify installation
vcluster --version

# Deploy the platform
vcluster platform start
```

The CLI opens the UI in a browser and logs you in, and you are prompted to create an administrator user at that point. The Helm route exists as well, using the chart repository at charts.loft.sh, and there is a third option for GitOps deployments through ArgoCD. The difference between the options is where the configuration lives rather than what gets installed.

## Ports, egress and the licence phone home

The resource requirements section is unusually specific, and it is the part to check before you install. The pod requests memory of 256Mi and cpu of 200m, with limits of 4Gi and 2 cpu. Four ports must be open: 8443 for the API service extension for cluster communication, 9443 for webhook validation and enforcement, 9444 for the management API for platform administration, and 9090 as a Prometheus metrics proxy for cost monitoring. Then there is the egress requirement, which allows egress to admin.loft.sh on port 443 over HTTPS for licence retrieval and validation. That last item is the one to raise with a security team before deploying, because it means the control plane talks home, and the licence check is what makes that traffic necessary.

## Reaching the platform and the default credentials

There are three documented ways in. The Loft Router is the default, and if loftHost is not configured a random domain is provisioned, which you retrieve from a secret.

```bash
kubectl get secret loft-router-domain \
  -n vcluster-platform \
  -o jsonpath="{.data.domain}" | base64 --decode
```

If you configured an ingress you use your own domain, and for local access there is a port forward.

```bash
kubectl port-forward -n vcluster-platform svc/vcluster-platform 8080:80
```

The credentials section is where the security note lives. If you do not set them in your values file, the defaults are the username admin and the password my-password, and the README marks it as strongly recommended to change these default credentials immediately after first login. Given that the platform's whole purpose is granting teams self-service access to shared infrastructure, leaving a published default password in place is the kind of detail that turns a convenience into an incident.

## Conclusion

Use Loft when you want engineers to self-service isolated Kubernetes environments on shared infrastructure, because the virtual cluster model plus projects and spaces is what makes that safe to delegate. Do not treat it as a free replacement for dedicated clusters, since the platform requires a LoftLabs licence key and reaches out to admin.loft.sh for licence retrieval and validation. Verify first which version you deploy, since a 5.0.0 alpha and a 4.12.4 release candidate were both published on the same day in October 2026, that you change the default admin credentials before anyone reaches the interface, and that the ports and egress rules in the prerequisites are open in your cluster.

## FAQ

### What is Loft?

It is a Kubernetes platform for managing virtual clusters, multi-tenancy and cluster sharing, letting teams connect clusters, deploy virtual clusters, configure user access and reduce operational costs, with a single interface across them.

### What does Loft sleep mode do?

It puts Kubernetes namespaces to sleep by setting replicas to zero for all replica-controlled resources, which the README says reduces cloud costs by up to 70 percent. Auto delete and inactivity detection handle inactive virtual clusters as well.

### What do I need to install Loft?

A Kubernetes cluster at version 1.20 or later with administrator access, Helm 3.10 or later, kubectl, and a LoftLabs licence key. Four ports must be open, 8443, 9443, 9444 and 9090, and egress to admin.loft.sh on port 443 is allowed for licence retrieval and validation.

### How do I install Loft with the vCluster CLI?

Download the vcluster binary for your platform, install it, then run vcluster platform start. The CLI opens the UI in your browser, logs you in and prompts you to create an administrator user. Helm and ArgoCD installation routes are also documented.

### How does Loft handle access control and GitOps?

Access control is granular RBAC at project, space and virtual cluster levels, with projects as the highest organisational unit grouping resources by team. For GitOps, all resources are defined as Custom Resource Definitions, and the platform exposes an OpenAPI 3.0 compliant REST API for automation.

## Sources

- [Issues](https://github.com/loft-sh/loft/issues)
- [loft-sh/loft on GitHub](https://github.com/loft-sh/loft)
- [Project website](https://loft.sh/docs/introduction)
- [README](https://github.com/loft-sh/loft/blob/master/README.md)
- [Releases](https://github.com/loft-sh/loft/releases)

---

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