Devices and Device Groups
Every machine running a RustDesk client that points at CortenDesk as its API Server appears here. Devices register themselves — you do not add them by hand, though you can pre-register one before it ever connects.
The client sends a heartbeat to CortenDesk roughly every 15 seconds, and a
sysinfo payload with its hostname, platform and version. A device CortenDesk
has never seen is created on its first heartbeat.
If nothing shows up, the client's API Server is not set or cannot reach the console. See Troubleshooting.
A device counts as online when its last heartbeat is inside the online
window — online_window, 60 seconds by default, in Settings → Server.
Raise it if you have flaky links and devices flicker between states.
The list filters by all, online, offline, and the recycle bin.
Open a device to set:
| Field | Notes |
|---|---|
| Alias | A friendly name. Shown instead of the hostname throughout the console. |
| Device group | The "folder" it belongs to. Drives access — see below. |
| Assigned user | The owner. A non-admin sees their own devices. |
| Strategy | A device policy pinned to this device. |
| Note | Free text. |
The RustDesk ID itself is only editable when pre-registering.
Clicking a device ID opens rustdesk://<id>, which hands off to the installed
desktop client. The web client is launched from the same row.
Device groups are folders and the unit of access control. A device belongs to at most one group.
Access is granted two ways:
- directly to a user, or
- to a user group, which grants it to every member
An administrator always sees everything. A non-administrator sees their own assigned devices plus any device group granted to them or to a user group they belong to. This scoping applies to the console and to the RustDesk client API, so a user's client only ever receives devices they are entitled to.
Read Users and access scoping before designing your group layout — the two features only make sense together.
Create a device before it exists by entering its RustDesk ID. Set the alias, group, owner and strategy up front. When the real client first heartbeats with that ID it adopts the record instead of creating a new one.
Useful when you image machines and want them landing in the right folder with the right policy from their first connection.
Settings → Security → require device approval, off by default.
With it on, a device that registers for the first time is created with status
pending instead of active. Pending devices are held in a separate tab and do
not appear in the normal list until an administrator approves them. Rejecting one
removes it.
Turn this on when you do not want an unknown machine appearing in the fleet just because someone pointed a client at your server. Devices already approved are unaffected when you toggle it.
Deleting a device is a soft delete. It moves to the recycle bin, where it can be restored or permanently deleted.
A recycled device stays invisible to the console and its heartbeats are deliberately ignored — the client keeps running and keeps trying, but presence is not recorded and nothing is created. That is what stops a deleted machine reappearing on its own 15 seconds later. Restore it and presence resumes.
- Users and access scoping
- Strategies (device policies)
-
Automation API — create, assign, enable and disable devices
from scripts, including the client's
--assignflag