Rancher Desktop 2.0 is a full 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, rebuilt from the ground up and easier to\nmaintain.
\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.
Because 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.
The 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.
\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 1.x, and the\ntwo ignore each other completely: separate package, separate data, separate\neverything. Install them in either order, remove them in either order, nothing\ngets tangled. Don't run them both at once, though. There are likely port and\nsocket conflicts.
\nThe full app, GUI plus bundled tools, comes from the latest\nrelease\non GitHub for Windows and macOS (Intel and Apple silicon), and from our RPM and\nDEB repositories and AppImages on Linux, the same places you would reach for\nRancher Desktop 1.x. If all you want is the daemon, download the single rdd\nbinary for your platform and you are two commands away from a running\ncontainer.
A 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 just released. To find\nout 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.
\n💬 Questions or feedback? Discuss this post on GitHub →
", "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 full 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 1.x alone, and both put you a couple of\ncommands from a working container engine.
2.0 installs beside Rancher Desktop 1.x without touching it, with a\nseparate package, separate data, and nothing shared. Install or remove them\nin any order. (The\nwelcome post covers what 2.0 is and how\nit differs; this one is about getting it running.)
\nThe full app, including the GUI and a set of bundled command-line tools, comes\nfrom the\nlatest release\non GitHub; its notes list the download for every platform. Open the Assets\nlist there.
\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 1.x does.
On Linux, install from our RPM or DEB repositories, or run the AppImage,\nsimilar to the channels used for Rancher Desktop 1.x.
\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.
\nOne thing the app will not do for you yet: turn on Kubernetes. It starts with\nKubernetes off, and this alpha has no settings screen or first-run dialog to\nchange that, so you enable it from the command line. The first run installs\nrdd into ~/.rd2/bin; put that on your PATH (or call ~/.rd2/bin/rdd\ndirectly) and run:
rdd set kubernetes.enabled=true
The VM is already running without Kubernetes, so this restarts it once. A\nsettings screen and first-run options are on the way; for now the command line\nis the only switch.
\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 in the same GitHub release. 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 1.x, leave it that way and reach for 2.0 with rdd run when you want\nto try 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, 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\npin a specific one (1.31 or newer).
The same rdd commands drive 2.0 whether you installed the full app or only the\nbinary. The GUI is an additional client; underneath, it runs the same daemon\nas you do.
rdd run is fine for the occasional command. If you use 2.0 a lot, add\n~/.rd2/bin to your PATH and call the tools directly. The first start\npopulates that directory; add it to your PATH yourself, in this shell and in\nyour profile:
export PATH=\"$HOME/.rd2/bin:$PATH\"
What you find there depends on how you installed. rdd provides kubectl\nitself, so it is there either way. docker and helm come with the full app,\nwhich links them into ~/.rd2/bin alongside its other bundled tools and the\ncredential helpers; with the daemon-only download, supply docker and helm\nyourself.
Both the Docker and Kubernetes contexts are\nnamed rancher-desktop-2, and 2.0 will not take over a context you already\nhave selected. If you run both side by side, move between them by switching\ncontexts:
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.
That is the alpha: install it one of two ways, start it, run a container. It\nmay break on setups we have never seen, and if it does, tell us.
\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 requested Kubernetes version, 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.
\n| 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 →
", "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, with\nmacOS and Windows support, k3s for Kubernetes, an image builder called kim, and\na way to switch Kubernetes versions. It was alpha software and looked like it.\nFive years on it's a different program, and the story of how it got here is\nmostly the story of how much work it took to keep one simple promise on three\noperating systems at 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.
\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, just 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, which meant a smaller\ndownload and a faster boot. Alpine stays small by using musl and OpenRC\ninstead of the glibc and systemd most Linux software is built against. Usually\nthat's invisible. Sometimes it isn't. You can't run the NVIDIA Container\nToolkit on it, which means no CUDA, which means machines with a GPU can't run\nthe AI workloads people increasingly want to run. A choice that saved a few\nmegabytes early on walled off a whole category of work once GPUs and AI showed\nup.
\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. WSL puts every distribution on one\nshared network, so to avoid port conflicts with the others, we gave our VM a\ntunnelling network in its own network namespace.
\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 wipes the VM back to nothing, worth a lot when your environment drifts\ninto 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, saving the VM's state to restore 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.
\n💬 Questions or feedback? Discuss this post on GitHub →
", "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": [] } ] }