RustDesk - Your remote desktop

Overview

RustDesk presents itself as a compact, robust remote desktop solution written in Rust, designed to provide direct, secure control over remote machines with minimal upfront configuration.
The core philosophy emphasizes user sovereignty over data: you decide where your data is stored, who can access it, and how connections traverse networks. This is reinforced by the option to operate your own rendezvous/relay server rather than relying solely on third‑party services.
The project welcomes contributions from the community and encourages collaboration across languages and regions, underscoring a multilingual ecosystem and open development flow.
The project acknowledges a cautionary note about misuse, stating clearly that unethical or illegal use is not condoned and that responsibility for how the software is used rests with the user. This stance is paired with accessible channels for discussion and support, including Discord, Twitter, Reddit, and YouTube.
An emphasis is placed on extensibility and transparency: developers can inspect, modify, and build upon the codebase, with explicit references to the repository structure and the accompanying server and client components. The project also highlights the availability of a proprietary‑style server option (RustDesk Server Pro) for advanced users seeking enhanced features.
Visual branding appears at the top of the document, setting the tone for a polished, user‑facing project. The logo serves as a recognizable entry point for readers who are exploring the documentation and the software’s capabilities.
A representative image is included to convey the look and feel of the software in operation, illustrating a typical deployment or usage scenario and helping readers imagine how the tool interplays with other systems.

Multilingual Reach and Community Involvement

The README invites readers to contribute by translating the documentation and the RustDesk user interface, signaling a deliberate effort to reach non‑English speaking audiences.
A comprehensive list of available translations is provided, spanning languages such as Ukrainian, Czech, Chinese, Hungarian, Spanish, Persian, French, German, Polish, Indonesian, Finnish, Malayalam, Japanese, Dutch, Italian, Russian, Brazilian Portuguese, Esperanto, Korean, Arabic, Vietnamese, Danish, Greek, Turkish, Norwegian, and Romanian. These entries point to localized README files that can be opened to view language‑specific instructions and nuances.
By inviting translators to participate in both the README and the UI localization, the project fosters a community around localization, UX consistency, and broader accessibility.

Features and Architectural Highlights

Rendezvous and relay architecture: readers are reminded that RustDesk can operate using its own rendezvous/relay infrastructure, meaning remote connections can be established even behind NATs and firewalls, which is central to a seamless remote access experience.
Data control and privacy: the design emphasizes that users retain ownership of their data, aligning with a security‑minded philosophy common to Rust‑based tooling.
Server options: readers are informed about the ability to deploy their own server infrastructure, offering administrators the option to host bespoke rendezvous/relay services for privacy, latency, or policy reasons.
Client and server roles: the README references both client and server components and points to distinct code paths (for example, client startup logic and server mediation components). This indicates a modular architecture where different pieces handle signaling, video/audio transport, file transfer, and input events.
Contribution and governance: the document signals an open culture with a dedicated CONTRIBUTING.md guide, inviting developers to participate in the project’s growth and improvement.

Dependencies and GUI choices

Desktop GUI options: the document notes that desktop builds use either Flutter or Sciter for the user interface. The current tutorial focuses on a Sciter‑based build, highlighting its simplicity and beginner‑friendly setup compared with Flutter in this context.
Flutter alternative: a link to the CI workflow for Flutter builds exists, suggesting that readers interested in the Flutter path can pursue a separate build route with its own dependencies and tooling.
Platform libraries: several dynamic libraries are required for the GUI, with explicit download links for Windows, Linux, and macOS. These libraries are essential for rendering the UI and enabling cross‑platform behavior.
Sciter library hosting: the build instructions provide direct URLs to the Sciter dynamic libraries, ensuring that developers can obtain the exact binary components needed to run the Sciter‑based interface.

Raw Steps to Build: Core Procedures

Development environment preparation: readers are advised to prepare a Rust development environment and a C++ build environment, which are prerequisites for compiling the core components.
Dependency management with vcpkg: the recommended approach involves installing vcpkg and configuring the VCPKG_ROOT environment variable. This step ensures that platform‑specific dependencies (such as video codecs, audio libraries, and other native components) can be resolved in a consistent manner across devices.
Platform‑specific library installation:
Windows: install libvpx, libyuv, opus, and aom with static builds to ensure compatibility and a compact runtime footprint.
Linux/macOS: install libvpx, libyuv, opus, and aom as native libraries via vcpkg.
Building via cargo: once the dependencies are in place, the process involves invoking cargo to build the Rust portions of the project, starting with cargo run to compile and launch a debug build.
Documentation and resources: the build instructions point to a dedicated development build page for more details and troubleshooting, indicating that the project provides a thorough reference for developers seeking to extend or debug the codebase.

