RustDesk: self-hosted remote desktop in Rust

What RustDesk solves, and who ends up using it

Remote desktop tools normally route every session through the vendor's servers. You install a client, the client registers with a directory the vendor runs, and the vendor's relay carries the pixels when a direct connection fails. RustDesk keeps the client but makes the directory and the relay replaceable. The README states you can use the project's rendezvous/relay server, set up your own, or write your own using the rustdesk-server-demo repository.

That single design choice defines the audience. It is for engineers who can run a small server, or who already have one, and who care where session metadata lands. It is also for people who need a client on platforms the vendor tools cover unevenly, since the README links Flutter builds, an F-Droid package and a Flathub app. The README describes the project as working out of the box with no configuration required, which is true for the default path: install, launch, exchange an ID, connect. Self-hosting is the part you opt into.

The misuse disclaimer at the top of the README is worth reading as a product statement rather than legal boilerplate. Remote access software is dual use, and the project puts the boundary in writing.

How the rendezvous and relay model actually works

The architecture separates three roles. A rendezvous server introduces two peers and helps them find each other. A relay server carries the stream when a direct peer-to-peer path cannot be established, which is common behind carrier-grade NAT or restrictive corporate firewalls. The client itself does the capture, encoding and input injection on the controlled machine.

The repository layout reflects that split. The top level holds src/ for the application, libs/ for the reusable crates, flutter/ for the Flutter GUI, and a Dockerfile plus vcpkg.json for the build environment. Cargo.toml declares three targets: a cdylib and staticlib named librustdesk, plus binaries named naming and service. The service binary is the piece that runs with elevated privileges on the controlled machine, which is why the build instructions treat it separately from the GUI.

The feature flags in Cargo.toml show how much of the capture path is compile-time. The default feature set is use_dasp for audio resampling. Hardware codec support sits behind hwcodec, vram, mediacodec and drm, each pulling a feature from the scrap crate. The drm-wake feature is documented in the manifest as a separate gate on top of drm, because the wake path writes a synthetic pointer event from the root service to re-enable idle-disabled outputs, while the rest of the DRM backend only reads a scanout. That comment is unusually candid about the risk: a write path that can be removed from the binary without giving up capture.

Installing RustDesk and making a first connection

Most users should take a released binary. The README points to the releases page for downloads and to a separate nightly tag for pre-release builds. On Linux, Flathub and F-Droid are linked as distribution channels. If you want the source build, the README documents both a raw path and a Docker path.

The raw path on Debian or Ubuntu starts with system packages. The README lists the exact set for Ubuntu 18 and Debian 10, and the list is long because the client links GTK, XCB, PulseAudio and GStreamer directly.

sudo apt install -y zip g++ gcc git curl wget nasm yasm libgtk-3-dev clang libxcb-randr0-dev libxdo-dev \
        libxfixes-dev libxcb-shape0-dev libxcb-xfixes0-dev libasound2-dev libpulse-dev cmake make \
        libclang-dev ninja-build libgstreamer1.0-dev libgstreamer-plugins-base1.0-dev

Next, vcpkg supplies libvpx, libyuv, opus and aom. The README pins a specific vcpkg checkout rather than tracking the default branch, which is the right call for reproducibility.

git clone https://github.com/microsoft/vcpkg
cd vcpkg
git checkout 2023.04.15
cd ..
vcpkg/bootstrap-vcpkg.sh
export VCPKG_ROOT=$HOME/vcpkg
vcpkg/vcpkg install libvpx libyuv opus aom

The Sciter GUI needs its dynamic library placed next to the debug binary before cargo can run. The README downloads it into target/debug and then invokes cargo with VCPKG_ROOT set.

curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
source $HOME/.cargo/env
git clone --recurse-submodules https://github.com/rustdesk/rustdesk
cd rustdesk
mkdir -p target/debug
wget https://raw.githubusercontent.com/c-smile/sciter-sdk/master/bin.lnx/x64/libsciter-gtk.so
mv libsciter-gtk.so target/debug
VCPKG_ROOT=$HOME/vcpkg cargo run

If you would rather not install the toolchain on your host, the Docker route builds a container once and reuses it. The README builds an image tagged rustdesk-builder, then runs it with the working directory and two cargo caches mounted so dependencies survive between builds.

git clone https://github.com/rustdesk/rustdesk
cd rustdesk
git submodule update --init --recursive
docker build -t "rustdesk-builder" .

