Rancher Desktop 2.0 is a ground-up rewrite, and the first build is ready for you\nto try. There is an alpha you can download today and run on your own machine.
\nLet's call it what it is: an early tech preview. It is rough, and not meant for\nproduction. It exists so you can see that 2.0 is real and already running, and\nso you can tell us what you would like while the architecture is still soft\nenough to change.
\nWe rewrote Rancher Desktop because the old design made every new feature take\nmore effort than the one before it. The history\npost tells that story; the short version is\none backend instead of two, the engine lifted out of the GUI, and a different\nguest OS underneath. 2.0 is that idea, built.
\nAt the center is a new background program called rdd, the Rancher Desktop\nDaemon. rdd does the real work. It runs the virtual machine, using Lima on every\nplatform now, Windows included. It starts your container engine and your\nKubernetes cluster. It exposes all of that through an API, and not a custom one:\nrdd speaks the Kubernetes API. Your kubectl and the usual client libraries can\ndrive it directly, no new SDK to learn. The desktop app is just one more client,\nwith no special privileges, talking to rdd the way any other tool would.
\nBecause the work lives in rdd instead of inside a window, you can run the whole\nthing without ever opening the GUI. And rdd is one self-contained executable: no\ninstaller, no separate daemon and command-line tool, just one file that is both\nthe backend and the way you drive it. Download it, start it from the command\nline, and you have a container engine and a cluster: on a headless server, on a\nCI runner, or in your own terminal. Deploying it is copying one file. Rancher\nDesktop never had a way to do this. The engine lived inside the app, and the\napp had to be on screen.
\nThe guest VM runs openSUSE Leap now instead of Alpine. The reason is glibc: much\nof the GPU and AI tooling people ask for needs it, and Alpine's musl does not\nprovide it. GPU support is not built yet, but the guest OS no longer rules it\nout.
\nWe could have kept this private until it looked polished. We would rather not.\nPutting it out now, rough edges and all, does two things for us.
\nIt shows that \"we will do that in 2.0\" means a workstream already running, not a\npromise about some distant year. And it puts the design in front of you early,\nwhen your feedback still counts. If your setup depends on something specific,\nthis is the moment to say so, before we lock in decisions we made without you.
\nThis is a working preview, not a finished product. What runs right now:
\nSo you are not caught off guard:
\nYou do not have to choose. 2.0 installs next to Rancher Desktop, and the two\nignore each other completely: separate package, separate data, separate\neverything. Install them in either order, remove them in either order, nothing\ngets tangled. You can even run both at once, though I would not recommend it.\nTwo container engines and two clusters on one laptop gets confusing quickly.
\nThe full app, GUI plus bundled tools, comes from the GitHub releases page for\nWindows and macOS (Intel and Apple silicon), and from our RPM and DEB\nrepositories and AppImages on Linux. The same places you would reach for Rancher\nDesktop 1. If all you want is the daemon, download the single rdd binary for\nyour platform and you are two commands away from a running container.
\nA real installation and usage\nwalkthrough is a separate post in this\nseries.
\nThis is alpha software. Things will break, especially in corners we have never\ntested on a machine configured like yours. When they do, tell us. That feedback\nis a big part of why we are shipping this early.
\nThere are no docs for 2.0 yet. There is this blog. As the work moves, we will\nwrite about how the pieces fit and what becomes newly possible: the daemon and\nits API, networking, snapshots, the AI story, whatever we're working on that\nmonth. To find out when the next preview drops, subscribe to the feed.
\nCurious, and feeling adventurous? Give it a try. Cautious? Follow along, and\njump in when it looks ready for you.
", "url": "https://docs.rancherdesktop.io/blog/welcome-to-rancher-desktop-2/", "title": "Welcome to Rancher Desktop 2.0", "summary": "Rancher Desktop 2.0 is a ground-up rewrite, and the first build is ready for you", "date_modified": "2026-06-19T00:00:00.000Z", "author": { "name": "Jan Dubois", "url": "https://github.com/jandubois" }, "tags": [] }, { "id": "https://docs.rancherdesktop.io/blog/installing-rancher-desktop-2/", "content_html": "The 2.0 alpha is out, and there are two ways to run it. Install the full\ndesktop app, or skip the GUI and run the new rdd binary straight from your\nterminal. Both leave Rancher Desktop alone, and both put you a couple of\ncommands from a working container engine.
\n2.0 installs beside Rancher Desktop without touching it: separate package,\nseparate data, nothing shared. Install or remove them in any order. (The\nwelcome post covers what 2.0 is and how\nit differs; this one is about getting it running.)
\nThe full app, the GUI plus a set of bundled command-line tools, comes from the\nreleases page\non GitHub. Find the latest alpha and open its Assets list.
\nOn macOS, download the .dmg that matches your chip:\nRancher.Desktop-2.0.0-alpha.1.aarch64.dmg on Apple silicon, or the x86_64\nbuild on an Intel Mac. Open it, drag the app into Applications, and launch it\nfrom there.
On Windows, download the installer, Rancher.Desktop.Setup.2.0.0-alpha.1.msi,\nand run it. Install WSL2 first if you have not already; 2.0 runs its Linux VM\nthrough WSL2, just as Rancher Desktop does.
On Linux, install from our RPM or DEB repositories or run the AppImage, the\nsame channels as Rancher Desktop.
\nThe first time you launch the app, it sets up the backend and downloads the\nVM image, which can take a while on a slow connection. After that the app is\ntalking to a running container engine, and you can manage containers, images,\nand volumes from its window.
\nIf you want a container engine and a cluster with no window on screen, skip the\napp and download the single rdd binary instead. It is the whole backend in\none file: no installer, nothing to unpack.
The binaries are on the same releases page. The name is rdd- followed by the\nversion, the operating system, and the CPU architecture: on an Apple silicon\nMac you want rdd-2.0.0-alpha.1.darwin.aarch64; on x86_64 Linux,\nrdd-2.0.0-alpha.1.linux.x86_64. Download the one for your machine, put it on\nyour 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:
\nrdd run docker run --rm hello-world
rdd run is the no-commitment way to use 2.0. It starts the daemon if it is\nnot already up, then runs your command with the PATH and the Docker and\nKubernetes contexts pointed at 2.0 for that command only. It leaves your own\nconfiguration untouched. So if your machine is already set up for Rancher\nDesktop, leave it that way and reach for 2.0 with rdd run when you want to\ntry something. The very first start downloads the openSUSE Leap image and\nbrings the VM up, which can take a while on a slow connection; after that it is\nquick.
Kubernetes works the same way. On a fresh setup, rdd run kubectl get node\nenables Kubernetes at the default version and runs against the new cluster,\nwith 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\nRancher Desktop exists, choose a version or toggle Kubernetes with rdd set\n(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\nbinary. 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\ndocker, kubectl, and helm on your PATH directly. The first start\npopulates ~/.rd2/bin with them; add that directory to your PATH yourself,\nin 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\nand Kubernetes contexts are named rancher-desktop-2, and 2.0 will not take\nover a context you already have selected. If you run both side by side, move\nbetween 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\nrdd 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\nclean slate. rdd svc delete stops the daemon and removes everything 2.0\ncreated, the VM, the cluster, your settings, and the daemon's own data, keeping\nonly the download cache so a reinstall does not refetch the VM image. It is\nalso how you uninstall: after it runs, delete the rdd binary or remove the\napp. The cache it leaves is Lima's, not ours (~/Library/Caches/lima on macOS,\n~/.cache/lima on Linux, ~/AppData/Local/lima on Windows); delete it too for\na full reclaim. A later release will handle that for you, clearing distro\nimages from earlier previews automatically and adding a command to empty the\ncache. 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\nwill break on setups we have never seen, and when it does, tell us. Finding out\nwhere it breaks is much of why we shipped it this early.
\nrdd is a Kubernetes API server in its own right, and Rancher Desktop's own\nstate lives inside it as Kubernetes objects. rdd ctl is kubectl aimed at that\nAPI. Ask it for the App object and the whole machine prints as YAML: the\ncontainer engine, the Kubernetes version it settled on, and the conditions\ntracking 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\nrepresenting itself through the same API your tools already speak, which means\nanything that drives Kubernetes can drive it, no bespoke SDK and no private\nprotocol. There is a lot to say about that, and it gets a post of its own.
", "url": "https://docs.rancherdesktop.io/blog/installing-rancher-desktop-2/", "title": "Installing and Running Rancher Desktop 2.0", "summary": "The 2.0 alpha is out, and there are two ways to run it. Install the full", "date_modified": "2026-06-18T00:00:00.000Z", "author": { "name": "Jan Dubois", "url": "https://github.com/jandubois" }, "tags": [] }, { "id": "https://docs.rancherdesktop.io/blog/history-of-rancher-desktop/", "content_html": "In October 2020, Rancher Desktop was a tray icon and a single shell command.\nClick the icon, and it ran minikube start to bring up a Kubernetes cluster on\nyour Mac. That was the whole thing: nine files, one good idea, and a note in the\nsource 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\nbuild: make Kubernetes easy on a developer's laptop. We called it Rancher\nDesktop because, at the time, \"Rancher\" was how SUSE said \"Kubernetes.\" That\nbranding has gotten more complicated since, the way branding does, but the name\nstuck.
\nAbout seven months later, in May 2021, the first public build shipped: macOS and\nWindows, k3s for Kubernetes, an image builder called kim, and a way to switch\nKubernetes versions. It was alpha software and looked like it. Five years on\nit's a different program, and the story of how it got here is mostly the story\nof how much work it took to keep one simple promise on three operating systems\nat once.
\nOn a Mac, Kubernetes needs a Linux virtual machine. On Windows, it needs WSL2.\nSo from the very first release, Rancher Desktop had two backends, and we spent\nthe next five years discovering how different \"two backends\" really are.
\nThe Mac side never sat still. We started with minikube, dropped it to drive\nApple's Hypervisor.framework via the docker-machine-driver-hyperkit, then\nreplaced it with Lima and QEMU. Each move was a rebuild of the layer that\ncreates the VM, installs k3s, and wires up the network. When Apple later shipped\nits own Virtualization framework, VZ, moving to it was mostly a matter of\ntelling Lima to use it. That's the difference a real foundation makes: the next\nbig change stops being a rebuild.
\nWindows went its own way, with k3s running inside a dedicated WSL distribution\nwe imported from an image we built ourselves. When Linux arrived as a tech\npreview in late 2021, it didn't add a third backend. It joined the Mac under\nLima, which manages the VM on macOS and Linux alike, and which we got to build\non as an upstream open-source project instead of maintaining alone. That part\nworked. macOS and Linux became one backend, where a fix landed once instead of\ntwice.
\nBuilding on Lima also meant building it. Lima started narrow: a way to run\ncontainers with nerdctl on a Mac. The provisioning scripts we added a few weeks\nin, the mechanism that runs setup inside a fresh VM, are how Rancher Desktop\ninstalls k3s and a container engine. They also opened up Lima so you could\nprovision for almost anything. Other contributions are the rules-based port\nforwarding configuration and host-based DNS lookup to extend VPN connections\ninto the VM. What we needed, we built upstream, where every Lima user got to\nbenefit from it.
\nWindows stayed separate. We tried more than once to fold the two together but\nnever fully managed it. The systems were too different: a VM you own end to end\non one side, a WSL distro living under someone else's rules on the other. So\nmost features had to be built twice, into two backends similar enough to look\nthe same and different enough to break in their own ways. Every new capability\nhad to be implemented twice.
\nThe VM ran Alpine Linux, picked because it's tiny: a smaller download, a faster\nboot. Alpine stays small by using musl and OpenRC instead of the glibc and\nsystemd most Linux software is built against. Usually that's invisible.\nSometimes it isn't: you can't run the NVIDIA Container Toolkit on it, which\nmeans no CUDA, which means machines with a GPU can't run the AI workloads people\nincreasingly want to run. A choice that saved a few megabytes early on walled\noff a whole category of work once GPUs and AI showed up.
\nWe set out to ship Kubernetes, and users kept asking for the rest of the\ncontainer toolbox. The first image builder, kim, ran inside the cluster; we\nreplaced it with nerdctl, the standard containerd CLI, and most people never\nnoticed kim was gone. Then we hit something we hadn't planned for: a lot of real\nprojects simply wouldn't build under nerdctl and buildkit. We added moby\n(dockerd and the Docker CLI) as a second engine, so those projects would build.\nLater we let people turn Kubernetes off entirely and run nothing but the\ncontainer engine. Rancher Desktop had quietly grown from \"Kubernetes on your\ndesktop\" into \"containers and Kubernetes on your desktop.\"
\nNetworking was the part that never stopped being hard. A container's ports, the\nright DNS answers, a corporate VPN that doesn't break everything: getting all\nthree to coexist took years of work on each platform, and little of it carried\nacross. On macOS the VM reaches the network through a layer called vmnet, where\nwe moved from one implementation to another and carried both for a while.\nWindows needed something else entirely: to keep the VM's network from fighting\nthe host's VPN, we built a tunnelling network that runs in its own isolated\nnamespace.
\nSome of that split is just the operating systems being different; there's no\nsingle answer that works on both. The question a clean design has to get right\nisn't how to avoid writing two of them. It's where that code should live, pushed\nas far down into the shared foundation as it will go instead of tangled through\nthe app.
\nThe request for Linux support surprised us. On Linux you can already run k3s,\ncontainerd, and Docker natively. What does a desktop app add? Not the\ncontainers. The value was being able to throw the whole thing away: a factory\nreset that wipes the VM back to nothing, worth a lot when your environment\ndrifts into a state you no longer understand. People didn't want another way to\nrun containers. They wanted an undo button for their development machine (and\nlater, snapshots).
\nTwo things made Rancher Desktop easier to work with, and both ran into the same\nwall.
\nThe first was rdctl, a command-line tool for driving Rancher Desktop without\ntouching the GUI. It let us write our integration tests as plain shell scripts\ninstead of clicking through the interface, and it let users automate their\nsetup. But not everything was reachable from it. Port forwarding, for one, still\nwent through private messaging between the GUI and the backend, never exposed\nthrough the REST API, so the GUI could do things no script could.
\nThe second was snapshots: save the VM's state, restore it later. A simple\nfeature, an awkward implementation, because the backend has to stop while its\ndisk is copied, and the backend lives inside the GUI. So taking a snapshot\nturned into a small contortion. The GUI launches rdctl, which calls back into\nthe GUI to ask it to shut its own backend down, takes the snapshot, then asks it\nto start back up. Cancelling was worse: there was no clean channel for it, so\nthe GUI found the running rdctl process and killed it by name.
\nUnderneath both was the same fact: you can't run the backend without the GUI.\nYou can hide the window, you can tuck it into the background, but the app is\nalways loaded, because the engine lives inside it. There is no headless Rancher\nDesktop. For something a developer wants to script, drop on a CI runner, or hand\nto an AI agent to drive, that's real friction.
\nStep back, and a pattern runs through all of it. Every feature got a little more\ndifficult to implement than the last. Two backends to change in lockstep. An\nengine welded to its own UI. A guest OS that couldn't reach the GPU. None of it\nwas a mistake exactly (each call was reasonable when we made it), but the costs\ncompounded, until we were spending more time maintaining the existing machinery\nthan building anything new.
\nThe parts that aged well point the way. Building on Lima gave us one backend for\nmacOS and Linux and an upstream community to share the load. And the\ncommand-line tool we'd built for our own tests turned out to matter more than we\nplanned. A tool an AI model can explore and drive on its own is also exactly\nwhat you want now that so much work is handed to agents.
\nSo Rancher Desktop 2.0 starts over, on purpose. One backend across every\nplatform, Windows included. The backend lifted out of the UI into something you\ncan run on its own: headless, scripted, snapshotted by itself. A guest that can\ntalk to your GPU. Not because the first five years were wrong, but because they\ntaught us exactly what the foundation needed to be. The rest of this blog is\nabout what we're building on it.
", "url": "https://docs.rancherdesktop.io/blog/history-of-rancher-desktop/", "title": "A Short History of Rancher Desktop", "summary": "In October 2020, Rancher Desktop was a tray icon and a single shell command.", "date_modified": "2026-06-17T00:00:00.000Z", "author": { "name": "Jan Dubois", "url": "https://github.com/jandubois" }, "tags": [] } ] }