# vind: a KinD-shaped Kubernetes cluster that can sleep and be snapshotted

> vind runs Kubernetes clusters as Docker containers by putting vCluster's Private Nodes mode behind the Docker driver, which buys pause and resume, a web UI, automatic LoadBalancers, snapshots to OCI registries and in-place upgrades, at the cost of a different engine underneath than KinD uses.

**loft-sh/vind** — vCluster in Docker (vind) is KinD (Kubernetes in Docker) alternative with additional features. For source code, see loft-sh/vcluster repo linked below.

- Repository: https://github.com/loft-sh/vind
- Website: https://github.com/loft-sh/vcluster
- Stars: 1,019 · Forks: 110
- Language: Unknown
- License: NOASSERTION
- Published: 2026-10-19 · Updated: 2026-10-19 · Language: en
- Canonical page: https://hysenlabs.com/projects/loft-sh-vind

## KinD's ergonomics on top of vCluster's engine

vind is described as an open-source way to run Kubernetes clusters directly as Docker containers, built on top of vCluster, combining the power of virtual Kubernetes clusters with the simplicity of Docker to create isolated Kubernetes environments for development, testing and CI/CD pipelines. The repository is thin by design. The top level holds docs/, examples/, CONTRIBUTING.md, LICENSE and the README, and the description points out that for source code you should look at the loft-sh/vcluster repository, which is the real implementation. So vind is a driver, a mode and a documentation set rather than a new engine, and the vCluster CLI is the interface. The project presents itself as a KinD alternative with additional features, and the comparison table at the end of the README is where the differences are laid out plainly. The licence situation has a wrinkle worth flagging: the README badge links to a LICENSE file and shows Apache 2.0, while the repository metadata classifies the licence as a custom one GitHub cannot categorise, so the file itself is the authoritative text.

## Private Nodes mode is the mechanism, and it is not optional

The single most important technical note in the README is short and often skipped. It says vind uses vCluster's Private Nodes mode internally, that this is automatically enabled when using the Docker driver, that it is required for proper operation, and that this is expected behaviour and not a configuration issue. The reason this matters is that it tells you what vind actually is. In vind, the cluster is a virtual Kubernetes cluster, a lightweight control plane running inside the container, which is why it can be paused, snapshotted and upgraded without touching the host's Kubernetes. The private nodes mode is the arrangement in which the virtual control plane manages node containers of its own rather than assuming it is talking to a real kubelet. If you are evaluating vind against KinD, this is the architectural difference that produces all the others, and the README is upfront that you cannot turn it off.

## The quick start is three commands and a check

The prerequisites are a Docker installation that is running and a vCluster CLI of v0.34.0 or later. The installation is then two CLI commands, because vind is a driver inside the vCluster CLI rather than a separate binary:

```bash
# Upgrade vCluster CLI to the latest version
vcluster upgrade --version v0.34.0

# Set Docker as the default driver
vcluster use driver docker
```

If you want the web interface, the platform is started separately with `vcluster platform start`, and the README is emphatic about the ordering: start the platform before creating clusters, because clusters created before the platform is started are not automatically synced to the UI, and only clusters created after `vcluster platform start` appear in the dashboard. That is a small trap but a real one, since the natural sequence is to create a cluster and then go looking for it in the UI. Creating the cluster is then a single command, and the verification is done with the ordinary Kubernetes client:

```bash
vcluster create my-cluster

kubectl get nodes
kubectl get namespaces
```

You should see the node and its namespaces, and the fact that kubectl is the verification tool is a hint about the shape of the thing, since a virtual cluster has its own API server and its own context.

## Sleep, resume, and the platform that has to be started first

The feature that distinguishes vind most sharply from KinD is pause and resume. The README lists sleep and wake as pausing clusters to save resources and resuming them instantly, with the claim that a cluster resumes in under three seconds, and the pairing is a single command each:

```bash
vcluster pause my-cluster
vcluster resume my-cluster
```

That capability only makes sense given the virtual control plane design, because what is being paused is a container rather than a set of processes spread across a machine. The second distinguishing feature is the built-in interface, the vCluster Platform UI, which the project describes as a free web UI for cluster management and which the comparison table marks as built-in for vind against command-line only for KinD. The third is automatic LoadBalancers, with LoadBalancer services working out of the box and enabled by default, where the table puts manual setup required for KinD. The fourth is the pull-through cache, which uses the local Docker daemon's image cache to speed up pulls and reduce bandwidth, again enabled by default, against direct registry pulls. The remaining rows in the table cover external nodes, CNI and CSI choice, snapshots and Kubernetes upgrades.

## Snapshots, hybrid nodes and upgrades that do not delete the cluster

Three features reach beyond the local development use case, and the snapshot one is the most interesting. A snapshot writes the entire cluster state to an OCI registry, an S3 bucket or a local file, and can then be restored on any vind cluster, which the README frames as the way to share reproducible environments or to safeguard a demo setup. The destinations are given as URI schemes, and the commands are the same shape as the create command:

