For devices that can already reach each other
SubnetDesk is an independently maintained RustDesk fork for LANs, private links, home labs and VPN-connected networks. It needs no public device ID, rendezvous server or Internet relay: you choose the target hostname, IP address and port.
Use it to operate an office workstation, maintain a home-lab computer or provide support through an existing VPN. It does not create a VPN or automatically make unreachable devices reachable.
| Task | Native client | Optional browser access |
|---|---|---|
| View the screen and choose a display | Supported according to host capabilities | Supported with a compatible WebCodecs browser |
| Keyboard and pointer control | Subject to host permissions | control or collaboration profile |
| Clipboard collaboration | Subject to session and host settings | Text clipboard in collaboration mode |
| File transfer and remote audio | Native capabilities, platform- and permission-dependent | Not currently exposed |
| Restart, recording, privacy mode and other administration | Depends on native client and platform capabilities | Not currently exposed |
Automatic mDNS discovery
Find nearby devices on the LAN, then use recent devices, favorites and local aliases to return to frequently used computers. Stable identity distinguishes machines; a familiar display name alone is not proof of trust.
Routed networks, guest Wi-Fi and VPNs may not carry mDNS. A device missing from discovery may still be reachable by hostname or IP.
Direct hostname and IP connections
Connect using a hostname or IP plus port. Native connections use TCP 21118 by default; LAN settings can change it.
Configure a username and password on the receiving computer, enable the relevant service, and allow the controller’s source network. VPN routing is your responsibility, and the firewall, routes and CIDR allowlist must match the actual connection.
Open only the necessary ports to trusted source networks. Do not disable the entire firewall for troubleshooting or expose a LAN-oriented tool to an untrusted public network.
Remote desktop, displays and input
View and operate the remote desktop with the mouse and keyboard. The native session toolbar provides display selection, scaling and quality-related controls. Multiple displays, codecs and hardware acceleration depend on both endpoints.
The host can restrict input and session capabilities. Use view-only access when observation is sufficient; changing a viewer setting does not grant unauthorized input.
macOS needs the applicable Screen Recording and Accessibility permissions. Elevated Windows applications, locked desktops and background-service scenarios also depend on installation mode and OS privileges.
File transfer, clipboard and audio
Transfer files between endpoints
The native client provides file transfer for sending documents, retrieving results or managing files during support. Read and write access still depend on session permissions, the selected directory and operating-system access. A connected desktop is not unrestricted filesystem authorization.
Collaborate through the clipboard
Relay clipboard content according to host and session settings to avoid retyping addresses and text. Clipboard data can be sensitive: turn the feature off when unnecessary, and distinguish it from file transfer and the browser’s text-only clipboard.
Hear remote audio
Native clients can carry host audio on supported platforms with the necessary permissions. Audio devices, system versions and session settings affect availability; identical behavior across every device, background state or browser session is not promised.
Optional browser remote access
SubnetDesk already includes browser access; it is not limited to native clients. The desktop must explicitly enable Web access and configure listen addresses, allowed networks and hostnames. The browser connects to your own host, not a public cloud remote-desktop service.
- view-only: view the screen.
- control: view and operate it with keyboard, pointer or text entry.
- collaboration: add text clipboard collaboration, subject to browser permission.
The gateway is HTTPS-only. Configure and trust the generated local certificate through a trusted process, or supply a certificate matching the hostname. Do not blindly bypass an unfamiliar certificate warning. A working WebCodecs decoder is also required.
Browser sessions currently do not expose file transfer, audio, remote restart, recording, blocking local input or privacy mode. The access password is used for the current connection and is not stored in browser storage. Browser access can help when installing a controller is inconvenient; full file and administration tasks still belong in native clients.
Identity and access boundaries
- Username and password: explicitly configured on the receiving host; passwords are stored as Argon2id hashes.
- Device fingerprint: verify over a separate trusted channel on first connection, then retain the identity. Investigate changes, including reinstalls or replacement devices, instead of accepting blindly.
- CIDR allowlist: restrict incoming source networks, including actual VPN source addresses.
- Capability permissions: viewing, control, files and other operations remain subject to host and session policies.
Direct connectivity reduces public-service dependencies; it does not remove authentication or make every open port safe.
Get started in three steps
- Prepare the host: install and open SubnetDesk, configure LAN credentials, discovery and the listening port, then grant necessary screen and input permissions.
- Find the target: ensure routes and TCP 21118—or your configured port—are reachable. Select a discovered device or enter its hostname/IP and port.
- Verify and connect: confirm the fingerprint, authenticate with the configured credentials, then choose a desktop or file task.
Browser access additionally needs its own enabled Web service, trusted HTTPS certificate and permission profile. The native connection port is not automatically a website address.
Platforms and installation
Release downloads cover Windows, macOS, Linux and Android. See installers and release information for architectures and formats. There is currently no official iOS installer; browser capability does not imply a released native iOS client.
- Windows: installed and portable builds can differ in background-service and privilege behavior.
- macOS: check Screen Recording and Accessibility first.
- Linux: Wayland capture and input depend on the compositor and can require interactive permission after login. Unattended access to a Wayland login screen is not guaranteed. Address actual SELinux denials with a narrow policy rather than globally disabling protection.
- Android: controlling another device and sharing the Android device’s screen are different roles. Capture, accessibility input, files and audio depend on system permissions and version.
Updates and network requests
Windows and macOS desktop builds implement signed updates: check availability, read release notes, choose automatic downloads and install after verification. Update checking is enabled by default and automatic downloading is off by default. Full in-app delivery requires a build configured with trusted signing information.
Checks and downloads contact the configured update source, GitHub by default. No public relay dependency does not mean no network requests. On isolated networks, disable automatic checks and use your own manual software-distribution process. Linux and Android follow their package and installation channels.
Common questions
| Symptom | First checks |
|---|---|
| A device is missing | LAN discovery, mDNS and guest-network isolation; try a manual address |
| Discovered but connection fails | Service readiness, credentials, TCP port, routes and CIDR |
| Black screen or input failure | Host capture/input permissions, active desktop session and OS privilege levels |
| Browser displays a screen but cannot control or copy | Web permission profile and browser permission; view-only behavior is intentional |
| In-app update is unavailable | Trusted update-signing configuration; use the official release page if needed |
When it is not a fit
- Devices have no reachable network and no VPN will be configured.
- The workflow depends on public device IDs, rendezvous or Internet relays.
- A released native iOS client is essential, or the browser must offer every native administration feature.
Source and license
The public GitHub repository uses AGPL-3.0; consult its license text for the terms. Continue with the browser guide, Linux host notes or official release.
Return to the product overview for representative interfaces and downloads.