Introduction
This guide explains Install and Set Up RustDesk on Ubuntu 24.04 in a production-aware way, including the design choices, implementation checks, and operational safeguards that matter for Linux environments.
Prerequisites
Use a supported release, a tested backup, administrative access, a maintenance window when required, and a rollback plan. Validate DNS, time synchronization, firewall rules, storage, and monitoring before implementation.
Architecture and Core Concepts
Understand the data flow, trust boundaries, dependencies, and the expected state before changing a live environment. Separate control-plane configuration from data-plane traffic and document every external dependency.
Configuration and Validation
Apply the smallest configuration that satisfies the requirement. Keep environment-specific values in a secret-managed configuration, validate syntax before reload, and verify the result from both the service and client perspectives.
Security Considerations
Production safety
- Do not expose management interfaces or databases to the public Internet.
- Store passwords, tokens, and private keys outside the article and source repository.
- Patch dependencies, restrict administrative access, and retain audit logs.
Before you start
RustDesk lets you view and control another computer remotely. This guide uses Ubuntu Desktop 24.04 and the official deb package. You need internet access and a sudo account. A server with no desktop needs a different setup.
At the time of writing, 14 October 2026, the official latest stable release is 1.5.0. For a later installation, check the Latest release link below; nightly builds are development builds.
1. Download and install
Open Terminal with Ctrl+Alt+T and check the package architecture.
dpkg --print-architectureThe commands below are for amd64, the usual Intel/AMD 64-bit desktop. If the result is arm64, download the AArch64 Ubuntu deb from the release page and install that local file instead.
sudo apt update
sudo apt install -y curl ca-certificates
mkdir -p ~/Downloads/rustdesk-install
cd ~/Downloads/rustdesk-install
curl -fL --show-error https://github.com/rustdesk/rustdesk/releases/download/1.5.0/rustdesk-1.5.0-x86_64.deb -o rustdesk-1.5.0-x86_64.deb
sudo apt install ./rustdesk-1.5.0-x86_64.debContinue only after the download finishes successfully. apt installs the local package and resolves its dependencies. The ./ before the filename matters.
2. Open RustDesk and connect
rustdeskRun it as your normal desktop user, or open it from the application menu. You will see this device’s ID and temporary password. Wait until the application reports that it is ready.
Install RustDesk on the other computer, enter the Ubuntu device ID in the remote device field and connect. Approve the request on Ubuntu, or enter the temporary password on the connecting computer. For the first test, keep someone at the Ubuntu desktop.
The default public connection service is enough for this first test. If your workplace uses its own RustDesk server, enter the administrator’s ID Server, Relay Server and Key in network settings on both devices.
3. If the screen is black or input does not work
Ubuntu 24.04 commonly uses Wayland. RustDesk documents its Wayland support as experimental, and screen sharing can require local approval. Check the desktop session from its terminal.
echo "$XDG_SESSION_TYPE"If it says wayland, approve any screen-sharing prompt first. If trouble remains, log out, select your user on the login screen, choose Ubuntu on Xorg from the gear menu and log in again. Logging out closes your applications, so save your work first.
Access to the login screen requires X11 according to the official Linux guide. If you need access after a reboot, edit GDM configuration locally, under [daemon] set WaylandEnable=false, and reboot after saving your work. Changing only the user session does not change the login screen.
sudo nano /etc/gdm3/custom.conf[daemon]
WaylandEnable=false4. Optional: access without someone at the desk
In Settings → Security, unlock the settings if requested and set a strong permanent password. Share it only with trusted people. Check the installed service, then test again after a reboot; a password alone does not remove Wayland’s permission prompts.
systemctl status rustdesk --no-pagerIf the installed service is inactive, start it and enable it at boot.
sudo systemctl enable --now rustdeskUpdates and quick troubleshooting
For an update, download the newer official deb for your architecture and install it with sudo apt install ./FILENAME.deb, replacing FILENAME with its actual name. This direct deb installation does not add a RustDesk apt repository.
If the application is not ready, check internet access on both computers and any custom server settings. If you see Permission denied during download, use the Downloads folder above. If the screen is black, return to the Wayland step. You do not need to disable the firewall or configure port forwarding for the default first connection.
Once the Ubuntu desktop appears on the second computer and you can move the pointer, the basic setup is complete. These commands were checked against official documentation; they were not executed on an Ubuntu machine for this article.
Best Practices
- Version-control configuration and review changes.
- Use least privilege and explicit allow-lists.
- Automate repeatable checks and monitor the expected state.
- Test upgrades and restores before production rollout.
Conclusion
A reliable implementation of Install and Set Up RustDesk on Ubuntu 24.04 is more than a successful first run. Keep the configuration documented, observable, recoverable, and aligned with the team's change-management process.
Frequently Asked Questions
Can this procedure be used in production without a maintenance window?
Only when the platform documents a safe reload or the change is isolated and rollback-tested; otherwise schedule a maintenance window.
What should be backed up before making the change?
Back up configuration, credentials held by the service, application data, and the current version of the deployment. Test the restore path.
How do I verify that the change really took effect?
Check the service health endpoint or status, inspect logs and metrics, and run a representative client-side test from the intended network zone.
What is the first check for a timeout or connection refusal?
Check listening ports, routing, firewall policy, DNS resolution, and whether the service is bound to the expected interface.
How should secrets and tokens be handled?
Use a secret manager or protected environment configuration, rotate them after exposure, and never commit them to Git or paste them into tickets.
How can this be automated safely?
Automate idempotent checks first, add dry-run support, require review for destructive operations, and emit logs and exit codes suitable for monitoring.
What should be monitored after deployment?
Monitor availability, error rate, latency, resource saturation, certificate expiry, failed jobs, and configuration drift.
When should I roll back instead of troubleshooting in place?
Rollback when the service is unavailable, data integrity is at risk, or the blast radius is growing faster than you can isolate it. Preserve logs first.
