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, rebuilt from the ground up and easier to maintain.
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.
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 1.x, 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. Don't run them both at once, though. There are likely port and socket conflicts.
The full app, GUI plus bundled tools, comes from the latest
release
on GitHub 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.x. 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 just released. 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.
💬 Questions or feedback? Discuss this post on GitHub →
]]>rdd binary straight from your
terminal. Both leave Rancher Desktop 1.x alone, and both put you a couple of
commands from a working container engine.
2.0 installs beside Rancher Desktop 1.x without touching it, with a separate package, separate data, and 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, including the GUI and a set of bundled command-line tools, comes from the latest release on GitHub; its notes list the download for every platform. Open the Assets list there.
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 1.x does.
On Linux, install from our RPM or DEB repositories, or run the AppImage, similar to the channels used for Rancher Desktop 1.x.
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.
One thing the app will not do for you yet: turn on Kubernetes. It starts with
Kubernetes off, and this alpha has no settings screen or first-run dialog to
change that, so you enable it from the command line. The first run installs
rdd into ~/.rd2/bin; put that on your PATH (or call ~/.rd2/bin/rdd
directly) and run:
rdd set kubernetes.enabled=true
The VM is already running without Kubernetes, so this restarts it once. A settings screen and first-run options are on the way; for now the command line is the only switch.
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 in the same GitHub release. 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 1.x, 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, turn Kubernetes on with rdd set:
rdd set kubernetes.enabled=true
The version defaults to the latest stable; pass kubernetes.version=1.32.2 to
pin a specific one (1.31 or newer).
The same rdd commands drive 2.0 whether you installed the full app or only the
binary. The GUI is an additional client; underneath, it runs the same daemon
as you do.
rdd run is fine for the occasional command. If you use 2.0 a lot, add
~/.rd2/bin to your PATH and call the tools directly. The first start
populates that directory; add it to your PATH yourself, in this shell and in
your profile:
export PATH="$HOME/.rd2/bin:$PATH"
What you find there depends on how you installed. rdd provides kubectl
itself, so it is there either way. docker and helm come with the full app,
which links them into ~/.rd2/bin alongside its other bundled tools and the
credential helpers; with the daemon-only download, supply docker and helm
yourself.
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.
That is the alpha: install it one of two ways, start it, run a container. It may break on setups we have never seen, and if it does, tell us.
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 requested Kubernetes version, 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.
| Command | What it does |
|---|---|
rdd run <cmd> | Run one command against 2.0, starting the daemon if needed and leaving your own setup untouched |
rdd start | Bring the backend up |
rdd stop | Take the backend down, keeping your data |
rdd set <key>=<value> | Change a setting, such as rdd set kubernetes.enabled=true |
rdd svc delete | Stop the daemon and remove everything 2.0 created (also how you uninstall) |
rdd ctl | kubectl aimed at the rdd API, where Rancher Desktop keeps its own state |
💬 Questions or feedback? Discuss this post on GitHub →
]]>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, with macOS and Windows support, 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.
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, just 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, which meant a smaller download and 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. WSL puts every distribution on one shared network, so to avoid port conflicts with the others, we gave our VM a tunnelling network in its own network 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 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, saving the VM's state to restore 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.
💬 Questions or feedback? Discuss this post on GitHub →
]]>