How to Build on Linux: Platform‑Specific Guidance

Ubuntu 18 (Debian 10) environment: a suite of development packages is required to assemble a functional toolchain, including compilers, GTK, and multimedia libraries, as well as build tools such as cmake and ninja. The commands reflect a typical, dense setup tailored for a desktop Linux distribution.
openSUSE Tumbleweed: the approach is to install development packages via zypper, covering compilers, GTK, X11 tools, CMake, ring‑buffering libraries, and PAM. The emphasis is on a modern, rolling‑release Linux environment with current system libraries.
Fedora 28 (CentOS 8) environment: the steps involve yum‑based installation of C/C++ toolchains, GTK, CLang, XCB libraries, XFixes, PulseAudio development headers, GStreamer stacks, and PAM modules, forming a comprehensive multimedia and input ecosystem for remote desktop operations.
Arch (Manjaro) environment: pacman is used to install essential build tools, unzip, git, cmake, compiler toolchain, GTK, xdotool, and XCB stacks, along with PipeWire for audio and video streams, reflecting Arch’s minimal, modular philosophy.
vcpkg installation loop: after the system toolchain is prepared, vcpkg is cloned, bootstrapped, and used to install core dependencies (libvpx, libyuv, opus, aom) across platforms, ensuring a uniform library set across builds.
Practical vpcpx fixes for Fedora: a special adjustment step is described for Fedora users to modify libvpx Makefiles to support position‑independent code and header includes, highlighting nuanced platform quirks that sometimes arise in real‑world builds.
Final build sequence: A sequence is provided that downloads the Rust toolchain, fetches the RustDesk repository with submodules, prepares the Sciter library, configures the environment, and executes cargo run to compile and run the debug build, with careful attention to locating resources and ensuring the Sciter binary is present.

How to Build with Docker

Initial setup: clone the RustDesk repository, initialize submodules, and build the Docker image named rustdesk-builder. This encapsulates the build environment and dependencies inside a container for reproducible builds.
Building inside the container: invoke docker run with a series of volume mounts that map the host project directory, the cargo git/cache directories, and a cargo registry cache into the container. Environment variables PUID and PGID are passed to preserve correct file ownership when files are emitted on the host.
Reproducibility and caching: the documentation emphasizes that the first build may take longer, as dependencies are cached on subsequent runs, resulting in faster rebuilds.
Custom build arguments: readers can append their own cargo arguments (for example, --release) to tailor the build to a particular target (debug vs. release) or to optimize performance for production use.
Output location and execution: the final compiled binaries appear in the target directory on the host, where they can be run directly (for example, target/debug/rustdesk for a debug build or target/release/rustdesk for a release build). The command sequence stresses running from the repository root so that resources can be located correctly.

File Structure and Component Overview

libs/hbb_common: a library group handling video codecs, configuration, TCP/UDP wrappers, protobuf, file transfer utilities, and miscellaneous helper functions. This area appears to be a core backbone for data handling and interprocess communication.
libs/scrap: a library focused on screen capture capabilities, enabling remote viewing of host desktops.
libs/enigo: platform‑specific input control utilities for keyboard and mouse interactions, a critical piece for remote control fidelity.
libs/clipboard: an implementation of copy/paste across Windows, Linux, and macOS, ensuring seamless clipboard data transfer between host and remote systems.
src/ui: an obsolete Sciter UI layer (deprecated), indicating a historical GUI path that has since been superseded by newer approaches.
src/server: a suite of services for audio, clipboard, input, video, and network connections that powers the server side of the remote session, including signal handling and media transport.
src/client.rs: entry point to start a peer connection, forming the client side of the remote session flow.
src/rendezvous_mediator.rs: the component responsible for mediating communication with the rustdesk-server, awaiting remote direct connections via TCP hole punching or relayed paths when necessary.
src/platform: a collection of platform‑specific code that adapts functionality to Windows, Linux, and macOS symptoms and idiosyncrasies.
flutter: the Flutter codebase for desktop and mobile clients, representing an alternative UI framework under the RustDesk umbrella.
flutter/web/js: JavaScript assets used for the Flutter web client, illustrating how the project branches into web presence and cross‑platform experiences.

Screenshots and Visual Proof of Concept