```bash
# Snapshot to an OCI registry
vcluster snapshot create my-cluster oci://ghcr.io/my-user/my-repo:my-tag

# Snapshot to a local file inside the cluster container
vcluster snapshot create my-cluster container:///data/my-snapshot.tar.gz

# Restore from an OCI registry
vcluster restore my-cluster oci://ghcr.io/my-user/my-repo:my-tag
```

The table notes that snapshots need vCluster 0.34 or later, which is also why the CLI version floor is stated up front. Joining external nodes is the other feature that extends the scope, since it lets you connect real cloud instances such as EC2, GCP or Azure as nodes to a local cluster through a built-in Tailscale VPN, and the table contrasts that with KinD's local-only limit. The last row of the comparison is the in-place Kubernetes upgrade, where vind upgrades the version without deleting the cluster against KinD's delete and recreate. The trade for all of this is that you are running a virtual control plane rather than a bare node, which is a different operational model from KinD even when the commands look similar.

## Configuration, examples and where the documentation lives

The configuration is YAML and the README shows the shape, with the Docker-specific options under an experimental.docker key. The example sets a custom network, lists additional nodes where only a name is required, and shows environment variables per node, port mappings, volumes and extra Docker arguments such as a capability addition:

```yaml
experimental:
  docker:
    network: "my-custom-network"
    nodes:
      - name: worker-1
        env:
          - "CUSTOM_VAR=value"
    ports:
      - "8080:80"
    volumes:
      - "/host/path:/container/path"
    args:
      - "--cap-add=SYS_ADMIN"
```

The examples directory is a better guide to what the tool can do than the configuration reference is. It holds a basic cluster setup, a multi-node cluster in two forms, a cluster with a custom CNI, load balancer services, node affinity, pod anti-affinity and topology spread, a snapshot and restore walkthrough, and an external node joining guide, plus a README of its own. The documentation set in docs/ covers the same ground in prose, with a getting started guide, a configuration guide, an advanced features document, the vind versus KinD comparison, and a troubleshooting page. That last one matters more than it usually would, because the project asks you not to treat the private nodes mode as a configuration issue, which means the troubleshooting is where a surprising behaviour gets explained.

## Where vind is the wrong tool

Three boundaries are worth being clear about. The first is that vind is not KinD with extras bolted on, it is vCluster with a different driver, and if your requirement is specifically KinD's node-in-a-container model with a plain control plane, you are looking at a different tool. The second is the maturity of the surrounding pieces. The README marks the Docker-specific configuration as experimental, and the private nodes mode is described as the mode vind uses internally rather than a mode you choose, so the Docker path is the young part of a project whose other paths are more settled. Snapshots also need vCluster 0.34 or later, which pins your CLI version. The third is what a virtual cluster means for the workloads you run. A virtual cluster with its own control plane is a different isolation model, and if you need a cluster that behaves like a small production cluster with real nodes, adding external cloud instances over a VPN is a step up in complexity that the development case does not justify. For local development and CI where you want a disposable cluster that can be paused between runs and snapshotted for reproducibility, vind is a good fit, and the platform UI plus the pause command are the two things that make it pleasant.

## Conclusion

Adopt vind if you want a local Kubernetes cluster for development or CI that you can pause, snapshot to an OCI registry, and upgrade in place, and you already run Docker. Do not adopt it if you specifically want KinD's node-in-a-container model without an extra control plane layer, because vind is vCluster with the Docker driver rather than a fork of KinD. Before you start, upgrade the vCluster CLI to v0.34.0 or later, set the Docker driver with `vcluster use driver docker`, and start the platform UI before creating any cluster, since clusters created earlier are not synced to the dashboard.

## FAQ

### What is vind and how does it relate to vCluster and KinD?

vind is an open-source way to run Kubernetes clusters directly as Docker containers, built on top of vCluster, and it is presented as a KinD alternative with additional features. The source code lives in the loft-sh/vcluster repository, and the vCluster CLI is the interface you drive it with.

### What do I need to install to use vind?

Docker installed and running, and the vCluster CLI at v0.34.0 or later. You then run `vcluster upgrade --version v0.34.0` and `vcluster use driver docker` to set Docker as the default driver, and `vcluster create my-cluster` to create a cluster.

### Why does vind use vCluster's Private Nodes mode?

The README states that vind uses Private Nodes mode internally, that it is automatically enabled with the Docker driver and required for proper operation, and that this is expected behaviour rather than a configuration issue.

### Can I snapshot a vind cluster?

Yes, with vCluster 0.34 or later. The cluster state can be saved to an OCI registry, an S3 bucket or a local file, using commands such as `vcluster snapshot create my-cluster oci://ghcr.io/my-user/my-repo:my-tag`, and restored with `vcluster restore`.

### What licence is vind released under?

The README badge points at a LICENSE file and shows Apache 2.0, while the repository metadata classifies the licence as a custom one GitHub cannot categorise, so the file is the authoritative text. The last push to the repository was on 2026-06-04 and it publishes no GitHub releases.

## Sources

- [Issues](https://github.com/loft-sh/vind/issues)
- [loft-sh/vind on GitHub](https://github.com/loft-sh/vind)
- [Project website](https://github.com/loft-sh/vcluster)
- [README](https://github.com/loft-sh/vind/blob/main/README.md)

---

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