docker run --rm -it -v $PWD:/home/user/rustdesk -v rustdesk-git-cache:/home/user/.cargo/git -v rustdesk-registry-cache:/home/user/.cargo/registry -e PUID="$(id -u)" -e PGID="$(id -g)" rustdesk-builder

After that, the README says the executable lands in the target folder and can be started as target/debug/rustdesk, or target/release/rustdesk for a release build. The first build is slow because dependencies are not cached yet; later builds reuse the mounted volumes.

For a first real session, launch the client on both machines, read the numeric ID shown on the machine you want to control, and enter it from the other side. The README's own server documentation is the place to look once you want those IDs to come from your infrastructure rather than the default.

Where RustDesk is the wrong tool

The build path is the first limitation. vcpkg is pinned to a 2023.04.15 checkout, and the README documents a Fedora-specific workaround that edits the libvpx Makefile with sed to add -fPIC before copying the static library into the vcpkg installed tree. That is a manual patch applied outside the build system. It works, but it is the kind of step that breaks silently when libvpx changes its build files.

The README also states that the Sciter GUI is deprecated and that the tutorial covers Sciter because it is easier to start with; the Flutter version is built through CI instead. Anyone following the raw steps is therefore learning a deprecated GUI path. The Flutter build is the one the project actually ships, and the README defers to the CI workflow file for it rather than documenting it inline.

Release hygiene is the other gap. The repository publishes a nightly tag alongside numbered releases, and the README does not document a rollback procedure, a version pinning policy, or how to verify that a published binary matches a source tag. If your environment requires an auditable chain from source to binary, that chain is not described here.

Finally, self-hosting is not a checkbox. Running your own rendezvous and relay means you own their availability. If the server is down, the clients cannot find each other through it. The README links to setup documentation but does not, in the pages it publishes, describe failover between multiple servers.

RustDesk against AnyDesk and the VNC family

The closest commercial comparison is AnyDesk, and the difference is structural rather than feature-level. AnyDesk operates the directory and relay infrastructure; you get an account and the vendor's network. RustDesk ships the client and a server you can host, so the equivalent of AnyDesk's backend becomes something you deploy and monitor. That changes the operational cost and the failure modes, not just the licence.

Against VNC implementations, the split is different again. VNC is a protocol with many independent servers and viewers, and it generally assumes you can reach the target machine's port directly or through a tunnel you set up yourself. RustDesk uses its own rendezvous and relay layer precisely so that neither side needs an inbound port, which is why it works across NAT without a VPN. The cost is that the rendezvous service becomes a component you depend on.

If you want to avoid running a relay at all, the search data suggests people pair RustDesk with Tailscale, putting both machines on a private network and letting the overlay handle reachability. That is a legitimate arrangement, but it is a user pattern rather than something the README documents, so treat it as an approach to evaluate rather than a supported configuration.

Licence, maintenance and what upgrades cost you

RustDesk is licensed AGPL-3.0. For internal use the practical effect is usually small. If you modify the code and let users interact with it over a network, the AGPL's source-availability condition applies to your modified version. If you want to embed RustDesk in a closed product, the AGPL is the constraint to resolve before you write code, either by publishing your changes or by taking the commercial route the project offers. This is a description of the licence, not legal advice; get your own counsel.

The repository is not archived. The last push was on 2026-07-10, and the most recent numbered release listed is 1.4.9 from 2026-07-06, with 1.4.8 on 2026-06-21. Cargo.toml on master declares version 1.5.0, so master is ahead of the latest numbered release. That gap matters if you build from source: you are testing code that has not been through a release.

Upgrade cost is dominated by the client fleet. Each machine needs its client updated, and the build toolchain (Rust 1.75 minimum per Cargo.toml, vcpkg at the pinned checkout, CMake) has to be reproduced on every build host. The Docker image encodes that toolchain, including a CMake built from source at version 3.30.6, which is the cheapest way to keep build hosts consistent.

Editorial conclusion

Adopt RustDesk if you need remote access where the connection metadata and relay traffic stay on infrastructure you control, and you accept AGPL-3.0 obligations or buy a commercial licence. Do not adopt it if you need a signed binary you can audit against a source tag, since the repository publishes nightly builds and the README does not document rollback. Before committing, verify that the 1.4.9 release matches the master branch you intend to run, and confirm that your own rendezvous and relay server is reachable from every network your users sit behind.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes