# RustDesk: AGPL, three crate types, and one default server that is not yours

> An open-source remote desktop application written in Rust, distributed as a library with three crate types and two extra binaries alongside the client. It works with no configuration because it defaults to the project's own rendezvous and relay servers, its documented build tutorial targets the deprecated GUI toolkit, and its build image disables certificate checking to fetch CMake.

**rustdesk/rustdesk** — A self-hostable open-source remote desktop application.

- Repository: https://github.com/rustdesk/rustdesk
- Website: https://rustdesk.com
- Stars: 124,514 · Forks: 19,258
- Language: Rust
- License: AGPL-3.0
- Published: 2026-08-08 · Updated: 2026-08-18 · Language: en
- Canonical page: https://hysenlabs.com/projects/rustdesk-rustdesk

## The default rendezvous and relay are the project's, and the client repo is not the server

The pitch is that it works out of the box with no configuration required and that you have full control of your data. Those two sentences are in tension, and the resolution is the server story, which the README gives in three options.

You can use the project's rendezvous and relay server. You can set up your own. Or you can write your own, with a separate demo repository linked for the purpose.

The first option is what no configuration means, and it is the one a default install takes. A rendezvous server is the address book that hands two clients to each other, and a relay is the path their traffic takes when a direct connection cannot be made. Until you change that setting, both of those functions are performed on infrastructure you do not operate, and the connection metadata passes through it.

The second structural point is that the client and the server are different projects. The repository you are reading is the application, and self-hosting means assembling the application plus a server you run, either from a separate repository or by deploying the service the project provides. Nobody has to write one, but nobody gets it from this repository either.

## --features drm is a read-only capture build, and waking the display is a write

The Cargo.toml explains its own most interesting flag, in a comment long enough to be worth reading twice.

The display wake exists as its own compile gate on top of drm. Everything else in the drm backend reads, because it captures a scanout. The wake writes, injecting one synthetic pointer event from the root service so that a compositor which idle-disabled its outputs re-enables them. The comment says that is a different kind of operation and deserves a switch that can remove it from the binary entirely without giving up DRM capture, and that `--features drm` builds the capture path with no wake code compiled in.

So there are two builds with meaningfully different powers. The one named in the comment is passive and only takes frames. The other, behind drm-wake, can generate input, and it does it by asking a service running as root to inject an event.

The practical failure this creates is worth stating plainly. Build with drm alone on a machine whose compositor has powered down the outputs, and you get a session that connects and shows nothing, with nothing in the logs pointing at a compile flag. The fix is a different feature, and understanding that is the difference between an afternoon of debugging and an afternoon of reading.

## The library builds three ways, and cargo run gives you neither service nor naming

The manifest declares a library and then two extra binaries, and this is the shape that explains why the project is packaged the way it is.

```toml
[lib]
name = "librustdesk"
crate-type = ["cdylib", "staticlib", "rlib"]

[[bin]]
name = "naming"
path = "src/naming.rs"

[[bin]]
name = "service"
path = "src/service.rs"
```

Three crate types means the same code is consumable as a C shared library, a static library, and a Rust library. That is what lets the project be embedded rather than only run, and it is why the display wake can be described as coming from a service, since something has to host it.

The two binaries are the part that trips people up. The raw build steps in the README end with running `cargo run`, and the package sets default-run to the client. So the shortest documented path produces the desktop application and nothing else. A headless install wants the service binary, and the naming binary is a third thing again. Nobody is stopped from building them, but the instructions do not say that the thing you need for a systemd unit or a Windows service is not what you just built.

## The build tutorial is for Sciter, which the same sentence calls deprecated

Read the dependencies note as a pair of sentences that contradict each other.

Desktop versions use Flutter or Sciter, and Sciter is marked deprecated. The tutorial that follows is for Sciter only, on the grounds that it is easier and more friendly to start, and the Flutter version is deferred to a CI workflow file rather than documented in prose. Then there is the instruction to download the Sciter dynamic library yourself, with a separate binary for Windows, Linux and macOS.

So the easiest path through the build documentation is the path to the deprecated user interface, and it requires a manual binary fetch of a GUI toolkit you have never heard of, into a location cargo will find. The maintained user interface is reachable only by reading a workflow YAML to work out the right feature flags.

The Cargo.toml does have the flag, named flutter, which pulls in a bridge crate. So the information exists, in a manifest rather than in the instructions, which is a reasonable place for it and a poor place for a first-time builder. Anyone starting here should read the features table before following the tutorial.

## vcpkg is pinned to a 2023 tag, and Fedora needs sed applied to libvpx

The C dependencies are four libraries, and they come from vcpkg, which the build instructions pin to a specific old commit.

```sh
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
```

Four libraries, three codecs and an image format, all pinned to a 2023 snapshot. The same pin appears in the Dockerfile, which clones the branch with --depth=1. That is deliberate reproducibility, and it is also a maintenance surface, because a vcpkg bump changes the codec and capture code underneath the whole application in one move.

Then there is a section headed Fix libvpx, for Fedora, which cd's into the dependency's own build tree, runs its configure, and rewrites its Makefile.

```sh
sed -i 's/CFLAGS+=-I/CFLAGS+=-fPIC -I/g' Makefile
sed -i 's/CXXFLAGS+=-I/CXXFLAGS+=-fPIC -I/g' Makefile
```

That is adding position-independent code flags by pattern match against a third-party Makefile. It is a documented manual repair step for one distribution, and it is a fair signal of how much of the build is a set of per-distro workarounds rather than a portable one.

## The build image fetches CMake with certificate checking switched off

The Dockerfile is worth reading for one line and one omission, and both are about the build rather than the application.

The line is the CMake fetch.

```dockerfile
RUN wget https://github.com/Kitware/CMake/releases/download/v3.30.6/cmake-3.30.6.tar.gz --no-check-certificate && \
    tar xzf cmake-3.30.6.tar.gz && \
    cd cmake-3.30.6 && \
    ./configure  --prefix=/usr/local && \
    make && \
    make install
```

--no-check-certificate means the image downloads a build tool over TLS without verifying who served it. Whatever the reason, it is a line that a supply-chain review will stop on, and it is a one-word change for anyone who needs to answer that review. It is in the project's own build image, used to produce a build container, so it is not on the path of a shipped binary, which is the appropriate place to scope the concern.

The omission is that the make invocation has no job control flag, so CMake compiles serially inside the image while everything around it would have been happy to run in parallel. The README warns that the first Docker build takes longer before dependencies are cached, and part of that time is this line rather than your code.

## AGPL-3.0, a file named LICENCE, and two store listings with different app identities

The licence is AGPL-3.0 and the file at the top of the repository is spelled LICENCE, with the British form, which means tooling looking for a file called LICENSE finds nothing.

The network clause is the term that matters for a deployment. The README links a pricing page, so the client has a commercial offering, and the repository's licence and the product's price are two separate questions. For anyone modifying this software and then serving it to users over a network, the AGPL is the term their own legal team will raise, and the answer is in that file rather than in the README.

The distribution picture is uneven in a way worth knowing before you deploy. The Flatpak listing is com.rustdesk.RustDesk. The F-Droid listing is com.carriez.flutter_hbb, which is a different application identity and a different vendor namespace entirely, reflecting the Flutter lineage of the project. So the two store entries are not the same app under two names, and an F-Droid user's package and a Flatpak user's package will not look alike in a system inventory.

The translations make the same point at a larger scale. There are around two dozen translated copies of this README, plus the interface strings under src/lang and a separate documentation site, and all three need translating.

## Conclusion

Use RustDesk when you need a remote desktop you can run entirely on your own machines and you are prepared to stand up the server side as well as the client, because the client is the easy half. Do not adopt it for a one-line self-host: out of the box it registers with the project's public rendezvous and relay, and the AGPL network clause is the term your legal team will ask about once you modify and expose it. Before you build, read the Cargo.toml features rather than the build tutorial, because `--features drm` gives you read-only capture and the display wake is a separate compile gate that injects a synthetic pointer event. And if your supply-chain review covers build images, be ready to justify the wget call in the Dockerfile that passes --no-check-certificate.

## FAQ

### What is the RustDesk app used for?

It is a self-hostable open-source remote desktop application written in Rust. You can use the project's rendezvous and relay server, set up your own, or write your own rendezvous and relay server from a separate demo repository, and the clients work with no configuration because they default to the first of those.

### Is RustDesk completely free?

The source is published under AGPL-3.0 and the README links a pricing page, so the repository and the commercial offering are separate things. Pre-built binaries and a nightly build are published on the releases page, and the README describes the project as a donor-independent self-hostable alternative without stating that the product itself carries no charge.

### How do I install RustDesk?

Pre-built binaries and a nightly build are linked from the releases page. To build it yourself you need a Rust and C++ toolchain, vcpkg with VCPKG_ROOT set for libvpx, libyuv, opus and aom, and the Sciter dynamic library downloaded by hand, then cargo run. A Docker path exists too, with git submodule update --init --recursive followed by docker build -t rustdesk-builder .

### How do I use a RustDesk server?

The README gives three options: use the project's rendezvous and relay server, set up your own through the server documentation, or write your own using the separate rustdesk-server-demo repository. Note that the repository you are reading is the client application, so running your own server means combining it with a separate server project.

### Is RustDesk the same as AnyDesk?

The README makes no comparison with AnyDesk. What it says about itself is that it is yet another remote desktop solution written in Rust, that it works with no configuration required, and that you can use the project's rendezvous and relay server, set up your own, or write your own, which is the distinction the project actually draws.

## Sources

- [Official documentation](https://rustdesk.com)
- [Official README](https://github.com/rustdesk/rustdesk#readme)
- [Project repository](https://github.com/rustdesk/rustdesk)
- [Release notes](https://github.com/rustdesk/rustdesk/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/rustdesk-rustdesk