Let's call it what it is: an early tech preview. It is rough, and not meant for production. It exists so you can see that 2.0 is real and already running, and so you can tell us what you would like while the architecture is still soft enough to change.
We rewrote Rancher Desktop because the old design made every new feature take more effort than the one before it. The history post tells that story; the short version is one backend instead of two, the engine lifted out of the GUI, and a different guest OS underneath. 2.0 is that idea, built.
At the center is a new background program called rdd, the Rancher Desktop Daemon. rdd does the real work. It runs the virtual machine, using Lima on every platform now, Windows included. It starts your container engine and your Kubernetes cluster. It exposes all of that through an API, and not a custom one: rdd speaks the Kubernetes API. Your kubectl and the usual client libraries can drive it directly, no new SDK to learn. The desktop app is just one more client, with no special privileges, talking to rdd the way any other tool would.
Because the work lives in rdd instead of inside a window, you can run the whole thing without ever opening the GUI. And rdd is one self-contained executable: no installer, no separate daemon and command-line tool, just one file that is both the backend and the way you drive it. Download it, start it from the command line, and you have a container engine and a cluster: on a headless server, on a CI runner, or in your own terminal. Deploying it is copying one file. Rancher Desktop never had a way to do this. The engine lived inside the app, and the app had to be on screen.
The guest VM runs openSUSE Leap now instead of Alpine. The reason is glibc: much of the GPU and AI tooling people ask for needs it, and Alpine's musl does not provide it. GPU support is not built yet, but the guest OS no longer rules it out.
We could have kept this private until it looked polished. We would rather not. Putting it out now, rough edges and all, does two things for us.
It shows that "we will do that in 2.0" means a workstream already running, not a promise about some distant year. And it puts the design in front of you early, when your feedback still counts. If your setup depends on something specific, this is the moment to say so, before we lock in decisions we made without you.
This is a working preview, not a finished product. What runs right now:
So you are not caught off guard:
You do not have to choose. 2.0 installs next to Rancher Desktop, and the two ignore each other completely: separate package, separate data, separate everything. Install them in either order, remove them in either order, nothing gets tangled. You can even run both at once, though I would not recommend it. Two container engines and two clusters on one laptop gets confusing quickly.
The full app, GUI plus bundled tools, comes from the GitHub releases page for Windows and macOS (Intel and Apple silicon), and from our RPM and DEB repositories and AppImages on Linux. The same places you would reach for Rancher Desktop 1. If all you want is the daemon, download the single rdd binary for your platform and you are two commands away from a running container.
A real installation and usage walkthrough is a separate post in this series.
This is alpha software. Things will break, especially in corners we have never tested on a machine configured like yours. When they do, tell us. That feedback is a big part of why we are shipping this early.
There are no docs for 2.0 yet. There is this blog. As the work moves, we will write about how the pieces fit and what becomes newly possible: the daemon and its API, networking, snapshots, the AI story, whatever we're working on that month. To find out when the next preview drops, subscribe to the feed.
Curious, and feeling adventurous? Give it a try. Cautious? Follow along, and jump in when it looks ready for you.
]]>2.0 installs beside Rancher Desktop without touching it: separate package, separate data, nothing shared. Install or remove them in any order. (The welcome post covers what 2.0 is and how it differs; this one is about getting it running.)
The full app, the GUI plus a set of bundled command-line tools, comes from the releases page on GitHub. Find the latest alpha and open its Assets list.
On macOS, download the .dmg that matches your chip:
Rancher.Desktop-2.0.0-alpha.1.aarch64.dmg on Apple silicon, or the x86_64
build on an Intel Mac. Open it, drag the app into Applications, and launch it
from there.
On Windows, download the installer, Rancher.Desktop.Setup.2.0.0-alpha.1.msi,
and run it. Install WSL2 first if you have not already; 2.0 runs its Linux VM
through WSL2, just as Rancher Desktop does.
On Linux, install from our RPM or DEB repositories or run the AppImage, the same channels as Rancher Desktop.
The first time you launch the app, it sets up the backend and downloads the VM image, which can take a while on a slow connection. After that the app is talking to a running container engine, and you can manage containers, images, and volumes from its window.
If you want a container engine and a cluster with no window on screen, skip the
app and download the single rdd binary instead. It is the whole backend in
one file: no installer, nothing to unpack.
The binaries are on the same releases page. The name is rdd- followed by the
version, the operating system, and the CPU architecture: on an Apple silicon
Mac you want rdd-2.0.0-alpha.1.darwin.aarch64; on x86_64 Linux,
rdd-2.0.0-alpha.1.linux.x86_64. Download the one for your machine, put it on
your PATH, and make it executable:
curl --location --output /usr/local/bin/rdd \
https://github.com/rancher-sandbox/rancher-desktop-2/releases/download/v2.0.0-alpha.1/rdd-2.0.0-alpha.1.darwin.aarch64
chmod +x /usr/local/bin/rdd
From there, one command gets you a running container:
rdd run docker run --rm hello-world
rdd run is the no-commitment way to use 2.0. It starts the daemon if it is
not already up, then runs your command with the PATH and the Docker and
Kubernetes contexts pointed at 2.0 for that command only. It leaves your own
configuration untouched. So if your machine is already set up for Rancher
Desktop, leave it that way and reach for 2.0 with rdd run when you want to
try something. The very first start downloads the openSUSE Leap image and
brings the VM up, which can take a while on a slow connection; after that it is
quick.
Kubernetes works the same way. On a fresh setup, rdd run kubectl get node
enables Kubernetes at the default version and runs against the new cluster,
with no separate step to turn it on:
rdd run kubectl get node
That shortcut fires only the first time, while nothing is configured yet. Once
Rancher Desktop exists, choose a version or toggle Kubernetes with rdd set
(1.31 or newer):
rdd set kubernetes.enabled=true kubernetes.version=1.32.2
The same rdd commands drive 2.0 whether you installed the app or only the
binary. The GUI is one more client; underneath, it runs the daemon you do.
rdd run is fine for the occasional command. If you reach for 2.0 a lot, put
docker, kubectl, and helm on your PATH directly. The first start
populates ~/.rd2/bin with them; add that directory to your PATH yourself,
in this shell and in your profile:
export PATH="$HOME/.rd2/bin:$PATH"
This alpha sets up no paths for you, so that line is your job. Both the Docker
and Kubernetes contexts are named rancher-desktop-2, and 2.0 will not take
over a context you already have selected. If you run both side by side, move
between them by switching contexts:
docker context use rancher-desktop-2
kubectl config use-context rancher-desktop-2
Managing the backend itself needs no rdd run. rdd start brings it up and
rdd stop takes it down, keeping your data for next time:
rdd start # bring the backend up
rdd stop # take it down, keep your data
There is no upgrade path between previews yet, so each new alpha starts from a
clean slate. rdd svc delete stops the daemon and removes everything 2.0
created, the VM, the cluster, your settings, and the daemon's own data, keeping
only the download cache so a reinstall does not refetch the VM image. It is
also how you uninstall: after it runs, delete the rdd binary or remove the
app. The cache it leaves is Lima's, not ours (~/Library/Caches/lima on macOS,
~/.cache/lima on Linux, ~/AppData/Local/lima on Windows); delete it too for
a full reclaim. A later release will handle that for you, clearing distro
images from earlier previews automatically and adding a command to empty the
cache. For the next preview instead, install the new build and start again.
That is the alpha: install it one of two ways, start it, run a container. It will break on setups we have never seen, and when it does, tell us. Finding out where it breaks is much of why we shipped it this early.
rdd is a Kubernetes API server in its own right, and Rancher Desktop's own
state lives inside it as Kubernetes objects. rdd ctl is kubectl aimed at that
API. Ask it for the App object and the whole machine prints as YAML: the
container engine, the Kubernetes version it settled on, and the conditions
tracking its progress toward the state you asked for.
# rdd ctl get app -o yaml
apiVersion: v1
items:
- apiVersion: app.rancherdesktop.io/v1alpha1
kind: App
metadata:
creationTimestamp: "2026-06-17T17:44:58Z"
finalizers:
- rdd.rancherdesktop.io/cleanup
generation: 4
name: app
resourceVersion: "507"
uid: 3ab44aec-8949-41b8-8432-03224fe38ce5
spec:
containerEngine:
name: moby
kubernetes:
enabled: true
version: 1.34.6
namespace: rancher-desktop
running: true
status:
conditions:
- lastTransitionTime: "2026-06-19T00:57:05Z"
message: Container engine synced
observedGeneration: 4
reason: Connected
status: "True"
type: ContainerEngineReady
- lastTransitionTime: "2026-06-19T00:57:10Z"
message: Kubernetes cluster is ready
observedGeneration: 4
reason: Ready
status: "True"
type: KubernetesReady
- lastTransitionTime: "2026-06-17T17:45:19Z"
message: Lima instance created successfully
observedGeneration: 4
reason: Created
status: "True"
type: Created
- lastTransitionTime: "2026-06-19T00:57:10Z"
message: App has reached the desired state
observedGeneration: 4
reason: Settled
status: "True"
type: Settled
- lastTransitionTime: "2026-06-19T00:57:05Z"
message: Lima instance is running
observedGeneration: 4
reason: Started
status: "True"
type: Running
kubernetesPort: 7443
kind: List
metadata:
resourceVersion: ""
This is not the cluster you turned on earlier. It is Rancher Desktop representing itself through the same API your tools already speak, which means anything that drives Kubernetes can drive it, no bespoke SDK and no private protocol. There is a lot to say about that, and it gets a post of its own.
]]>minikube start to bring up a Kubernetes cluster on
your Mac. That was the whole thing: nine files, one good idea, and a note in the
source that read, more or less, this is just a quick proof of concept.
SUSE had just bought Rancher Labs, and the goal was easy to state and hard to build: make Kubernetes easy on a developer's laptop. We called it Rancher Desktop because, at the time, "Rancher" was how SUSE said "Kubernetes." That branding has gotten more complicated since, the way branding does, but the name stuck.
About seven months later, in May 2021, the first public build shipped: macOS and Windows, k3s for Kubernetes, an image builder called kim, and a way to switch Kubernetes versions. It was alpha software and looked like it. Five years on it's a different program, and the story of how it got here is mostly the story of how much work it took to keep one simple promise on three operating systems at once.
On a Mac, Kubernetes needs a Linux virtual machine. On Windows, it needs WSL2. So from the very first release, Rancher Desktop had two backends, and we spent the next five years discovering how different "two backends" really are.
The Mac side never sat still. We started with minikube, dropped it to drive Apple's Hypervisor.framework via the docker-machine-driver-hyperkit, then replaced it with Lima and QEMU. Each move was a rebuild of the layer that creates the VM, installs k3s, and wires up the network. When Apple later shipped its own Virtualization framework, VZ, moving to it was mostly a matter of telling Lima to use it. That's the difference a real foundation makes: the next big change stops being a rebuild.
Windows went its own way, with k3s running inside a dedicated WSL distribution we imported from an image we built ourselves. When Linux arrived as a tech preview in late 2021, it didn't add a third backend. It joined the Mac under Lima, which manages the VM on macOS and Linux alike, and which we got to build on as an upstream open-source project instead of maintaining alone. That part worked. macOS and Linux became one backend, where a fix landed once instead of twice.
Building on Lima also meant building it. Lima started narrow: a way to run containers with nerdctl on a Mac. The provisioning scripts we added a few weeks in, the mechanism that runs setup inside a fresh VM, are how Rancher Desktop installs k3s and a container engine. They also opened up Lima so you could provision for almost anything. Other contributions are the rules-based port forwarding configuration and host-based DNS lookup to extend VPN connections into the VM. What we needed, we built upstream, where every Lima user got to benefit from it.
Windows stayed separate. We tried more than once to fold the two together but never fully managed it. The systems were too different: a VM you own end to end on one side, a WSL distro living under someone else's rules on the other. So most features had to be built twice, into two backends similar enough to look the same and different enough to break in their own ways. Every new capability had to be implemented twice.
The VM ran Alpine Linux, picked because it's tiny: a smaller download, a faster boot. Alpine stays small by using musl and OpenRC instead of the glibc and systemd most Linux software is built against. Usually that's invisible. Sometimes it isn't: you can't run the NVIDIA Container Toolkit on it, which means no CUDA, which means machines with a GPU can't run the AI workloads people increasingly want to run. A choice that saved a few megabytes early on walled off a whole category of work once GPUs and AI showed up.
We set out to ship Kubernetes, and users kept asking for the rest of the container toolbox. The first image builder, kim, ran inside the cluster; we replaced it with nerdctl, the standard containerd CLI, and most people never noticed kim was gone. Then we hit something we hadn't planned for: a lot of real projects simply wouldn't build under nerdctl and buildkit. We added moby (dockerd and the Docker CLI) as a second engine, so those projects would build. Later we let people turn Kubernetes off entirely and run nothing but the container engine. Rancher Desktop had quietly grown from "Kubernetes on your desktop" into "containers and Kubernetes on your desktop."
Networking was the part that never stopped being hard. A container's ports, the right DNS answers, a corporate VPN that doesn't break everything: getting all three to coexist took years of work on each platform, and little of it carried across. On macOS the VM reaches the network through a layer called vmnet, where we moved from one implementation to another and carried both for a while. Windows needed something else entirely: to keep the VM's network from fighting the host's VPN, we built a tunnelling network that runs in its own isolated namespace.
Some of that split is just the operating systems being different; there's no single answer that works on both. The question a clean design has to get right isn't how to avoid writing two of them. It's where that code should live, pushed as far down into the shared foundation as it will go instead of tangled through the app.
The request for Linux support surprised us. On Linux you can already run k3s, containerd, and Docker natively. What does a desktop app add? Not the containers. The value was being able to throw the whole thing away: a factory reset that wipes the VM back to nothing, worth a lot when your environment drifts into a state you no longer understand. People didn't want another way to run containers. They wanted an undo button for their development machine (and later, snapshots).
Two things made Rancher Desktop easier to work with, and both ran into the same wall.
The first was rdctl, a command-line tool for driving Rancher Desktop without touching the GUI. It let us write our integration tests as plain shell scripts instead of clicking through the interface, and it let users automate their setup. But not everything was reachable from it. Port forwarding, for one, still went through private messaging between the GUI and the backend, never exposed through the REST API, so the GUI could do things no script could.
The second was snapshots: save the VM's state, restore it later. A simple feature, an awkward implementation, because the backend has to stop while its disk is copied, and the backend lives inside the GUI. So taking a snapshot turned into a small contortion. The GUI launches rdctl, which calls back into the GUI to ask it to shut its own backend down, takes the snapshot, then asks it to start back up. Cancelling was worse: there was no clean channel for it, so the GUI found the running rdctl process and killed it by name.
Underneath both was the same fact: you can't run the backend without the GUI. You can hide the window, you can tuck it into the background, but the app is always loaded, because the engine lives inside it. There is no headless Rancher Desktop. For something a developer wants to script, drop on a CI runner, or hand to an AI agent to drive, that's real friction.
Step back, and a pattern runs through all of it. Every feature got a little more difficult to implement than the last. Two backends to change in lockstep. An engine welded to its own UI. A guest OS that couldn't reach the GPU. None of it was a mistake exactly (each call was reasonable when we made it), but the costs compounded, until we were spending more time maintaining the existing machinery than building anything new.
The parts that aged well point the way. Building on Lima gave us one backend for macOS and Linux and an upstream community to share the load. And the command-line tool we'd built for our own tests turned out to matter more than we planned. A tool an AI model can explore and drive on its own is also exactly what you want now that so much work is handed to agents.
So Rancher Desktop 2.0 starts over, on purpose. One backend across every platform, Windows included. The backend lifted out of the UI into something you can run on its own: headless, scripted, snapshotted by itself. A guest that can talk to your GPU. Not because the first five years were wrong, but because they taught us exactly what the foundation needed to be. The rest of this blog is about what we're building on it.
]]>