Kubernetes Cluster (K3s) Playground
A multi-node K3s cluster with a load balancer, Helm, and more.

About This Playground
Want to try a kubectl command, deploy a Helm chart, or troubleshoot a Kubernetes workload without turning your laptop into a small data center?
iximiuz Labs' K3s playground gives you a ready-to-use, multi-node Kubernetes cluster running on four Linux servers: a dedicated development machine, one control-plane node, and two worker nodes. The cluster starts in seconds and comes with kubectl, Helm, a load balancer, and other useful tools pre-installed.
This is not a simulated or single-container Kubernetes environment. Every node is a lightweight but fully fledged VM running on iximiuz Labs' bare-metal infrastructure. The machines have their own kernels and communicate over a private network, making the setup much closer to a real Kubernetes cluster than solutions based on Docker-in-Docker or several containers pretending to be nodes.
Use the K3s playground for learning Kubernetes, experimenting with Helm charts and operators, testing multi-node workloads, debugging deployments, and running short-lived development or demo environments. Practice scheduling, service discovery, persistent storage, ingress, rolling updates, node failures, and all the other things that are difficult—or simply annoying—to reproduce locally.
K3s is a lightweight Kubernetes distribution, but it exposes the same familiar Kubernetes API and core abstractions. Most applications, manifests, Helm charts, controllers, and troubleshooting techniques work exactly as they would in a larger cluster.
iximiuz Labs playgrounds are not intended for production workloads or services that must stay online indefinitely. Playground sessions have a time limit, public URLs should not be treated as production endpoints, and disposable environments are the wrong home for irreplaceable data.
For everything else, start the cluster and get your hands dirty. The fastest way to understand Kubernetes is to deploy workloads, inspect what the control plane did, break a few things, and learn how to put them back together.
Happy hacking!
A real VM, not a container
Get root on a VM with its own kernel, so Docker, Kubernetes, and systemd just work.
Read the docs →
SSH from browser or CLI
Use the built-in web terminal, or connect with labctl ssh, plain ssh, scp, or rsync.
Read the docs →
Drive it with AI
Let Claude, Codex, or any MCP client start this playground and run commands in it.
Read the docs →
Expose HTTP(S) ports
Give any web app running inside the VM a public URL - for yourself or to share with others.
Read the docs →
Share terminals
Invite others into your terminal session, or open it yourself from another device.
Read the docs →
Customize with init scripts
Add shell scripts that run at boot to install packages, clone repos, or seed test data.
Read the docs →
Private networking
VMs reach the internet via NAT with no public IP; several VMs share bridge networks.
Read the docs →
Ephemeral or persistent
By default, VMs are destroyed when the session ends; enable persistence to keep the disks for next time.
Read the docs →
Built-in container registry
A private registry.iximiuz.com for every playground to share images across services and VMs.
Read the docs →