Features
Everything the console does
Grouped roughly the way you meet them: the fleet first, then who can reach it, then what you push to it, then the record of what happened.
Devices
Fleet and folders
Machines register themselves the first time a client points at the console. Device groups act as folders and as the unit of access control — a device belongs to exactly one.
- Presence, platform, client version and last-seen
- Aliases, owners, notes and per-device policy
- Pre-register by ID before a machine is built
- Optional approval gate for unknown devices
- Recycle bin — a deleted device stays deleted
Users and access
Who can reach what
Administrators see everything. Everyone else sees the devices assigned to them plus any folder granted to them or to a group they belong to.
- User groups, so grants are made once
- Disable an account without deleting it
- Force logout revokes sessions and client tokens together
Delegated administration
Hand over one screen, not the keys
A role is a permission matrix over each console area, set to None, View or Manage. Roles govern what somebody can do — they never widen which devices somebody can see.
- Devices, users, groups, address books, logs, policies, settings, tokens
- Sign-in history and the console audit trail sit behind Manage, not View
- A role can require two-factor of everyone assigned to it
Device policies
Strategies
Client settings pushed from the console and applied on the next heartbeat. Assign to a device, a user or a folder; the most specific assignment wins, and exactly one policy is ever in force.
- Permissions — keyboard, clipboard, file transfer, audio, camera and more
- Security — approval mode, password rules, IP allowlist, idle disconnect
- Capture and display behaviour
- Leave anything unmanaged and the device keeps its own value
- Enforce, and a change made locally is reverted within a minute
Address books
Shared peer lists
Every user gets a personal book. Shared books are handed out with per-book rules — to everyone, to a person, or to a group — as read, read/write or full control.
- Coloured tags for organising a large book
- Modern multi-book API and the legacy single-book API
- A read-only book is read-only in the client too
Audit
A record of what happened
Five logs: connections, file transfers, sign-ins, security alarms and console actions. All filterable, all exportable to CSV.
- Alarms from the clients and from the console's own sign-in limiter
- Retention in days, with automatic nightly pruning
- Active sessions on the dashboard, endable by an administrator
Identity and automation
Signing in, and scripting it
Single sign-on (OIDC)
Authorization-code flow with PKCE and verified ID tokens. Just-in-time account creation with optional approval, an email-domain allowlist and optional provider sign-out. Works for the console and for RustDesk client sign-in.
Two-factor authentication
TOTP with single-use recovery codes. Optionally required for everyone or for administrators only, with an administrator reset and a command-line way back in.
Automation API
Scoped bearer tokens over a REST API covering users, devices, groups, address books and audit logs. A token can never hold more permission than whoever issued it.
SMTP with a test send that reports the provider's own error. Invitations, self-service password reset, and an optional emailed code when signing in from an unrecognised browser.
Fallback access
A client in the browser, for when you cannot install one
Use the official RustDesk clients. They are the supported, polished way to connect, and nothing here changes that.
The built-in browser client exists for the times you cannot — a machine you are not allowed to install software on, a borrowed computer, or an urgent connection from somewhere unfamiliar. It is a genuine implementation of the RustDesk protocol rather than a viewer, and it does view, control and file transfer. It is also newer and less polished than the desktop clients, so treat it as the way in when the usual way is not available.
Better over HTTPS
With TLS it decodes VP8, VP9, H.264, H.265 and AV1 in hardware. Over plain http:// it falls back to H.264 automatically — fewer codecs, same session.
Chrome or Edge
The screen stream needs WebCodecs. Other browsers may not carry it.
Policies still apply
Permissions are enforced by the device, so a strategy that disables file transfer disables it here too.
Try it against your own server
It needs a RustDesk server you already run, and three values from it.