Connection Manager: an image showing the user interface that orchestrates connections to remote machines, featuring status indicators, device lists, and connection controls.
Connected to a Windows PC: a visual demonstration of a live remote session in progress, highlighting cross‑platform capability and the practical usability of the remote desktop experience for Windows hosts.
File Transfer: an illustration of file management workflows during a remote session, underscoring the ability to transfer data between host and client seamlessly.
TCP Tunneling: a depiction of the network tunneling aspect, emphasizing how RustDesk can traverse restrictive network environments through its relay or direct paths.
The visual identity is reinforced by a prominent badge for RustDesk Server Pro, signaling advanced features for users seeking enhanced performance and additional capabilities beyond the base offering:
RustDesk Server Pro badge: Advanced Features (blue), positioned as a mark of upgraded server functionality.
Additional badges and distribution channels demonstrate the project’s ecosystem:
“Get it on F-Droid” badge, pointing to an Android distribution channel.
“Get it on Flathub” badge, indicating availability through the Flathub app store.
Embedded logos and assets:
A header logo graphic (RustDesk logo) anchors the documentation visually.
A developer‑facing image illustrating the project’s branding and identity is included near the introduction to reinforce recognition.

Getting Involved, Help, and Further Resources

Documentation and help: the README points readers to a dedicated FAQ, a general documentation page, and a development build guide. Readers interested in Flutter builds can consult a separate CI workflow file dedicated to Flutter builds.
Contribution workflow: contributors are encouraged to review and follow the CONTRIBUTING.md guidelines, with practical tips on getting started, setting up development environments, and submitting improvements.
Server and hosting choices: readers can explore the option to set up their own rendezvous/relay server, or even write a custom rendezvous/relay server that integrates with the RustDesk ecosystem. This flexibility supports varied deployment scenarios, from personal, on‑premise setups to scalable enterprise configurations.
Official channels for community support: Discord, Twitter, Reddit, and YouTube are highlighted as venues where users and developers can discuss features, report issues, and collaborate on improvements.
Release and distribution information: references to binary downloads, nightly builds, and distribution packages (such as F‑Droid and Flathub) provide pathways for testing, experimentation, and production deployment.

Implementation Nuances and Developer Notes

Dependency handling across platforms: the documentation emphasizes the use of vcpkg to manage platform libraries, ensuring a consistent cross‑platform dependency graph that minimizes build failures due to missing headers or libraries.
Sciter versus Flutter: the guidance to use Sciter for the initial tutorial reflects a practical choice for ease of setup and a gentle learning curve. The Flutter route is acknowledged as a parallel path with its own CI workflow, suggesting a future or alternative development track for those who prefer Flutter’s widget system.
Dynamic library provisioning: explicit instructions for downloading the Sciter dynamic library for Windows, Linux, and macOS are provided, underscoring the necessity of these runtime components for rendering the GUI. This ensures that developers can reproduce a stable build environment.
Build reproducibility and caching: Docker integration is presented as a robust method to achieve reproducible builds, with a focus on caching behavior to expedite iterative development cycles after the initial setup.
Resource location discipline: attention to file locations and resource discovery is highlighted, with reminders to run commands from the repository root to ensure resources are found correctly during runtime.

Quick Reference: Practical Commands (condensed)

Clone and prepare the repository with submodules:
git clone https://github.com/rustdesk/rustdesk
cd rustdesk
git submodule update --init --recursive
Docker build (quick start):
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
Local Linux build (high level):
Prepare dependencies for your distro (Ubuntu, openSUSE, Fedora, Arch) including compilers, GTK, CMake, and multimedia libraries.
Install vcpkg and dependencies:
- git clone https://github.com/microsoft/vcpkg
- cd vcpkg
- git checkout 2023.04.15
- ./bootstrap-vcpkg.sh
- export VCPKG_ROOT=$HOME/vcpkg
- ./vcpkg/vcpkg install libvpx libyuv opus aom
Build RustDesk:
- 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
Floating notes:
The first build may take longer as dependencies are cached; subsequent builds are faster.
For optimized releases, append --release to the cargo command.
Ensure to run commands from the repository root to locate resources correctly.

Visual Summary and Closing Thoughts

The RustDesk documentation blends practical build instructions with a broad view of the project’s architecture, accessibility, and community dynamics. It communicates an emphasis on privacy, user control, and the flexibility to operate in distributed or centralized server environments.
The inclusion of diverse language translations, multiple distribution channels, and clear calls for community involvement signals an ambitious project intent: to become a dependable, cross‑platform remote desktop solution with an open, collaborative ecosystem.
The combination of core libraries for video, screen capture, input control, and clipboard integration, along with server mediation logic and cross‑platform considerations, gives a sense of a mature, modular architecture designed to be extended and adapted to various deployment contexts.
The visual assets—logo, live operation images, and feature badges—enhance the narrative by providing tangible impressions of the user experience, the remote session workflow, and the project’s professional branding.

Images embedded from the Input