more blogs

2026-07-12 17:53:45 +00:00 · 2026-07-09 11:16:05 +08:00
parent 8e5b554639
commit bc29d68890
124 changed files with 5849 additions and 6 deletions
@@ -7,3 +7,207 @@
  for = "/_astro/*"
  [headers.values]
    Cache-Control = "public, max-age=31536000, immutable"
+
+[[redirects]]
+  from = "/blog/teamviewer-vs-anydesk-vs-splashtop"
+  to = "/blog/teamviewer-vs-splashtop"
+  status = 301
+  force = true
+
+[[redirects]]
+  from = "/ar/blog/2024/10/muayinat-rustdesk-web-client-v2"
+  to = "/ar/blog/muayinat-rustdesk-web-client-v2"
+  status = 301
+  force = true
+
+[[redirects]]
+  from = "/ar/blog/2024/12/tashghil-flutter-3-24-ala-windows-7"
+  to = "/ar/blog/tashghil-flutter-3-24-ala-windows-7"
+  status = 301
+  force = true
+
+[[redirects]]
+  from = "/ar/blog/2025/02/tahsin-acl-fi-rustdesk-server-pro-1-5-0"
+  to = "/ar/blog/tahsin-acl-fi-rustdesk-server-pro-1-5-0"
+  status = 301
+  force = true
+
+[[redirects]]
+  from = "/blog/2024/10/rustdesk-web-client-v2-preview"
+  to = "/blog/rustdesk-web-client-v2-preview"
+  status = 301
+  force = true
+
+[[redirects]]
+  from = "/blog/2024/12/how-to-make-flutter-3-24-run-on-windows-7"
+  to = "/blog/how-to-make-flutter-3-24-run-on-windows-7"
+  status = 301
+  force = true
+
+[[redirects]]
+  from = "/blog/2025/02/enhanced-acl-in-rustdesk-server-pro-1-5-0"
+  to = "/blog/enhanced-acl-in-rustdesk-server-pro-1-5-0"
+  status = 301
+  force = true
+
+[[redirects]]
+  from = "/de/blog/2024/10/vorschau-rustdesk-web-client-v2"
+  to = "/de/blog/vorschau-rustdesk-web-client-v2"
+  status = 301
+  force = true
+
+[[redirects]]
+  from = "/de/blog/2024/12/flutter-3-24-unter-windows-7-ausfuehren"
+  to = "/de/blog/flutter-3-24-unter-windows-7-ausfuehren"
+  status = 301
+  force = true
+
+[[redirects]]
+  from = "/de/blog/2025/02/erweiterte-acl-in-rustdesk-server-pro-1-5-0"
+  to = "/de/blog/erweiterte-acl-in-rustdesk-server-pro-1-5-0"
+  status = 301
+  force = true
+
+[[redirects]]
+  from = "/es/blog/2024/10/vista-previa-cliente-web-rustdesk-v2"
+  to = "/es/blog/vista-previa-cliente-web-rustdesk-v2"
+  status = 301
+  force = true
+
+[[redirects]]
+  from = "/es/blog/2024/12/ejecutar-flutter-3-24-en-windows-7"
+  to = "/es/blog/ejecutar-flutter-3-24-en-windows-7"
+  status = 301
+  force = true
+
+[[redirects]]
+  from = "/es/blog/2025/02/acl-mejoradas-rustdesk-server-pro-1-5-0"
+  to = "/es/blog/acl-mejoradas-rustdesk-server-pro-1-5-0"
+  status = 301
+  force = true
+
+[[redirects]]
+  from = "/fr/blog/2024/10/apercu-client-web-rustdesk-v2"
+  to = "/fr/blog/apercu-client-web-rustdesk-v2"
+  status = 301
+  force = true
+
+[[redirects]]
+  from = "/fr/blog/2024/12/executer-flutter-3-24-sous-windows-7"
+  to = "/fr/blog/executer-flutter-3-24-sous-windows-7"
+  status = 301
+  force = true
+
+[[redirects]]
+  from = "/fr/blog/2025/02/acl-ameliorees-rustdesk-server-pro-1-5-0"
+  to = "/fr/blog/acl-ameliorees-rustdesk-server-pro-1-5-0"
+  status = 301
+  force = true
+
+[[redirects]]
+  from = "/it/blog/2024/10/anteprima-client-web-rustdesk-v2"
+  to = "/it/blog/anteprima-client-web-rustdesk-v2"
+  status = 301
+  force = true
+
+[[redirects]]
+  from = "/it/blog/2024/12/eseguire-flutter-3-24-su-windows-7"
+  to = "/it/blog/eseguire-flutter-3-24-su-windows-7"
+  status = 301
+  force = true
+
+[[redirects]]
+  from = "/it/blog/2025/02/acl-migliorate-rustdesk-server-pro-1-5-0"
+  to = "/it/blog/acl-migliorate-rustdesk-server-pro-1-5-0"
+  status = 301
+  force = true
+
+[[redirects]]
+  from = "/ja/blog/2024/10/rustdesk-web-client-v2-preview-ja"
+  to = "/ja/blog/rustdesk-web-client-v2-preview-ja"
+  status = 301
+  force = true
+
+[[redirects]]
+  from = "/ja/blog/2024/12/flutter-3-24-windows-7-de-ugokasu-houhou"
+  to = "/ja/blog/flutter-3-24-windows-7-de-ugokasu-houhou"
+  status = 301
+  force = true
+
+[[redirects]]
+  from = "/ja/blog/2025/02/rustdesk-server-pro-1-5-0-acl-kyouka"
+  to = "/ja/blog/rustdesk-server-pro-1-5-0-acl-kyouka"
+  status = 301
+  force = true
+
+[[redirects]]
+  from = "/ko/blog/2024/10/rustdesk-web-client-v2-miribogi"
+  to = "/ko/blog/rustdesk-web-client-v2-miribogi"
+  status = 301
+  force = true
+
+[[redirects]]
+  from = "/ko/blog/2024/12/windows-7-flutter-3-24-silhaeng-haneun-bangbeop"
+  to = "/ko/blog/windows-7-flutter-3-24-silhaeng-haneun-bangbeop"
+  status = 301
+  force = true
+
+[[redirects]]
+  from = "/ko/blog/2025/02/rustdesk-server-pro-1-5-0-hyangsangdoen-acl"
+  to = "/ko/blog/rustdesk-server-pro-1-5-0-hyangsangdoen-acl"
+  status = 301
+  force = true
+
+[[redirects]]
+  from = "/pt/blog/2024/10/previa-cliente-web-rustdesk-v2"
+  to = "/pt/blog/previa-cliente-web-rustdesk-v2"
+  status = 301
+  force = true
+
+[[redirects]]
+  from = "/pt/blog/2024/12/executar-flutter-3-24-no-windows-7"
+  to = "/pt/blog/executar-flutter-3-24-no-windows-7"
+  status = 301
+  force = true
+
+[[redirects]]
+  from = "/pt/blog/2025/02/acl-aprimorada-rustdesk-server-pro-1-5-0"
+  to = "/pt/blog/acl-aprimorada-rustdesk-server-pro-1-5-0"
+  status = 301
+  force = true
+
+[[redirects]]
+  from = "/zh-cn/blog/2024/10/rustdesk-web-ke-hu-duan-v2-yu-lan"
+  to = "/zh-cn/blog/rustdesk-web-ke-hu-duan-v2-yu-lan"
+  status = 301
+  force = true
+
+[[redirects]]
+  from = "/zh-cn/blog/2024/12/ru-he-rang-flutter-3-24-yun-xing-yu-windows-7"
+  to = "/zh-cn/blog/ru-he-rang-flutter-3-24-yun-xing-yu-windows-7"
+  status = 301
+  force = true
+
+[[redirects]]
+  from = "/zh-cn/blog/2025/02/rustdesk-server-pro-1-5-0-zeng-qiang-acl"
+  to = "/zh-cn/blog/rustdesk-server-pro-1-5-0-zeng-qiang-acl"
+  status = 301
+  force = true
+
+[[redirects]]
+  from = "/zh-tw/blog/2024/10/rustdesk-web-yong-hu-duan-v2-yu-lan"
+  to = "/zh-tw/blog/rustdesk-web-yong-hu-duan-v2-yu-lan"
+  status = 301
+  force = true
+
+[[redirects]]
+  from = "/zh-tw/blog/2024/12/ru-he-rang-flutter-3-24-zai-windows-7-shang-zhi-xing"
+  to = "/zh-tw/blog/ru-he-rang-flutter-3-24-zai-windows-7-shang-zhi-xing"
+  status = 301
+  force = true
+
+[[redirects]]
+  from = "/zh-tw/blog/2025/02/rustdesk-server-pro-1-5-0-qiang-hua-acl"
+  to = "/zh-tw/blog/rustdesk-server-pro-1-5-0-qiang-hua-acl"
+  status = 301
+  force = true
@@ -0,0 +1,23 @@
+---
+export interface Props {
+  items?: Array<{ question: string; answer: string }>;
+}
+
+const { items = [] } = Astro.props;
+---
+
+{
+  items.length > 0 && (
+    <section aria-labelledby="post-faq-heading">
+      <h2 id="post-faq-heading">Frequently asked questions</h2>
+      <div>
+        {items.map((item) => (
+          <details>
+            <summary>{item.question}</summary>
+            <p>{item.answer}</p>
+          </details>
+        ))}
+      </div>
+    </section>
+  )
+}
@@ -136,6 +136,11 @@ if (type === 'software' || pageKind === 'pricing') {
 }

 if (type === 'article' && article) {
+  const articleAuthorSchema =
+    !article.author || article.author === 'RustDesk Team'
+      ? { '@id': `${siteOrigin}/#organization` }
+      : { '@type': 'Person', name: article.author };
+
  graphItems.push({
    '@type': 'BlogPosting',
    '@id': `${currentUrl}#article`,
@@ -144,10 +149,7 @@ if (type === 'article' && article) {
    url: currentUrl,
    datePublished: article.publishDate?.toISOString(),
    dateModified: (article.updateDate || article.publishDate)?.toISOString(),
-    author: {
-      '@type': 'Person',
-      name: article.author || 'RustDesk Team',
-    },
+    author: articleAuthorSchema,
    publisher: { '@id': `${siteOrigin}/#organization` },
    ...(article.image
      ? {
@@ -40,7 +40,7 @@ apps:

    post:
      isEnabled: true
-      permalink: '/blog/%year%/%month%/%slug%' # Variables: %slug%, %year%, %month%, %day%, %hour%, %minute%, %second%, %category%
+      permalink: '/blog/%slug%' # Variables: %slug%, %year%, %month%, %day%, %hour%, %minute%, %second%, %category%
      robots:
        index: true

@@ -62,6 +62,16 @@ const postCollection = defineCollection({
    category: z.string().optional(),
    tags: z.array(z.string()).optional(),
    author: z.string().optional(),
+    authorUrl: z.string().url().optional(),
+
+    faq: z
+      .array(
+        z.object({
+          question: z.string(),
+          answer: z.string(),
+        })
+      )
+      .optional(),

    metadata: metadataDefinition(),
  }),
@@ -0,0 +1,95 @@
+---
+publishDate: 2026-07-06T00:00:00Z
+lang: en
+translationKey: anydesk-alternative-self-hosted
+draft: false
+title: 'Best AnyDesk Alternative 2026: Own Your Data with RustDesk'
+excerpt: 'Comparing AnyDesk alternatives? See how RustDesk differs through open source, self-hosting, and plan-dependent concurrency.'
+image: ~/assets/images/blog/anydesk-alternative-self-hosted-og.png
+category: Alternatives
+tags:
+  - RustDesk
+  - AnyDesk
+  - alternative
+  - self-hosting
+author: RustDesk Team
+metadata:
+  description: "Looking for an AnyDesk alternative? Compare RustDesk's open-source, self-hosted model, licensing, and operational trade-offs."
+  keywords: 'AnyDesk alternative, self-hosted AnyDesk alternative, open source AnyDesk alternative, AnyDesk replacement'
+---
+
+## Why people are searching for an AnyDesk alternative
+
+Most people who look for an AnyDesk alternative aren't chasing a shinier feature list. They're reacting to two things: the bill going up, and the feeling that they no longer control their own remote-access setup.
+
+Buyers typically start this search after reviewing renewal costs, vendor dependence, or security requirements. AnyDesk publicly disclosed a security incident in early 2024; evaluate that event through public reporting rather than private customer correspondence.
+
+If that's roughly where you are, this page is for you. We'll be direct: RustDesk is a genuinely different model, and it isn't for everyone. Here's the honest version.
+
+## The core difference: rent access, or own it
+
+AnyDesk is a cloud service. Your sessions route through infrastructure the vendor owns, and you pay a subscription to keep the lights on. When they change the price or the terms, you adapt.
+
+RustDesk flips that. **RustDesk Server Pro is self-hosted** — the ID/rendezvous server, relay, console, and stored deployment data run on _your_ infrastructure. Direct sessions still flow between endpoints; relayed traffic uses the relay you configure.
+
+And **RustDesk's core is [open source (AGPL)](/blog/case-for-open-source-remote-access)**. You can read the code, audit what the client does, build it yourself, and run the free community server indefinitely.
+
+## AnyDesk vs. RustDesk at a glance
+
+|                                                                       | AnyDesk                     | RustDesk                                                                          |
+| --------------------------------------------------------------------- | --------------------------- | --------------------------------------------------------------------------------- |
+| Hosting                                                               | Vendor cloud                | Self-hosted (your server)                                                         |
+| Source code                                                           | Proprietary                 | Open source (AGPL)                                                                |
+| Where your data lives                                                 | Vendor infrastructure       | Infrastructure you control                                                        |
+| [Concurrent connections](/blog/rustdesk-concurrent-connections-limit) | Plan-dependent              | Unlimited on standard plans; limited on Customized V2                             |
+| Licensing model                                                       | Per-seat cloud subscription | [Per login-user + per managed-device](/blog/rustdesk-pro-license-cost-how-to-pay) |
+| Try without sales call                                                | Varies                      | Free server today, or Pro trial on request                                        |
+
+For exact AnyDesk pricing and plan tiers, check their current pricing page — we don't quote competitor numbers we can't verify.
+
+## Benefit 1: Control the server-side infrastructure
+
+You choose where the rendezvous, relay, console, and device data run. Direct connections still travel between endpoints, and relayed traffic uses your configured relay, so self-hosting alone does not guarantee in-country traffic or GDPR compliance. See the [data-sovereignty guide](/blog/remote-desktop-data-sovereignty-gdpr).
+
+## Benefit 2: Choose the concurrency model
+
+A common licensing question is how simultaneous work is counted. RustDesk standard plans include unlimited concurrent connections, while Customized V2 has a defined concurrency allowance and charges for additional connections. All paid plans must also fit login-user and managed-device counts.
+
+The licensing is **per login-user + per managed-device, upgradeable any time (prorated)** — no per-channel model, no per-seat cloud subscription stacked on top. For the current per-unit rates, see [rustdesk.com/pricing](https://rustdesk.com/pricing).
+
+## Benefit 3: Built for MSPs and IT teams
+
+Self-hosting doesn't mean going without tooling. RustDesk Pro gives you a **[self-hosted web console](/blog/rustdesk-web-console-custom-client-generator-port-21114), a custom-branded client generator, and [device groups plus a shared address book](/blog/rustdesk-per-user-access-control-device-groups-shared-address-book)** for per-user access control. **[LDAP/SSO](/blog/rustdesk-active-directory-ldap-sso) (OIDC) is available from the Basic plan and up.**
+
+And it scales: RustDesk publishes [large-fleet planning guidance](/blog/rustdesk-scale-50000-200000-devices) for teams evaluating bigger environments.
+
+## The honest caveat: someone has to run the server
+
+Here's the trade-off we won't hide. Self-hosting means **someone on your side runs the server** — you provision a host, open ports, set up TLS, and patch it over time. It's not hard, but it isn't zero.
+
+If your team wants a fully managed SaaS with no server to maintain, RustDesk Server Pro is [self-hosted by design](/blog/why-self-host-remote-desktop-software) and is not that. Commercial rates can still change at renewal; the structural benefit is control of the server-side services, paired with the responsibility to operate them.
+
+Self-hosting is not guaranteed to have the lowest sticker price in every configuration. Model both products against the same user, device, concurrency, feature, infrastructure, and operational requirements. See [rustdesk.com/pricing](https://rustdesk.com/pricing).
+
+## A practical AnyDesk migration checklist
+
+Do not start by removing AnyDesk. Run both tools during a controlled pilot and validate the gaps that matter to your environment:
+
+1. Deploy the RustDesk ID and relay services and confirm direct and relayed sessions from outside your network.
+2. Reproduce attended support, unattended access, file transfer, multi-monitor, clipboard, and privilege-elevation workflows.
+3. Map AnyDesk users and address-book entries to RustDesk login users, device groups, and access rules.
+4. Generate and sign the required clients, then test OS permissions on Windows, macOS, Linux, Android, and iOS devices you actually support.
+5. Measure relay bandwidth and latency during peak concurrency instead of assuming a small lab represents production.
+6. Define rollback, key backup, patching, and monitoring ownership before the wider cutover.
+
+That pilot tells you whether the control gained through self-hosting is worth the operating work. It also exposes feature or platform dependencies before they become a migration outage.
+
+## Try it without a sales call
+
+You don't have to book a demo to find out if this fits.
+
+- **Self-host the free open-source community server today** — no cost, no expiry.
+- **Want to try the Pro features?** Email [sales@rustdesk.com](mailto:sales@rustdesk.com) to ask about current evaluation terms, or check [rustdesk.com/pricing](https://rustdesk.com/pricing) for standard plan rates.
+- **Prefer to see it first?** Watch a full [video demo](/blog/see-rustdesk-in-action) on the [RustDesk YouTube channel](https://www.youtube.com/@rustdesk) — no booking required.
+
+Start at [rustdesk.com](https://rustdesk.com) and see the code for yourself on [GitHub](https://github.com/rustdesk/rustdesk).
@@ -0,0 +1,125 @@
+---
+publishDate: 2026-07-07T00:00:00Z
+lang: en
+translationKey: anydesk-commercial-use-detected
+draft: false
+title: 'AnyDesk Commercial Use Detected: How to Fix It'
+excerpt: "Flagged for commercial use on AnyDesk's free version? Here's the official whitelist process, what counts as commercial use, and the self-hosted way to avoid it."
+image: ~/assets/images/blog/anydesk-commercial-use-detected-og.png
+category: Troubleshooting
+tags:
+  - AnyDesk
+  - troubleshooting
+  - licensing
+author: RustDesk Team
+faq:
+  - question: "Why does AnyDesk say 'commercial use detected' when I only use it personally?"
+    answer: "AnyDesk's free version is licensed for personal, non-commercial use only and uses automated detection to enforce that boundary. AnyDesk does not publish a reliable detection formula or official thresholds. If your personal use is classified incorrectly, use the official whitelist request."
+  - question: "How do I fix 'commercial use detected' on AnyDesk for personal use?"
+    answer: "Submit AnyDesk's official whitelist request with your AnyDesk address and an honest description of your personal use. AnyDesk reviews the request. If your use is genuinely commercial, the appropriate fix is a license or another tool whose terms cover that work."
+  - question: 'Is AnyDesk free for business use?'
+    answer: "No. AnyDesk's free version is for personal, non-commercial use. Remote work, organizational device administration, and support for customers or colleagues require commercial terms. Check AnyDesk's current terms for the authoritative definition."
+  - question: 'What counts as commercial use on AnyDesk?'
+    answer: 'Supporting clients or colleagues, remote work (including checking work email), server administration, managing devices for an organization, or any use you are paid for. Helping family and friends or reaching your own personal devices is personal use.'
+  - question: 'How does RustDesk avoid commercial-use detection?'
+    answer: "RustDesk's open-source community server does not implement AnyDesk's commercial-use classifier. Server Pro is commercially licensed and self-hosted, with limits determined by the purchased RustDesk plan rather than an AnyDesk free-tier detector. Standard RustDesk plans include unlimited concurrent connections; Customized V2 does not."
+metadata:
+  description: "AnyDesk flagging your personal use as commercial? Here's the official whitelist fix, what counts as commercial use, and how self-hosted RustDesk avoids it."
+  keywords: 'AnyDesk commercial use detected, AnyDesk personal use flagged, AnyDesk whitelist request, AnyDesk commercial use appeal'
+---
+
+You opened AnyDesk to reach your own home PC or help a family member and got a warning that **commercial use was detected**, or that you need a license for professional use. This guide explains the official review path, what the terms classify as commercial use, and the licensed alternatives when the flag is correct.
+
+AnyDesk's current [Terms & Conditions](https://anydesk.com/en/terms) reserve the free version for personal, non-commercial use and permit enforcement of that boundary. Start with the official review process when the classification is wrong; if the use is commercial, compare paid or self-hosted options instead of trying to evade the terms.
+
+## How to fix "commercial use detected" on your AnyDesk account
+
+AnyDesk publishes an official [whitelist request](https://anydesk.com/en/commercial-use) for people whose use really is personal and non-commercial. In outline:
+
+1. **Note your AnyDesk address (ID)** — the number shown when you open the client — for every device involved: the one you connect _from_ and the ones you connect _to_.
+2. **Open AnyDesk's official [commercial-use / whitelist request form](https://anydesk.com/en/commercial-use).**
+3. **Describe your actual usage honestly** — e.g. "I only use this to help my parents with their home PC," or whatever genuinely describes what you are doing.
+4. **Submit and wait for AnyDesk to review the case.** Use the contact path shown on the current form if you need to follow up.
+
+One of two things happens next: AnyDesk confirms personal use and whitelists you, or it concludes your usage is commercial and the flag stands. The appeal only helps when the flag was a genuine false positive — if your use really is commercial, neither the outcome nor a workaround changes that. We are also not going to walk you through the unofficial "delete the config files" reset tricks that circulate: they skirt AnyDesk's licensing terms and do nothing about whether your use actually counts as commercial.
+
+### What actually counts as "commercial use" here
+
+Per AnyDesk's own terms, **personal use** is non-professional — reaching your own devices or helping friends and family, with no direct or indirect payment involved. **Commercial (professional) use** — the kind a whitelist request will not, and should not, clear — includes:
+
+- Providing support to clients, customers, or colleagues
+- Remote work of any kind, including simply connecting to a work machine or checking work email
+- Any connection made in the course of a trade, business, or profession
+- Administering servers or managing multiple devices for an organization
+- Any use for which you are paid, directly or indirectly
+
+If you are doing any of that, AnyDesk's detection is working as intended, and the real fix is choosing a tool licensed for how you actually use it — which is where the rest of this guide picks up.
+
+## Why AnyDesk flags "commercial use"
+
+AnyDesk's free tier is licensed for personal use only, and [its terms allow enforcement](https://anydesk.com/en/terms) when use appears professional. AnyDesk does not publish a formula users can safely rely on, so connection counts, session lengths, device limits, or timeout durations from third-party posts should not be presented as official thresholds.
+
+The same licensing distinction exists in other remote-access products, including [TeamViewer's commercial-use classification](/blog/teamviewer-commercial-use-detected). For genuinely commercial support work, the warning is not a technical bug to work around; compare current paid plans or alternatives rather than relying on unofficial resets or private renewal anecdotes.
+
+So if the appeal does not apply to you — because your use genuinely is commercial — the real question becomes: pay up, or move to something without a commercial-use tripwire at all?
+
+## The core difference: own the server, skip the nagging
+
+AnyDesk supports direct client-to-client connections as well as sessions routed through its public network, as its [client settings documentation](https://support.anydesk.com/docs/settings) explains. Commercial-use detection therefore should not be explained as proof that every media stream crosses an AnyDesk relay. Enforcement can occur through the client, account, licensing service, and connection metadata without mandatory cloud relay of session media; AnyDesk does not publish the detector's formula.
+
+**RustDesk changes the enforcement point.** The ID/rendezvous server, relay, console, and stored deployment data run on infrastructure you control, so a remote-access SaaS is not classifying each session as personal or commercial. Direct sessions still flow between endpoints, and RustDesk's own commercial license terms still apply to Server Pro.
+
+On top of that, RustDesk's core client is open source under the [AGPL](/blog/case-for-open-source-remote-access). You can read the code, audit exactly what it does on your machines, build it yourself, and run the free community server indefinitely. That is the opposite of a black box watching your connection habits.
+
+## How the two models compare
+
+|                                                                       | AnyDesk free tier                                                 | RustDesk                                                                          |
+| --------------------------------------------------------------------- | ----------------------------------------------------------------- | --------------------------------------------------------------------------------- |
+| "Commercial use" detection                                            | Yes — can flag, throttle to short sessions, or block              | None — you host the server                                                        |
+| Session path                                                          | Direct when available; AnyDesk network relay otherwise            | Direct when available; your relay otherwise                                       |
+| Device allowance                                                      | Check current free-use terms                                      | Commercial plans count managed devices                                            |
+| Source code                                                           | Closed                                                            | Open source (AGPL), auditable                                                     |
+| [Concurrent connections](/blog/rustdesk-concurrent-connections-limit) | Gated on free tier                                                | Standard plans unlimited; Customized V2 limited                                   |
+| Pricing model                                                         | Per-seat cloud subscription                                       | [Per login-user + per managed-device](/blog/rustdesk-pro-license-cost-how-to-pay) |
+| Data boundary                                                         | Vendor services coordinate access; media can be direct or relayed | Server-side services on infrastructure you control; endpoint routes still matter  |
+
+For exact AnyDesk pricing and current free-tier limits, check their own terms directly — we won't quote numbers we can't stand behind.
+
+## No concurrent-connection gate on standard plans
+
+RustDesk standard plans include unlimited concurrent connections; Customized V2 limits and prices them separately. All paid plans must also fit their login-user and managed-device allowances.
+
+## Your data stays where you put it
+
+Self-hosting lets you control the rendezvous, relay, console, and stored device data. Direct sessions still travel between endpoints, so review the complete [data-sovereignty and GDPR implications](/blog/remote-desktop-data-sovereignty-gdpr) rather than assuming server location controls every packet.
+
+## Built for MSPs and IT teams
+
+If you are supporting clients — the exact use AnyDesk's flag exists to catch — you get the tooling to run it like a business: a [self-hosted web console](/blog/rustdesk-web-console-custom-client-generator-port-21114), a custom-branded client generator, and [device groups plus a shared address book](/blog/rustdesk-per-user-access-control-device-groups-shared-address-book) for per-user access control. [LDAP/SSO](/blog/rustdesk-active-directory-ldap-sso) (OIDC) is available from the Basic plan and up. Licensing is per login-user + per managed-device, you can [upgrade any time](/blog/upgrade-rustdesk-license-mid-subscription) (prorated), and there is no per-channel model or per-seat cloud subscription layered on top.
+
+For specific access-control, SSO, and client-generation availability by plan, [see rustdesk.com/pricing](https://rustdesk.com/pricing).
+
+## The honest caveat
+
+Self-hosting is the fix for commercial-use nagging, but it means _someone on your side runs the server_. You provision a host, open ports, set up TLS, and patch it over time. It is not a heavy lift for an IT team — but it is real work. If what you actually want is a [zero-maintenance managed SaaS](/blog/rustdesk-self-hosted-vs-cloud-saas-option) with no server to run, RustDesk Server Pro is [self-hosted by design](/blog/why-self-host-remote-desktop-software) and won't be that. Go in clear-eyed: you are trading a monthly bill and a commercial-use tripwire for a server you own and maintain.
+
+## Choose the fix that matches your use
+
+| Your situation                                          | Appropriate next step                                                                                      |
+| ------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------- |
+| Personal use was classified incorrectly                 | Submit AnyDesk's official whitelist request and keep the confirmation                                      |
+| You use AnyDesk for paid work or organizational support | Buy a license that covers that use or evaluate a commercial alternative                                    |
+| You need a free tool for business use                   | Compare the license terms of open-source servers; do not assume every free download permits commercial use |
+| You need infrastructure and policy control              | Pilot a self-hosted option, including server operations, access rules, logging, and client deployment      |
+
+For a RustDesk pilot, test the actual workflow that triggered the flag: the same technicians, endpoints, unattended sessions, and support volume. Also size both licensing dimensions—login users and managed devices—before treating “no commercial-use detection” as “no licensing requirements.”
+
+## What to do next
+
+You don't need a sales call to find out if this works for you:
+
+- **Self-host the free community server today.** It's open source, runs indefinitely, and has no commercial-use detection to trip.
+- **Want to try the Pro features?** Email [sales@rustdesk.com](mailto:sales@rustdesk.com) to ask about current evaluation terms, or check [rustdesk.com/pricing](https://rustdesk.com/pricing) for standard plan rates.
+- **Prefer to see it first?** Watch a full [video demo](/blog/see-rustdesk-in-action) on the [RustDesk YouTube channel](https://www.youtube.com/@rustdesk) — no booking required.
+
+Test the free community server or request current Pro evaluation terms before committing to an annual purchase.
@@ -0,0 +1,105 @@
+---
+publishDate: 2026-07-06T00:00:00Z
+lang: en
+translationKey: anydesk-price-increase-alternatives
+draft: false
+title: 'AnyDesk Price Increase: Alternatives for Teams'
+excerpt: "Another AnyDesk price increase pushing your budget? Here's how teams switch to a predictable, self-hosted, open-source remote desktop."
+image: ~/assets/images/blog/anydesk-price-increase-alternatives-og.png
+category: Guides
+tags:
+  - RustDesk
+  - AnyDesk
+  - pricing
+  - alternative
+author: RustDesk Team
+metadata:
+  description: 'Facing another AnyDesk price increase? See why teams switch to RustDesk: predictable self-hosted cost, your own data, and open-source transparency.'
+  keywords: 'AnyDesk price increase, AnyDesk renewal cost, AnyDesk pricing alternatives, AnyDesk three-year TCO'
+---
+
+If you searched for "AnyDesk price increase," compare your dated renewal quote with current alternatives and include migration and operating costs. Compare current public or written quotes.
+
+That is the trap of the subscription remote-desktop market. Your tooling cost is set by a vendor's roadmap, not yours. This guide is for teams — [MSPs](/blog/rustdesk-for-msps), internal IT, support desks — who are tired of that cycle and want a remote support solution with a cost they actually control. We'll be honest about the trade-offs, but the short version is: self-hosting changes who holds the pricing power.
+
+## Why the AnyDesk price increase keeps happening
+
+A cloud subscription is a recurring lever. The vendor owns the infrastructure your sessions run through, so renewal pricing, seat tiers, and channel counts are theirs to adjust. When they do, your only options are pay more or migrate — and migration is painful enough that most teams just pay.
+
+Cost is not the only consideration. Review public security disclosures, support terms, renewal mechanics, and the operational control each product gives you. AnyDesk's 2024 security incident is documented publicly.
+
+We're not going to invent numbers about AnyDesk's pricing — check their current rates yourself. The structural point stands: with a cloud subscription, the price and the terms are not yours to set.
+
+## Verify what actually increased
+
+Put the previous invoice, renewal quote, and current official plan page side by side. Normalize currency, tax, billing period, discount, user count, concurrent sessions, managed endpoints, support, and add-ons. A larger total can come from a rate change, a discount ending, increased usage, changed packaging, or several of those at once.
+
+Record the effective per-year cost and the exact entitlements in both quotes. That produces a defensible “price increase” figure for your organization. Third-party trackers and another customer's contract can provide context, but they cannot replace your dated documents.
+
+## The core difference: you host it, you control the cost
+
+RustDesk Server Pro is **self-hosted**. The ID/rendezvous server, relay, console, and stored deployment data run on infrastructure you control. Direct sessions still flow between endpoints; relayed sessions use your configured relay. The product still has annual license terms, so compare the current pricing page at each renewal.
+
+RustDesk licensing is **per login-user plus per managed-device**, and you can [upgrade](/blog/upgrade-rustdesk-license-mid-subscription) with proration. Standard plans include unlimited [concurrent connections](/blog/rustdesk-concurrent-connections-limit); Customized V2 limits and prices them separately.
+
+### Quick comparison
+
+| What you're evaluating     | Cloud subscription tools | RustDesk Server Pro                                                               |
+| -------------------------- | ------------------------ | --------------------------------------------------------------------------------- |
+| Where sessions run         | Vendor's cloud           | Your server (on-prem or your VPS)                                                 |
+| Who sets renewal pricing   | The vendor               | You host it; cost is your infrastructure + license                                |
+| Concurrent connections     | Often tiered/limited     | Unlimited on standard plans; limited on Customized V2                             |
+| Licensing model            | Per seat / per channel   | [Per login-user + per managed-device](/blog/rustdesk-pro-license-cost-how-to-pay) |
+| Source code                | Closed                   | [Open source (AGPL)](/blog/case-for-open-source-remote-access), auditable         |
+| Server-side data and relay | Vendor-operated          | Infrastructure you control; direct traffic still flows between endpoints          |
+
+For exact license prices and plan tiers, [see rustdesk.com/pricing](https://rustdesk.com/pricing).
+
+## Own your data — a real reason teams move
+
+Self-hosting lets you choose where the rendezvous, relay, console, and managed-device data run. It does not guarantee that direct endpoint traffic remains in one country or make a deployment compliant by itself. Map the full data flow and obligations in the [data-sovereignty guide](/blog/remote-desktop-data-sovereignty-gdpr).
+
+After a year in which remote-access vendors made headlines for security incidents — [AnyDesk disclosed a breach in early 2024](https://www.infosecurity-magazine.com/news/anydesk-hit-cyberattack-customer/), and a [separate ConnectWise ScreenConnect vulnerability](https://www.cisa.gov/news-events/alerts/2024/02/22/cisa-adds-one-known-exploited-connectwise-vulnerability-cve-2024-1709-catalog) was widely reported the same year — "where does my session actually go?" stopped being a theoretical question. Self-hosting gives you a concrete answer: your box.
+
+## Open source you can actually audit
+
+RustDesk's core is **open source under the AGPL.** You can read the code, verify what the client does, build it yourself, and run the free community server indefinitely.
+
+For MSPs and IT teams, Pro adds a [self-hosted web console](/blog/rustdesk-web-console-custom-client-generator-port-21114), a custom-branded client generator, and [device groups plus a shared address book](/blog/rustdesk-per-user-access-control-device-groups-shared-address-book) for per-user access control. [LDAP/SSO](/blog/rustdesk-active-directory-ldap-sso) (OIDC) is available from the Basic plan and up. RustDesk also publishes [large-fleet planning guidance](/blog/rustdesk-scale-50000-200000-devices) for bigger environments.
+
+## Renew-and-negotiate vs switch: the decision math
+
+When the renewal quote jumps, you really have two moves, and it's worth costing both honestly rather than reacting reflexively.
+
+**Renew and negotiate.** The fastest path: no migration, no retraining, a tool your team already knows, and sometimes you can talk the increase down. But you're negotiating from the weaker seat — the vendor knows switching is painful and has priced that pain into the quote — any discount you win tends to be temporary, and you're back at the same table next year. This is the right call when the increase is genuinely modest, you're mid-project, or your switching cost is unusually high.
+
+**Switch.** There's a real upfront cost here, and we won't pretend otherwise: migration time, some retraining, and standing up and securing a server. What you buy with that one-time cost is a change in _who holds the lever_ — with a self-hosted, open-source tool, your recurring spend becomes your own infrastructure plus a license, not a seat count a vendor re-prices on its own schedule.
+
+**The break-even.** Estimate the switch cost once — hours to migrate plus server setup — and weigh it against the increase you'd otherwise absorb at _every_ renewal. A one-time cost is a single line; a compounding annual increase is a curve. When the increase recurs, a switch often pays for itself within a renewal cycle or two. Run it with your own numbers before committing either way.
+
+## The honest caveat
+
+Self-hosting is not free of effort, and pretending otherwise would be dishonest. **Someone on your side runs the server** — you provision a host, open ports, set up TLS, and keep it patched. That's real ops work. If what you actually want is a [zero-maintenance managed SaaS](/blog/rustdesk-self-hosted-vs-cloud-saas-option) with no server to run, be clear-eyed: RustDesk Server Pro is [self-hosted by design](/blog/why-self-host-remote-desktop-software) and is not that.
+
+Self-hosting is not necessarily the lowest-cost option in every configuration. Compare current quotes using the same login-user, managed-device, concurrency, feature, infrastructure, and support requirements. Check [rustdesk.com/pricing](https://rustdesk.com/pricing).
+
+## Build a comparable three-year cost model
+
+Put each option into the same worksheet instead of comparing one renewal quote with another vendor's entry price:
+
+| Cost input                                 |            AnyDesk renewal |                             Self-hosted alternative |
+| ------------------------------------------ | -------------------------: | --------------------------------------------------: |
+| Required licensed users and endpoints      |           Your dated quote |                    Login users plus managed devices |
+| Required concurrency or channels           | Plan allowance and add-ons |            Standard-plan or Customized V2 allowance |
+| Hosting, backup, monitoring, and bandwidth |   Usually included in SaaS |                            Your infrastructure cost |
+| Deployment and migration labor             |      Policy/client changes |        Server setup, client rollout, access mapping |
+| Ongoing administration                     |  Vendor/account management | Patching, certificates, capacity, incident response |
+| Optional branding, SSO, and admin controls |       Correct tier/add-ons |                             Correct Server Pro tier |
+
+Run a base case and a growth case for the same 36-month period. A self-hosted option may reduce vendor-cloud costs, but it is not operationally free; the useful result is total cost for your workload, not the smallest number on a pricing page.
+
+## Run the comparison on your own infrastructure
+
+You do not need to book a demo to find out if this fits. **Self-host the free community server today**, or email [sales@rustdesk.com](mailto:sales@rustdesk.com) for current Pro evaluation terms. Point a couple of technicians and a handful of devices at it, run real sessions, and see whether owning your infrastructure feels like the right trade for your team. Prefer to watch first? There's a full [video walkthrough](/blog/see-rustdesk-in-action) on the [RustDesk YouTube channel](https://www.youtube.com/@rustdesk).
+
+The next price-increase email is a matter of when, not if. Self-hosting is how you stop being on the receiving end of it.
@@ -0,0 +1,96 @@
+---
+publishDate: 2026-07-07T00:00:00Z
+lang: en
+translationKey: avoid-remote-desktop-scams
+draft: false
+title: 'Remote Desktop Scams: How to Spot and Avoid Them'
+excerpt: 'How remote access scams work, the red flags that give them away, and exactly what to do if a scammer already took control of your computer.'
+image: ~/assets/images/blog/avoid-remote-desktop-scams-og.png
+category: Security
+tags:
+  - security
+  - troubleshooting
+author: RustDesk Team
+faq:
+  - question: 'What is a remote desktop scam?'
+    answer: 'It is a form of fraud where a criminal convinces you to install legitimate remote-access software and then uses it to control your computer, usually to move money, steal data, or install malware. The tools are the same ones IT teams use every day. What makes it a scam is that the person on the other end contacted you under false pretenses and talked you into granting access.'
+  - question: 'Can a scammer get into my computer if I never gave them a code or installed anything?'
+    answer: 'In the typical social-engineering flow described here, refusing to install the caller’s tool or share a connection code usually stops that attempt. It does not rule out existing unattended access, stolen credentials, malware, or exposed services such as RDP. If you see unexplained sessions or account activity, disconnect the device and investigate even if you never shared a new code.'
+  - question: 'What should I do right after I realize I was scammed?'
+    answer: "Disconnect the device from the internet, uninstall the remote-access app they had you run, and change your passwords from a different trusted device, starting with email and banking. Call your bank or card issuer to report fraud, and file a report with the FTC at ReportFraud.ftc.gov and the FBI's Internet Crime Complaint Center at ic3.gov. If you shared identity details, place a fraud alert or credit freeze with Equifax, Experian, and TransUnion."
+  - question: 'Does using RustDesk protect me from scams?'
+    answer: 'No remote-desktop tool can make you scam-proof, RustDesk included. If someone tricks you into installing a client and reading them a connection code, they can take control on any platform. What self-hosting and open source change is your side of the equation: you control your own ID and relay server, decide exactly which clients may connect, and can audit the code. That reduces certain risks, but it does not replace basic caution about who you let in.'
+metadata:
+  description: 'How remote access scams work, the red flags to watch for, and exactly what to do if a scammer already took control of your computer.'
+  keywords: 'remote desktop scams, remote access scam, tech support scam, how to avoid remote access scam, scammer remote access computer, report tech support scam'
+---
+
+A remote desktop scam is a type of fraud where a criminal convinces you to install legitimate remote-access software, then uses it to take control of your computer — to drain a bank account, steal data, or plant malware. The tools themselves are the same ones IT departments use every day. What turns it into a scam is who is on the other end and how they talked their way in.
+
+This guide is deliberately vendor-neutral. Any remote-desktop product can be abused this way, RustDesk included. The goal here is to help you recognize the pattern, refuse it, and recover if you have already been caught.
+
+## How a remote access scam works
+
+The [U.S. Federal Trade Commission](https://consumer.ftc.gov/articles/how-spot-avoid-and-report-tech-support-scams) and the [FBI](https://www.fbi.gov/how-we-can-help-you/scams-and-safety/common-frauds-and-scams/tech-support-scams) both describe a remarkably consistent script:
+
+1. **The bait.** A pop-up warns that "your computer is infected," or you get an unexpected call, email, or text. The sender impersonates a name you trust — Microsoft, Apple, Amazon, your bank, a utility company, or even your own IT department.
+2. **Manufactured urgency.** Your account is compromised, a virus is spreading, a refund is waiting, or your service will be cut off. According to the FTC, scammers "want you to act before you have time to think," so the pressure to move fast is the point.
+3. **Install the tool.** They ask you to download "free remote support software" so they can "fix" the problem. It is real software — that is what makes it convincing.
+4. **Read out the code.** You are told to read them the connection ID or one-time code on your screen. That single step is the moment they get in.
+5. **Take control.** They fake a virus scan, open your banking site, move money, or set up new accounts. The [FBI's Boston field office](https://www.fbi.gov/contact-us/field-offices/boston/news/press-releases/fbi-warns-public-to-beware-of-tech-support-scammers-targeting-financial-accounts-using-remote-desktop-software) has warned that scammers use this access to open virtual-currency accounts and liquidate victims' genuine bank balances.
+
+The losses are not theoretical. In that same FBI warning, investigators described a Maine couple who lost roughly **$1.1 million** after a pop-up told them to call a number for "Fidelity," were instructed to install remote-desktop software, and let fake "Microsoft" and "Fidelity" representatives watch their accounts.
+
+## The red flags
+
+Almost every remote access scam trips at least one of these wires:
+
+- **Unsolicited contact.** A stranger reaches out to fix a computer problem you never reported. The FTC is blunt about this: it and its refund administrators "will never ask you to pay with gift cards" or "request remote access to your device." Neither will Microsoft, Apple, or your bank.
+- **A pop-up with a phone number.** Legitimate security warnings never tell you to call a support line. That number belongs to the scammer.
+- **Pressure and urgency.** "Do this right now or you lose everything" is a manipulation tactic, not a support process.
+- **A request to install software and read out a code.** This is the mechanical heart of the scam. No honest cold-caller needs it.
+- **A pivot to money.** Gift cards, wire transfers, cryptocurrency, or a "refund" that is somehow too large and needs to be "sent back."
+- **Staying on the line while you log in.** They want to watch you type your banking credentials.
+
+## Legitimate support versus a scam
+
+|                     | Legitimate remote support                   | A scam                                   |
+| ------------------- | ------------------------------------------- | ---------------------------------------- |
+| Who starts it       | You contact them, at a number you looked up | They contact you out of the blue         |
+| The problem         | One you already reported                    | One they "discovered" and told you about |
+| Urgency             | Scheduled, unhurried                        | "Act now or else"                        |
+| The connection code | You choose to share it, knowingly           | You are pressured to read it aloud fast  |
+| Payment             | Normal invoicing, if any                    | Gift cards, wire, crypto, "refunds"      |
+| Access to banking   | Never needed to fix a PC                    | The actual goal                          |
+
+## What to do if you already gave a scammer access
+
+If you realize mid-call or afterward that you have been scammed, act quickly and in order:
+
+1. **Disconnect from the internet.** Turn off Wi-Fi or unplug the network cable to cut their session immediately.
+2. **Uninstall the remote-access app** they had you install. If you are unsure how, a trusted local technician can help.
+3. **Scan for malware.** Run a full antivirus scan; consider professional cleanup if sensitive machines were involved. Assume they may have left something behind.
+4. **Change your passwords from a different, trusted device** — email and banking first, then anything that shares a password.
+5. **Call your bank and card issuers.** Report the fraud, ask about reversing transfers, and watch for unauthorized activity.
+6. **Protect your identity.** If you shared personal details, place a fraud alert or credit freeze with all three major U.S. bureaus: Equifax, Experian, and TransUnion.
+7. **Report it.** File with the FTC at [ReportFraud.ftc.gov](https://reportfraud.ftc.gov) and the FBI's [Internet Crime Complaint Center (IC3)](https://www.ic3.gov). Reporting helps investigators and can support recovery.
+
+## How to prevent it
+
+Prevention comes down to a few habits:
+
+- **Never install remote software at the request of someone who contacted you.** Reverse the direction: if you need help, you find the vendor's real number and call them.
+- **Never read a connection code aloud** to someone you did not deliberately reach out to.
+- **Treat pop-up phone numbers as fake.** Close the browser — force-quit it if needed — rather than calling.
+- **Slow down.** Urgency is the scammer's tool. A real institution will let you hang up and call back.
+- **Talk about it.** These scams disproportionately target older adults and people under stress. A quick "does this sound right to you?" to a family member breaks the spell.
+
+## Where remote-desktop tools fit in
+
+It is worth repeating: the software is not the villain. Remote-desktop tools are how IT teams keep the world's computers running, and the exact same app can be a lifeline or a weapon depending on who is holding it. Blaming any one product misses the point — the defense is controlling who you let in.
+
+That said, if you _run_ remote support professionally, a few structural choices reduce your exposure. Self-hosting the RustDesk server means the ID and relay servers run on infrastructure you control, so you decide exactly which clients are allowed to connect rather than trusting a vendor cloud to arbitrate it. For your own fleet, practice basic [unattended-access hygiene](/blog/rustdesk-unattended-access-setup): strong, unique permanent passwords, connections restricted to your device groups and [shared address book](/blog/rustdesk-per-user-access-control-device-groups-shared-address-book), and two-factor authentication. And because the RustDesk client is [open source](/blog/case-for-open-source-remote-access), you or a security team can audit exactly what it does on your machines.
+
+None of that makes RustDesk — or anything else — scam-proof. A user tricked into installing a client and reading out a code can be victimized on any platform. Structure lowers certain risks; it never replaces the simple rule at the center of every warning above: do not hand control of your computer to someone who contacted _you_.
+
+If you want to dig into how specific tools handle safety and how they get impersonated, see our companion guides on whether [AnyDesk is safe](/blog/is-anydesk-safe) and whether [Chrome Remote Desktop is safe](/blog/is-chrome-remote-desktop-safe).
@@ -0,0 +1,111 @@
+---
+publishDate: 2026-07-07T00:00:00Z
+lang: en
+translationKey: best-free-remote-desktop-software
+draft: false
+title: 'Best Free Remote Desktop Software for Business (2026)'
+excerpt: 'Genuinely free remote desktop tools — including ones you can use for business without a commercial-use flag. Six honest options, each with its catch.'
+image: ~/assets/images/blog/best-free-remote-desktop-software-og.png
+category: Guides
+tags:
+  - RustDesk
+  - open-source
+  - comparison
+author: RustDesk Team
+faq:
+  - question: 'What is the best free remote desktop software for business use?'
+    answer: 'RustDesk stands out when a business needs open-source code and a self-hosted community server with no commercial-use classifier. Chrome Remote Desktop is also free and Google documents enterprise administration policies for it, but it uses Google accounts and a Google-operated control plane. Apache Guacamole and MeshCentral are business-friendly infrastructure projects with different operating models.'
+  - question: 'Is any free remote desktop software actually free for commercial use?'
+    answer: "Yes. RustDesk's open-source client and free community server, Apache Guacamole, MeshCentral, and the VNC family permit business use under their respective licenses. Chrome Remote Desktop is free and has documented enterprise controls; unlike TeamViewer and AnyDesk free tiers, it should not be described as personal-use-only. Always review the current terms for the exact deployment."
+  - question: 'What is the catch with free remote desktop software?'
+    answer: 'The catch is almost always effort. Free self-hosted tools like RustDesk, Guacamole, and MeshCentral require you to run and maintain a server. VNC needs port-forwarding or a VPN to work across the internet. The saving is money; the cost is operational work and, sometimes, missing convenience features.'
+  - question: 'How is this different from open-source remote desktop software?'
+    answer: 'Open source is about the license and auditability; free is about price and terms. There is overlap, but they are not the same lens. This guide focuses on tools that are free to run — especially for business — while our open-source guide compares the auditable, self-hostable options in depth.'
+metadata:
+  description: 'Genuinely free remote desktop software for 2026 — including tools you can use for business without a commercial-use flag. Six options, each with its catch.'
+  keywords: 'best free remote desktop software, free remote desktop for business, free remote desktop no commercial use, RustDesk free, Apache Guacamole, MeshCentral, free VNC remote desktop'
+---
+
+## What "free" should actually mean
+
+Search "free remote desktop software" and you'll get a wall of tools that are free — right up until they aren't. TeamViewer and AnyDesk both offer free tiers, but they're licensed for personal use, and their software watches your connection patterns. Do anything that looks like work and you can get [flagged for commercial use on TeamViewer](/blog/teamviewer-commercial-use-detected) or [the same thing on AnyDesk](/blog/anydesk-commercial-use-detected) — sessions time out, and you're pushed toward a paid plan.
+
+So this guide applies a stricter test. To make the list, a tool has to be **genuinely free to run** — and ideally free for **business** use with no commercial-use trip wire. That rules out the "free until we decide it isn't" tier and leaves the tools you can actually build a workflow on.
+
+A note on scope: this is the _free_ lens. If what you care about is auditability and licensing specifically, our companion piece on [open-source remote desktop software](/blog/open-source-remote-desktop-software) compares the auditable, self-hostable options in depth. There's overlap, but "free" and "open source" aren't the same question.
+
+## The genuinely free options
+
+The order below starts with the tools that are genuinely free for business use and then weighs self-hosting, cross-platform coverage, and operational overhead.
+
+### RustDesk — free, open source, no commercial-use nag
+
+RustDesk sits first here because its client core is open source under the **[AGPL](/blog/case-for-open-source-remote-access)** and the **community server has no license fee or commercial-use classifier**. You still pay for any hosting and operations you choose. It is cross-platform (Windows, macOS, Linux, Android, iOS). On Windows, macOS, Linux, and Android hosts it includes file transfer and unattended access; the iOS app is controller-only. The source can be inspected and built independently.
+
+**The catch:** self-hosting is real work. Someone provisions a host, opens ports, sets up TLS, and patches the server over time. The free community server also isn't the paid Server Pro — team features like the [web console, custom-branded clients, and device groups](/blog/rustdesk-web-console-custom-client-generator-port-21114) live in Server Pro (self-hosted, not free). For current terms, see [rustdesk.com/pricing](https://rustdesk.com/pricing).
+
+### Chrome Remote Desktop — free and simple, with Google-managed coordination
+
+Google's [Chrome Remote Desktop](https://support.google.com/chrome/answer/1649523) is free, browser-based, and about as easy as remote access gets. Google also documents [enterprise administration policies](https://support.google.com/chrome/a/answer/2799701) for enabling, disabling, and constraining its use in organizations.
+
+**The catch:** it requires Google identity and a Google-operated signaling service, and it lacks some support-team conveniences such as drag-and-drop file transfer, remote printing, and RustDesk-style device groups. Google documents organization-level policies, but not a self-hosted control plane. Session setup is negotiated through Google; live traffic can use a direct or STUN path, with TURN/Google relay used when required. We cover this in depth in our [Chrome Remote Desktop alternative](/blog/chrome-remote-desktop-alternative) guide.
+
+### The VNC family — the free open protocol
+
+VNC is the granddaddy of open remote access. Free implementations like [TigerVNC](https://tigervnc.org/), [TightVNC](https://www.tightvnc.com/), and [UltraVNC](https://uvnc.com/) let one machine control another's screen with no licensing cost, and the protocol is genuinely open.
+
+**The catch:** plain VNC is a display protocol with no built-in NAT traversal or relay, so reaching a machine across the internet generally means setting up **port-forwarding or a VPN** yourself — and configuring encryption and access control on top. It's powerful and free, but you assemble the surrounding infrastructure. (See our [RustDesk vs. VNC](/blog/rustdesk-vs-vnc) comparison for the trade-offs.)
+
+### Apache Guacamole — free clientless HTML5 gateway
+
+[Apache Guacamole](https://guacamole.apache.org/) is a "clientless remote desktop gateway" licensed under Apache 2.0. Because it's HTML5-based, "once Guacamole is installed on a server, all you need to access your desktops is a web browser" — no plugins, no client software. It brokers connections to standard protocols like **RDP, VNC, and SSH**.
+
+**The catch:** Guacamole is an infrastructure project in its own right. You stand up the gateway, wire it to your existing RDP/VNC/SSH endpoints, and manage it. It shines when you already have those back-end connections and want browser-based, centralized access — less so as a two-minute point-to-point tool.
+
+### MeshCentral — free agent-based fleet management
+
+[MeshCentral](https://github.com/Ylianst/MeshCentral) is a free, open-source (Apache 2.0), self-hosted "full computer management web site." You run your own server and install an agent on managed devices to get web-based remote desktop, terminal, and file management across a fleet — on a LAN or over the internet.
+
+**The catch:** it's agent-based and management-oriented, which means more setup than a lightweight point-to-point tool, and a UI aimed at administrators. If you want a fleet-management console for free, it's excellent; if you want the simplest possible one-off connection, it's more than you need.
+
+### Remmina — free Linux client
+
+[Remmina](https://remmina.org/) is a free, copyleft remote desktop **client** for Linux and other Unix-like systems, supporting RDP, VNC, SSH, SPICE, and more from one unified interface.
+
+**The catch:** Remmina is a _client_, not a full remote-access system. It connects to servers that already speak those protocols; it doesn't provide the host side, NAT traversal, or a management layer. It's the go-to free client on Linux — pair it with something on the server end.
+
+## Free remote desktop software compared
+
+| Tool                             | Free for business?                        | Self-host a server?            | Best for                                         |
+| -------------------------------- | ----------------------------------------- | ------------------------------ | ------------------------------------------------ |
+| **RustDesk**                     | Yes (AGPL client + free community server) | Yes (free server / Server Pro) | Cross-platform access with no commercial-use nag |
+| Chrome Remote Desktop            | Yes; enterprise policies available        | No self-hosted control plane   | Simple access with Google-managed coordination   |
+| VNC (TigerVNC/TightVNC/UltraVNC) | Yes (open protocol)                       | Yes (you assemble it)          | LAN/DIY access with a VPN                        |
+| Apache Guacamole                 | Yes (Apache 2.0)                          | Yes (gateway)                  | Browser access to existing RDP/VNC/SSH           |
+| MeshCentral                      | Yes (Apache 2.0)                          | Yes (agent-based)              | Managing a fleet of devices                      |
+| Remmina                          | Yes (client only)                         | N/A (client)                   | A free remote desktop client on Linux            |
+
+For exact TeamViewer and AnyDesk terms, check their current pages — we don't quote numbers or license terms we can't stand behind.
+
+## Why RustDesk leads for free business use
+
+Most of the free options make you choose between Google-managed simplicity (CRD), heavier infrastructure (Guacamole and MeshCentral), or DIY networking (VNC). RustDesk's pitch is that you don't have to trade away business use, cross-platform reach, self-hosting, or auditability to run something free.
+
+- **Open source you can audit.** The client is [AGPL](/blog/case-for-open-source-remote-access) — read it, build it, verify it.
+- **A community server without a license fee.** Self-host it under its open-source license; infrastructure and operating costs remain yours.
+- **No black-box vendor.** Sessions run through infrastructure you control, not a cloud that can meter or flag you.
+- **Every major platform.** Windows, macOS, Linux, and Android hosts; iOS is a controller app.
+
+When your team outgrows the free server, [Server Pro](/blog/rustdesk-pro-license-cost-how-to-pay) adds the console, custom clients, device groups, and SSO — still self-hosted, priced per login-user and per managed-device.
+
+## The honest caveat
+
+"Free" almost always means "you do the work." Every self-hosted option here — RustDesk, Guacamole, MeshCentral — trades a subscription for operational effort: a server to run, ports to open, TLS to configure, patches to apply. VNC trades it for networking setup. That's a real cost, just not a cash one. If your team genuinely wants a zero-maintenance managed cloud with nothing to run, none of these free tools are that, and paying for a hosted product may be the honest answer. Only you can weigh the trade.
+
+## Try RustDesk without a sales call
+
+- **Self-host the free, open-source community server today** — no cost, no expiry, no commercial-use flag.
+- **Want the Pro team features?** Email [sales@rustdesk.com](mailto:sales@rustdesk.com) for current evaluation terms, or see [rustdesk.com/pricing](https://rustdesk.com/pricing).
+- **Prefer to see it first?** Watch a [video walkthrough](/blog/see-rustdesk-in-action) on the [RustDesk YouTube channel](https://www.youtube.com/@rustdesk).
+
+Read the code on [GitHub](https://github.com/rustdesk/rustdesk), stand up a server, and decide for yourself.
@@ -0,0 +1,89 @@
+---
+publishDate: 2026-07-06T00:00:00Z
+lang: en
+translationKey: best-screenconnect-alternative-msps
+draft: false
+title: 'The Best ScreenConnect Alternative for MSPs'
+excerpt: "Exploitation of a critical ScreenConnect vulnerability and packaging changes have MSPs evaluating alternatives. Here's how self-hosted RustDesk compares."
+image: ~/assets/images/blog/best-screenconnect-alternative-msps-og.png
+category: Alternatives
+tags:
+  - RustDesk
+  - ScreenConnect
+  - alternative
+  - MSP
+author: RustDesk Team
+metadata:
+  description: 'Looking for a ScreenConnect alternative? RustDesk is self-hosted, open source, and brandable, with no per-channel cost. Built for MSPs.'
+  keywords: 'ScreenConnect alternative, ConnectWise Control alternative for MSPs, self-hosted ScreenConnect replacement, MSP remote support alternative'
+---
+
+## The Best ScreenConnect Alternative for MSPs
+
+[The 2024 ScreenConnect vulnerability](https://www.cisa.gov/news-events/alerts/2024/02/22/cisa-adds-one-known-exploited-connectwise-vulnerability-cve-2024-1709-catalog) and product packaging changes prompted renewed evaluation of alternatives. The documented event was exploitation of CVE-2024-1709 in affected ScreenConnect servers; it should not be described as ConnectWise itself being hacked. Security conclusions here rely on public disclosures.
+
+If you run a managed services shop, this is a business-continuity question, not just a licensing one. When a critical remote-access server vulnerability is actively exploited, clients may block affected versions or instances until remediation is verified. This article makes the case for RustDesk: an open-source, self-hosted remote desktop platform built for an "our infrastructure, our rules" posture.
+
+## The core difference: you host it, so you control it
+
+The biggest structural difference between RustDesk and ScreenConnect's cloud offering is who operates the server-side services. RustDesk Server Pro is **self-hosted**: the ID/rendezvous server, relay, console, and stored deployment data run on infrastructure you control. Direct sessions still flow between endpoints; sessions use your relay only when direct connectivity fails or relay is forced.
+
+The free community server supports a self-hosted proof of concept before a buyer evaluates paid Server Pro features.
+
+On top of that, RustDesk's core client is **[open source (AGPL)](/blog/case-for-open-source-remote-access)**. You can read the code, audit exactly what the client does on a customer's machine, build it yourself, and run the free community server indefinitely. For an MSP that has to answer a hospital's or a bank's security questionnaire, "here's the source, and it runs on our servers" is a much stronger answer than "trust our cloud."
+
+## RustDesk vs ScreenConnect at a glance
+
+| What matters to an MSP                                       | ScreenConnect / ConnectWise Control | RustDesk                                                                                  |
+| ------------------------------------------------------------ | ----------------------------------- | ----------------------------------------------------------------------------------------- |
+| Hosting                                                      | Managed cloud or on-premise         | [Self-hosted by design](/blog/why-self-host-remote-desktop-software); on-prem or your VPS |
+| Source code                                                  | Proprietary                         | Open source (AGPL), auditable                                                             |
+| Pricing model                                                | Per-channel / seat (see vendor)     | [Per login-user + per managed-device](/blog/rustdesk-pro-license-cost-how-to-pay)         |
+| Concurrent sessions                                          | Tied to channels/licensing          | Standard plans unlimited; Customized V2 limited                                           |
+| Custom-branded client                                        | Available (see vendor)              | Custom-branded client generator                                                           |
+| [Data residency](/blog/remote-desktop-data-sovereignty-gdpr) | Vendor-dependent                    | Server-side services on infrastructure you control; endpoint routes still matter          |
+| Evaluate without sales call                                  | Varies                              | Free server today, or Pro trial on request                                                |
+
+For exact RustDesk prices and plan-by-plan feature availability, [see rustdesk.com/pricing](https://rustdesk.com/pricing).
+
+## No per-channel tax, no concurrency ceiling on standard plans
+
+Compare the products through a proof of concept that covers features, cost, usability, migration, and operating effort.
+
+RustDesk licensing is **per login-user plus per managed-device**. Standard plans include unlimited [concurrent connections](/blog/rustdesk-concurrent-connections-limit); Customized V2 limits and prices them separately. Upgrades can be prorated.
+
+## Built for MSP operations: branding, console, access control
+
+Being cheap and self-hosted isn't enough if the tooling is thin. For MSPs and IT teams, RustDesk provides a self-hosted **[web console](/blog/rustdesk-web-console-custom-client-generator-port-21114)**, a **custom-branded client generator** (ship a client with your logo and your server baked in), and **[device groups plus a shared address book](/blog/rustdesk-per-user-access-control-device-groups-shared-address-book)** for per-user access control. **[LDAP/SSO](/blog/rustdesk-active-directory-ldap-sso) (OIDC) integration is available from the Basic plan and up**, so you can tie access to your existing directory.
+
+It also scales past the SMB tier: RustDesk publishes [large-fleet planning guidance](/blog/rustdesk-scale-50000-200000-devices) for teams that need to evaluate much larger estates.
+
+## Compliance and data sovereignty
+
+For regulated clients, map where rendezvous, relay, device data, and endpoint traffic flow. Self-hosting provides control over server-side components but does not by itself guarantee data residency or GDPR compliance.
+
+## The honest caveat
+
+Self-hosting is the strength and the responsibility. It means **someone on your side runs the server**: you provision a host, open the right ports, set up TLS, and patch it over time. If what you want is a [zero-maintenance managed SaaS](/blog/rustdesk-self-hosted-vs-cloud-saas-option) with no server to run, RustDesk Server Pro is self-hosted by design and is not that. For most MSPs — who already run infrastructure for clients — this is a comfortable trade, and it's the price of full control over your data and your access tool.
+
+## MSP proof-of-concept scorecard
+
+An MSP should grade the replacement against client-service operations, not a generic feature list:
+
+- **Tenant separation:** prove that each technician can see only assigned customer device groups.
+- **Technician lifecycle:** test SSO, MFA, onboarding, role changes, emergency access, and immediate offboarding.
+- **Support workflow:** validate attended and unattended access, elevation, file transfer, chat, multi-monitor, and session handoff.
+- **Client deployment:** verify branding, preconfiguration, code signing, OS permissions, silent updates, and rollback.
+- **Service reliability:** measure relay capacity, latency, monitoring, backup restoration, and failover under representative load.
+- **Audit evidence:** confirm which session, account, device, and administrative events are recorded and how long they are retained.
+- **Commercial fit:** size both login users and managed devices, plus any Customized V2 concurrency requirements.
+
+Keep ScreenConnect available during the pilot. A passing scorecard and a tested rollback plan are stronger migration criteria than feature parity on paper.
+
+## Run an MSP proof of concept
+
+You do not need a full migration to test the model.
+
+- **Self-host the free open-source community server today** — open source, no cost, no expiry.
+- **Want to try the Pro features?** Email [sales@rustdesk.com](mailto:sales@rustdesk.com) to ask about current evaluation terms, or check [rustdesk.com/pricing](https://rustdesk.com/pricing) for standard plan rates.
+- **Prefer to see it first?** Watch a full [video walkthrough](/blog/see-rustdesk-in-action).
@@ -0,0 +1,78 @@
+---
+publishDate: 2026-07-06T00:00:00Z
+lang: en
+translationKey: case-for-open-source-remote-access
+draft: false
+title: 'Why Open Source Matters for Remote Access'
+excerpt: 'Why auditability, infrastructure control, and lower lock-in matter more in remote access than in most software categories.'
+image: ~/assets/images/blog/case-for-open-source-remote-access-og.png
+category: Guides
+tags:
+  - RustDesk
+  - open-source
+author: RustDesk Team
+metadata:
+  description: 'Why open source matters in remote access: auditability, lower lock-in, infrastructure control, and the trade-offs of self-hosting.'
+  keywords: 'why open source remote access, auditable remote support software, remote desktop source audit, open source trust model'
+---
+
+## Why open source matters for remote access
+
+Remote-access buyers often prioritize source auditability, infrastructure control, and predictable licensing.
+
+This is the argument for **open-source remote access**: when a piece of software can see and control your customers' screens, files, and keystrokes, the right to read exactly what it does is not a nice-to-have. It's the whole point. If you are comparing concrete product options rather than the argument itself, start with [Open-Source Remote Desktop Software: The Options](/blog/open-source-remote-desktop-software).
+
+## Why "open source" matters more here than almost anywhere else
+
+Most software you can treat as a black box. Remote-access software you cannot, because the threat model is inverted: the tool is _designed_ to have total control of a remote machine. That means two things matter enormously.
+
+**You can verify the client, not just believe the marketing.** RustDesk's core is open source under the AGPL. You — or a security team you hire — can read the code, confirm what the client actually sends and where, build it yourself, and run the free community server indefinitely. There is no "take our word for it."
+
+**A breach in a closed tool leaves customers dependent on vendor disclosures.** Public events such as [AnyDesk's 2024 security incident](https://www.infosecurity-magazine.com/news/anydesk-hit-cyberattack-customer/) and the [2024 ConnectWise ScreenConnect vulnerability](https://www.cisa.gov/news-events/alerts/2024/02/22/cisa-adds-one-known-exploited-connectwise-vulnerability-cve-2024-1709-catalog) illustrate why independent auditability matters.
+
+## Open source vs closed source, for remote access specifically
+
+| What you care about            | Closed-source SaaS (typical)    | Open-source, self-hosted (RustDesk)                                    |
+| ------------------------------ | ------------------------------- | ---------------------------------------------------------------------- |
+| Can you audit the client?      | No — binary only                | Yes — AGPL source, build it yourself                                   |
+| Where does session traffic go? | Through the vendor's cloud      | Through servers you run                                                |
+| Where does your data live?     | Vendor infrastructure/region    | Infrastructure you control; routing and endpoint location still matter |
+| Lock-in                        | Vendor subscription and service | Community server under an open-source license; Pro optional            |
+| Who runs the server?           | Vendor (nothing to run)         | You (see the honest caveat below)                                      |
+
+## No lock-in, and a cost model that doesn't punish growth
+
+Vendor-controlled subscription pricing can change at renewal. Compare current public terms or written quotes.
+
+Open source is the structural answer to that treadmill. You can run the community server under its open-source license without a Server Pro subscription. Server Pro is licensed **per login-user plus per managed-device**, and mid-term upgrades may be prorated under current terms. **Standard plans include unlimited [concurrent connections](/blog/rustdesk-concurrent-connections-limit); Customized V2 has a defined allowance.** Use the current [pricing page](https://rustdesk.com/pricing) for all rates and limits.
+
+## Your data stays where your rules say it must
+
+Because you host it, the ID/rendezvous and relay servers run on your own machine — on-prem or a VPS you rent — with no vendor cloud in the middle. Session traffic that uses your relay and the device data your server stores stay on infrastructure you control, which is a meaningful input to [GDPR](/blog/remote-desktop-data-sovereignty-gdpr), healthcare, and public-sector deployment design.
+
+Self-hosting gives an organization control over its rendezvous, relay, and management services, but it is not a compliance checkbox by itself. Endpoint location, routing, access controls, retention, and legal obligations still require assessment.
+
+## Open source doesn't mean it can't scale
+
+A fair worry is whether a self-hostable option handles real load. RustDesk documents large-deployment guidance and offers a web console, device groups, shared address books, and plan-dependent client generation and identity features. Validate capacity against your own workload.
+
+## The honest caveat: someone has to run the server
+
+Open source and self-hosting are not free of trade-offs, and we'd rather you hear this from us. **Self-hosting means someone on your side runs the server**: you provision a host, open ports, set up TLS, and keep it patched. That's a real, ongoing responsibility. If what your team actually wants is a [zero-maintenance managed SaaS](/blog/rustdesk-self-hosted-vs-cloud-saas-option) with no server to run and no ops burden, be clear-eyed about it — **RustDesk Server Pro is [self-hosted by design](/blog/why-self-host-remote-desktop-software), and it is not that.** The control and auditability you gain are inseparable from the fact that you own the box. For many teams that's the trade they want; for some it isn't, and that's fine.
+
+## How to turn source access into assurance
+
+Publishing code creates the opportunity to audit; it does not prove that anyone reviewed your build. A practical evaluation should:
+
+1. Pin the exact client and server revisions you plan to deploy.
+2. Review the connection, authentication, update, unattended-access, clipboard, and file-transfer trust boundaries.
+3. Produce a software bill of materials and scan both direct and transitive dependencies.
+4. Build in a controlled pipeline and compare the resulting artifacts with what you distribute.
+5. Track security reports and upstream releases, then define how quickly critical fixes reach managed endpoints.
+6. Record local patches so they can be rebased and reviewed instead of becoming an unmaintained fork.
+
+For smaller teams, a full source audit may be unrealistic. The minimum useful version is still concrete: know the revision, verify package provenance, monitor disclosures, restrict permissions, and keep a repeatable upgrade path.
+
+## Start with an audit or proof of concept
+
+You don't have to commit to find out. **Self-host the free open-source community server today**, or email [sales@rustdesk.com](mailto:sales@rustdesk.com) for current Pro evaluation terms — see [rustdesk.com/pricing](https://rustdesk.com/pricing) for standard plan rates. Prefer to watch first? There's a full [video walkthrough](/blog/see-rustdesk-in-action) on the [RustDesk YouTube channel](https://www.youtube.com/@rustdesk).
@@ -0,0 +1,94 @@
+---
+publishDate: 2026-07-07T00:00:00Z
+lang: en
+translationKey: chrome-remote-desktop-alternative
+draft: false
+title: 'Chrome Remote Desktop Alternative: Self-Hosted RustDesk'
+excerpt: "Chrome Remote Desktop is free and simple, but ties you to Google and drops key features. Here's an open-source, self-hosted alternative you control."
+image: ~/assets/images/blog/chrome-remote-desktop-alternative-og.png
+category: Alternatives
+tags:
+  - RustDesk
+  - Chrome Remote Desktop
+  - alternative
+  - self-hosting
+author: RustDesk Team
+faq:
+  - question: 'Is there a Chrome Remote Desktop alternative that does not require a Google account?'
+    answer: 'Yes. RustDesk uses its own ID/rendezvous and relay servers instead of a Google account, and you can self-host those servers so no third-party cloud sits in the middle. Chrome Remote Desktop, by contrast, requires a Google account on both the host and the client.'
+  - question: 'Does Chrome Remote Desktop support file transfer?'
+    answer: 'Chrome Remote Desktop offers only a basic upload/download file mechanism and no drag-and-drop; reviewers commonly list file transfer among its missing conveniences. RustDesk includes built-in file transfer alongside remote control.'
+  - question: 'Can Chrome Remote Desktop provide unattended access?'
+    answer: 'It can, but the target machine must be powered on and signed into the same Google account, and Chrome Remote Desktop cannot wake a sleeping computer. RustDesk supports permanent-password unattended access to a fleet you manage from your own console.'
+  - question: 'Is RustDesk free like Chrome Remote Desktop?'
+    answer: "RustDesk's client core is open source under the AGPL, and you can run the free community server indefinitely at no cost. The commercial Server Pro adds team features and is self-hosted; see rustdesk.com/pricing for current terms."
+metadata:
+  description: 'Chrome Remote Desktop is free and simple but ties you to Google and lacks key features. Compare it with RustDesk, an open-source, self-hosted alternative.'
+  keywords: 'Chrome Remote Desktop alternative, self-hosted Chrome Remote Desktop alternative, remote desktop without Google account, RustDesk vs Chrome Remote Desktop'
+---
+
+## Why look for a Chrome Remote Desktop alternative
+
+[Chrome Remote Desktop](https://support.google.com/chrome/answer/1649523) is Google's free, browser-based remote-access tool. It's genuinely convenient: install a small host, sign in, and you can reach your machine from another device in a couple of minutes. For casual personal use, that's hard to beat.
+
+But the moment your needs grow past "help my own laptop from the couch," the seams show. You're tied to Google identity and signaling, some support-team features are missing, and the control plane is not self-hostable. Google's [network guide](https://support.google.com/chrome/a/answer/16364503) explains the boundary: connections are initially negotiated through Google services, while live WebRTC traffic uses Direct, STUN, or TURN/relay paths. Only TURN/relay session packets are relayed through Google data centers. If you've bumped into those trade-offs, this page lays out what a self-hosted, open-source alternative looks like.
+
+We'll be even-handed about it: CRD is a legitimately good free tool for what it's designed to do, and RustDesk asks more of you up front. Here's the honest comparison.
+
+## What Chrome Remote Desktop does well
+
+Credit where it's due. [TechRadar's review](https://www.techradar.com/reviews/chrome-remote-desktop-review) calls it "completely free with no subscriptions or premium tiers," easy to set up, and a solid fit for personal use. It runs on Windows, macOS, and Linux, needs no license negotiation, and there's nothing to host. If you want to check on your home PC from your phone, CRD is close to zero-effort.
+
+That simplicity is the product. The trouble starts when you ask it to do the things a support team or a multi-machine setup actually needs.
+
+## Where Chrome Remote Desktop hits its limits
+
+### Missing features: self-hosted control, device management, and team workflows
+
+Google's help pages document remote access to files and applications and let administrators control access and network behavior, but they still describe a Google-account-based service with Google-operated coordination. The network guide shows sessions are negotiated through Google services first, then carried as Direct, STUN, or TURN/relay P2P traffic. In other words: CRD is fine for simple access, but it is not a self-hosted support console with RustDesk-style device groups or custom branding.
+
+### Unattended access and sleeping machines
+
+CRD can do unattended access, but the target still has to be **powered on and online** and signed into the **same Google account**. Google documents PIN-based remote access, not a wake-on-LAN substitute. If the machine is asleep or offline, there is nothing for CRD to connect to. For a fleet of remote endpoints, that is a real operational constraint.
+
+### Managing users and the Google-account requirement
+
+Every participant needs a Google account, and for shared (non-unattended) sessions someone has to be present to grant access. Google Workspace administrators can [enable or disable CRD and constrain firewall traversal](https://support.google.com/chrome/a/answer/2799701), but that is not the same as a self-hosted support console with device groups and scoped technician access. Google services still handle identity and initial negotiation; media may be direct or relayed depending on ICE/WebRTC connectivity. (For the security angle specifically, see [is Chrome Remote Desktop safe?](/blog/is-chrome-remote-desktop-safe))
+
+## Chrome Remote Desktop vs. RustDesk at a glance
+
+|                                                             | Chrome Remote Desktop                                            | RustDesk                                                                                                                    |
+| ----------------------------------------------------------- | ---------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------- |
+| Cost                                                        | Free                                                             | Open-source client (AGPL); free community server; paid Server Pro                                                           |
+| Control plane and traffic                                   | Google identity/signaling; direct, STUN, or Google-relayed media | [Self-hosted](/blog/why-self-host-remote-desktop-software) server roles; direct or self-relayed media                       |
+| Source code                                                 | Proprietary                                                      | Open source ([AGPL](/blog/case-for-open-source-remote-access)), auditable                                                   |
+| Account needed                                              | Google account on both ends                                      | Your own ID; no third-party account required                                                                                |
+| File transfer / transfer workflows                          | Google documents access to files and applications                | Built in                                                                                                                    |
+| [Unattended access](/blog/rustdesk-unattended-access-setup) | Same Google account, machine must be awake                       | Permanent-password access to a fleet you manage                                                                             |
+| Central management                                          | Google Admin policies; no self-hosted support console            | Web console, [device groups, shared address book](/blog/rustdesk-per-user-access-control-device-groups-shared-address-book) |
+| Custom branding                                             | No                                                               | Custom-branded client generator                                                                                             |
+| Platforms                                                   | Win/macOS/Linux (in Chrome)                                      | Win/macOS/[Linux](/blog/rustdesk-for-linux)/Android; iOS controller app                                                      |
+
+## Where RustDesk fits: self-hosted and open source
+
+RustDesk is built around the two things CRD structurally can't offer: **you host the infrastructure, and you can read the code.**
+
+RustDesk's client core is open source under the **[AGPL](/blog/case-for-open-source-remote-access)** — you can audit exactly what runs on your machines, build it yourself, and run the **free community server indefinitely**. When you move to Server Pro, it's **[self-hosted by design](/blog/why-self-host-remote-desktop-software)**: the ID/rendezvous and relay servers run on your own machine or a VPS you rent, so there's no Google (or any vendor) cloud in the middle. Note the honest nuance for compliance planning: direct connections still travel between endpoints, and relayed traffic uses your relay, so review the [data-sovereignty implications](/blog/remote-desktop-data-sovereignty-gdpr) rather than assuming server location controls every packet.
+
+On top of that self-hosted core, RustDesk adds the team features CRD lacks: a [self-hosted web console](/blog/rustdesk-web-console-custom-client-generator-port-21114), a custom-branded client generator, [device groups and a shared address book](/blog/rustdesk-per-user-access-control-device-groups-shared-address-book) for scoped access, and [LDAP/AD and OIDC SSO](/blog/rustdesk-active-directory-ldap-sso) from the Basic plan up. Real file transfer and permanent-password [unattended access](/blog/rustdesk-unattended-access-setup) come standard on Windows, macOS, Linux, and Android hosts; the iOS app is controller-only.
+
+## The honest caveat
+
+Here's the trade-off we won't hide: **Chrome Remote Desktop is zero-setup and genuinely free**, and RustDesk self-hosting is real work. Someone on your side has to provision a host, open the right ports, set up TLS, and patch the server over time. That's ongoing operational effort CRD simply doesn't ask of you.
+
+If all you need is casual, occasional access to your own personal machine, CRD may be the right answer, and there's no shame in using it. RustDesk earns its keep when you need control, auditability, central management, and features CRD doesn't have — and you're willing to own a server to get them. If you'd rather not run anything, be clear-eyed: RustDesk Server Pro is self-hosted, not a zero-maintenance managed cloud.
+
+## Try it without a sales call
+
+You can evaluate RustDesk on your own terms:
+
+- **Self-host the free, open-source community server today** — no cost, no expiry, no Google account.
+- **Want the Pro team features?** Email [sales@rustdesk.com](mailto:sales@rustdesk.com) for current evaluation terms, or compare plans at [rustdesk.com/pricing](https://rustdesk.com/pricing).
+- **Prefer to see it first?** Watch a [video walkthrough](/blog/see-rustdesk-in-action) on the [RustDesk YouTube channel](https://www.youtube.com/@rustdesk).
+
+Read the code for yourself on [GitHub](https://github.com/rustdesk/rustdesk), point a couple of devices at your own server, and decide whether the trade-offs fit before committing anything.
@@ -0,0 +1,88 @@
+---
+publishDate: 2026-07-07T00:00:00Z
+lang: en
+translationKey: gotomypc-alternative-self-hosted
+draft: false
+title: 'GoToMyPC Alternative: Self-Hosted and Open Source'
+excerpt: 'Looking for a self-hosted GoToMyPC alternative? See how RustDesk compares on hosting, open source, and per-computer vs. per-user licensing.'
+image: ~/assets/images/blog/gotomypc-alternative-self-hosted-og.png
+category: Alternatives
+tags:
+  - RustDesk
+  - GoToMyPC
+  - alternative
+  - self-hosting
+author: RustDesk Team
+faq:
+  - question: 'Is there a self-hosted alternative to GoToMyPC?'
+    answer: 'Yes. GoToMyPC is a vendor-hosted remote access service. RustDesk is self-hosted by design: the ID/rendezvous, relay, and management services run on infrastructure you control. Direct sessions still flow between endpoints, while relayed sessions use your configured relay. The RustDesk client is also open source under the AGPL.'
+  - question: "How does RustDesk licensing compare to GoToMyPC's per-computer pricing?"
+    answer: 'GoToMyPC is priced per computer per month as a cloud subscription across its Personal, Pro, and Corporate plans. RustDesk Server Pro is licensed per login-user plus per managed-device, hosted on your own server, with unlimited concurrent connections on standard plans. There is no per-computer cloud subscription. For current rates, see rustdesk.com/pricing.'
+  - question: 'Can RustDesk do unattended access to my own computers like GoToMyPC?'
+    answer: "Yes. RustDesk supports permanent-password unattended access so you can reach your own machines without someone sitting at the far end, which is GoToMyPC's core use case. The difference is that with RustDesk you own the server brokering those connections instead of renting cloud access per computer."
+  - question: 'What is the downside of switching from GoToMyPC to a self-hosted tool?'
+    answer: 'GoToMyPC is fully managed with zero server upkeep — you just log in. With RustDesk you or your IT team run the server: provisioning a host, opening ports, setting up TLS, and patching it. For teams that already run a VPS it is a small lift; for anyone who wants nothing to maintain, that operational work is the real trade-off.'
+metadata:
+  description: 'Self-hosted GoToMyPC alternative: RustDesk is open-source, runs on your own server, and licenses per login-user and per managed-device, not per computer.'
+  keywords: 'GoToMyPC alternative, self-hosted GoToMyPC alternative, open source GoToMyPC alternative, RustDesk vs GoToMyPC, self-hosted remote access, GoToMyPC replacement'
+---
+
+[GoToMyPC](https://get.gotomypc.com/) is built around a simple job: leave an agent on a computer and reach that computer later without someone at the far end. If that is the workflow you need to preserve, evaluate alternatives on unattended reliability, reboot recovery, display handling, file transfer, remote printing, and mobile access—not on the length of a generic feature list.
+
+This is an honest comparison. RustDesk is a different model with clear advantages and one real trade-off. Here is where it fits as a self-hosted GoToMyPC alternative.
+
+## What GoToMyPC is (and isn't)
+
+GoToMyPC is a mature, [cloud-based remote-access product](https://en.wikipedia.org/wiki/GoToMyPC): you install a host agent on the machine you want to reach, and connect to it from a browser or app anywhere. It handles file transfer, remote printing, and multi-monitor support, and it is **fully managed** — GoTo runs the infrastructure, so there is nothing on your side to maintain.
+
+Two things send people looking for an alternative. First, it is **cloud-only**: there is no self-hosted option, so every session is brokered through GoTo's servers. Second, its pricing is **per computer, per month** across the Personal, Pro, and Corporate tiers ([GoToMyPC plans](https://get.gotomypc.com/plansandpricing)), which adds up quickly as the number of machines you need to reach grows.
+
+## What changes when you self-host this workflow
+
+GoToMyPC operates the service for you. With RustDesk, you deploy the ID/rendezvous and relay services, configure each endpoint to use them, and own server uptime. Direct sessions flow between the two endpoints when NAT traversal works; otherwise they use your relay.
+
+That introduces work GoToMyPC normally hides: server patching, certificates, firewall rules, key backup, monitoring, and recovery. In return, you choose where the server-side services and device administration run. The RustDesk client is [open source under the AGPL](/blog/case-for-open-source-remote-access), and the community server is available for a no-license-cost proof of concept.
+
+## GoToMyPC vs. RustDesk at a glance
+
+|                                                                       | GoToMyPC (cloud)        | RustDesk (self-hosted)                                                            |
+| --------------------------------------------------------------------- | ----------------------- | --------------------------------------------------------------------------------- |
+| Hosting                                                               | Vendor cloud (GoTo)     | Your server (on-prem or your VPS)                                                 |
+| Self-hosted option                                                    | None                    | Yes, by design                                                                    |
+| Source code                                                           | Proprietary             | Open source (AGPL) core                                                           |
+| Server-side services                                                  | GoTo-operated           | Operated on infrastructure you control                                            |
+| Licensing model                                                       | Per computer, per month | [Per login-user + per managed-device](/blog/rustdesk-pro-license-cost-how-to-pay) |
+| [Concurrent connections](/blog/rustdesk-concurrent-connections-limit) | Plan-dependent          | Unlimited on standard plans; limited on Customized V2                             |
+| Server maintenance                                                    | None (GoTo runs it)     | Yours to run                                                                      |
+
+_GoToMyPC plans and prices change over time — confirm current terms on [GoTo's pricing page](https://get.gotomypc.com/plansandpricing). For RustDesk rates, see [rustdesk.com/pricing](https://rustdesk.com/pricing)._
+
+## Model the endpoint count before comparing price
+
+GoToMyPC plans are organized around the computers being accessed. Confirm the current billing interval, included users, and features on the official pricing page.
+
+RustDesk licenses differently: **per login-user (the people connecting) plus per managed-device (the machines you control)**, running on a server you host. **Standard plans include unlimited concurrent connections** (Customized V2 defines a concurrency allowance), and you can [upgrade any time](/blog/upgrade-rustdesk-license-mid-subscription), prorated, as you grow. Whether that works out cheaper depends on your exact mix of users and devices — so model both against the same requirements rather than assuming. We don't quote a hard RustDesk price in prose; check [rustdesk.com/pricing](https://rustdesk.com/pricing) or email [sales@rustdesk.com](mailto:sales@rustdesk.com). For how devices are counted, see [what counts as a managed device](/blog/what-counts-as-a-managed-device).
+
+## Unattended access to your own machines
+
+GoToMyPC's bread and butter is reaching your own computers when nobody is sitting at them. RustDesk does the same: permanent-password [unattended access](/blog/rustdesk-unattended-access-setup) lets you connect to your fleet on demand, with attended, ad-hoc sessions available for one-off help. Managed from a [self-hosted web console](/blog/rustdesk-web-console-custom-client-generator-port-21114), with [device groups and a shared address book](/blog/rustdesk-per-user-access-control-device-groups-shared-address-book) deciding who can reach which machines, it covers both the personal "access my own PC" workflow and the team "many admins, many devices" workflow on infrastructure you own.
+
+## Check the unattended-access details that break migrations
+
+Before moving a production endpoint, test access after reboot and logout, host service startup, display sleep, multi-monitor switching, file transfer, keyboard layout, privilege elevation, and recovery when the server is unavailable. If remote printing or browser-only access is mandatory, verify it explicitly rather than assuming parity.
+
+For regulated use, document the ID, relay, console, stored device data, endpoint locations, and direct-session routes. Self-hosting supplies server-side control; it does not make the deployment compliant on its own.
+
+## The honest caveat: someone has to run the server
+
+The trade-off is real and we won't hide it. Self-hosting means **someone on your side runs the server** — you provision a host, open ports, set up TLS, and patch it over time. For a team that already runs a VPS or a spare box, that is a small lift. For a solo user who just wants to click and connect with nothing to maintain, it is the one genuine cost of moving off GoToMyPC's cloud.
+
+GoToMyPC is fully managed with **zero server upkeep**, and for some people that convenience is worth the subscription. RustDesk Server Pro is [self-hosted by design](/blog/rustdesk-self-hosted-vs-cloud-saas-option), and its commercial rates and allowances can still change. The structural difference is who operates the server-side services, not a promise that pricing will never change.
+
+## Try it without a sales call
+
+- **Self-host the free, open-source community server today** — no cost, no expiry.
+- **Want the Pro features?** Email [sales@rustdesk.com](mailto:sales@rustdesk.com) about current evaluation terms, or check [rustdesk.com/pricing](https://rustdesk.com/pricing) for standard plan rates.
+- **Prefer to see it first?** Watch a full [video demo](/blog/see-rustdesk-in-action) on the [RustDesk YouTube channel](https://www.youtube.com/@rustdesk) — no booking required.
+
+If cost and control are why you are looking past GoToMyPC, a self-hosted, open-source alternative is worth an afternoon of your time.
@@ -0,0 +1,72 @@
+---
+publishDate: 2026-07-07T00:00:00Z
+lang: en
+translationKey: is-anydesk-safe
+draft: false
+title: 'Is AnyDesk Safe? Encryption, the 2024 Breach & Scams'
+excerpt: 'Is AnyDesk safe? A fair look at its encryption, the 2024 production-systems breach, and why scammers abuse it — plus how open source compares.'
+image: ~/assets/images/blog/is-anydesk-safe-og.png
+category: Security
+tags:
+  - AnyDesk
+  - security
+author: RustDesk Team
+faq:
+  - question: 'Is AnyDesk safe to use?'
+    answer: 'For legitimate use, AnyDesk is a mature, generally secure commercial remote-desktop tool. It encrypts sessions with standard transport security and offers two-factor authentication and access-control lists. The two things to keep in mind are that it is closed source and cloud-brokered by default, and that its biggest real-world danger is not a software flaw but tech-support scammers who talk victims into installing it.'
+  - question: 'Was AnyDesk hacked?'
+    answer: "In early 2024 AnyDesk disclosed a security incident affecting its production systems, in which attackers obtained source code and code-signing material. AnyDesk revoked certificates, pushed a re-signed client, and reset web-portal passwords. It stated that no end-user devices were affected. Confirm the exact scope and dates against AnyDesk's own advisories and neutral reporting."
+  - question: 'Why do scammers use AnyDesk?'
+    answer: 'Because it is free, quick to install, and requires no account for the person being controlled, AnyDesk is a favorite tool of tech-support scammers who phone or email victims and talk them into granting remote access. This is a usage risk, not an AnyDesk vulnerability — the same social-engineering trick works with any remote-desktop tool, including RustDesk.'
+  - question: "Is AnyDesk's encryption secure?"
+    answer: "AnyDesk's security documentation describes TLS 1.2 with AEAD, an RSA-2048 asymmetric key exchange, and 256-bit AES transport encryption, plus perfect forward secrecy. Those are industry-standard protections. The caveat is that you are trusting a closed-source client and, by default, AnyDesk's cloud to broker the connection, so you rely on the vendor's operational security rather than being able to audit the code yourself."
+metadata:
+  description: 'Is AnyDesk safe? A fair look at its encryption, the 2024 production-systems breach, and why scammers abuse it — plus how open source compares.'
+  keywords: 'is AnyDesk safe, AnyDesk security, AnyDesk breach 2024, AnyDesk scam, AnyDesk encryption, is AnyDesk safe to use, AnyDesk hacked'
+---
+
+Short version: yes, AnyDesk is a legitimate, generally secure commercial remote-desktop product for people using it on purpose. The risks worth understanding aren't that AnyDesk is malware — it isn't — but that it's closed source, cloud-brokered by default, had a notable breach in 2024, and is one of the tools scammers most love to abuse. Here's the fair, sourced version.
+
+## The short answer
+
+AnyDesk secures its sessions with standard, well-regarded encryption and offers the account protections you'd expect. It's used every day by help desks and enterprises without incident. Two caveats matter for your decision: first, you're trusting a proprietary client and, by default, AnyDesk's own cloud to broker connections, so you can't audit the code and you inherit the vendor's operational security — a point that stopped being abstract in [2024](https://www.infosecurity-magazine.com/news/anydesk-hit-cyberattack-customer/). Second, and more likely to affect an ordinary user, AnyDesk is a favorite prop in remote-access scams. Neither makes it unsafe to _install_; both shape how you should _use_ it.
+
+## How AnyDesk secures your sessions
+
+Per [AnyDesk's own security documentation](https://anydesk.com/en/security), sessions are protected with TLS 1.2 using AEAD, an RSA-2048 asymmetric key exchange to verify endpoints and guard against man-in-the-middle attacks, and 256-bit AES transport encryption, with perfect forward secrecy from an ephemeral key exchange. On the account side, AnyDesk supports two-factor authentication (TOTP) for unattended access, an access-control list / allowlist to restrict who may connect, and salted password hashing. (Some of AnyDesk's materials reference newer TLS versions; treat the current page as authoritative and verify the specifics there.)
+
+Those are solid, industry-standard protections — comparable in kind to what every serious competitor uses. On the transport layer, there is nothing alarming here. The interesting questions are about _trust model_ and _human behavior_, not cipher suites.
+
+## The 2024 AnyDesk breach: what actually happened
+
+In early 2024, AnyDesk publicly disclosed a security incident affecting its **production systems**. According to [Infosecurity Magazine](https://www.infosecurity-magazine.com/news/anydesk-hit-cyberattack-customer/) and security analysts at [Akamai](https://www.akamai.com/blog/security-research/anydesk-breach-what-to-know-mitigations-and-recommendations), attackers gained access to internal infrastructure and obtained source code and code-signing material. AnyDesk's response, by its own account, included engaging outside forensics, revoking and replacing security-related certificates, pushing a re-signed client build, and resetting web-portal passwords as a precaution.
+
+Two things deserve a fair hearing. On the reassuring side, AnyDesk stated that **no end-user devices were affected** and that its systems are designed not to store the private keys, tokens, or passwords that would let an attacker connect to customer machines. On the sobering side, shortly after disclosure, tranches of AnyDesk account credentials were reported [offered for sale on the dark web](https://www.infosecurity-magazine.com/news/anydesk-hit-cyberattack-customer/) — a reminder that portal credentials are worth resetting even when the vendor says devices are safe. Exact dates and figures were reported variously at the time, so confirm the specifics against AnyDesk's advisories and neutral coverage rather than any single summary, including this one.
+
+The honest takeaway isn't "AnyDesk is uniquely insecure." Every major remote-access vendor has an incident history. The takeaway is about **vendor-concentration risk**: when a third party operates the infrastructure that brokers your sessions and holds your account data, a compromise there is a compromise you did not choose and could not prevent.
+
+## The bigger risk isn't a bug — it's scams
+
+For most individuals, the largest AnyDesk-related danger has nothing to do with a CVE. It's social engineering. The [FBI has warned](https://www.fbi.gov/contact-us/field-offices/boston/news/press-releases/fbi-warns-public-to-beware-of-tech-support-scammers-targeting-financial-accounts-using-remote-desktop-software) that tech-support scammers routinely direct victims to install remote-desktop software, then use that access to drain financial accounts. AnyDesk shows up constantly in these schemes, and AnyDesk itself publishes [abuse-prevention guidance](https://anydesk.com/en/abuse-prevention) precisely because it's so commonly weaponized.
+
+Why AnyDesk specifically? It's free to download, installs in seconds, and — critically — the person being _controlled_ doesn't need to create an account. That low friction is a feature for legitimate support and a gift for fraudsters, who phone or email a target, invent an urgent "problem," and walk them through granting full remote control.
+
+This is the fairness point that gets lost in scary headlines: **this is a usage risk, not an AnyDesk vulnerability.** The exact same trick works with TeamViewer, Chrome Remote Desktop, or RustDesk. No amount of AES protects you if you willingly hand the keys to a stranger on the phone. If you want the defensive playbook, we wrote it up separately in [how to avoid remote-desktop scams](/blog/avoid-remote-desktop-scams), and the same reasoning applies to [whether Chrome Remote Desktop is safe](/blog/is-chrome-remote-desktop-safe).
+
+## Closed source and cloud-brokered: the trust question
+
+Here's where AnyDesk's model and RustDesk's part ways — not on whether the encryption is good, but on _what you have to take on faith._
+
+AnyDesk is proprietary. You cannot read the client's source, build it yourself, or independently verify what it does; you trust AnyDesk that the binary behaves as advertised. And by default your sessions are brokered through AnyDesk's cloud, so the availability and security of that infrastructure are the vendor's to manage — as 2024 illustrated. AnyDesk's higher tiers offer an on-premises appliance, which narrows this gap for those who buy in.
+
+RustDesk approaches the same problem from a different assurance basis. The client is [open source under the AGPL](/blog/case-for-open-source-remote-access), so the code is auditable and buildable. Self-hosting also lets you operate the ID/rendezvous, relay, console, and stored deployment data. That can support a [data-sovereignty design](/blog/remote-desktop-data-sovereignty-gdpr), but endpoint locations, direct-session routing, retention, and legal obligations still have to be assessed.
+
+To be equally fair: open source is not a magic shield. RustDesk's own defects are public too, so track the [latest releases](https://github.com/rustdesk/rustdesk/releases) and current vulnerability records. Self-hosting alone does not make a deployment compliant or secure; direct session traffic still flows between endpoints, and you are responsible for patching the server.
+
+## The verdict
+
+Is AnyDesk safe? For deliberate, legitimate use: yes — it's a mature product with standard-grade encryption and sensible account controls, and it's used safely at scale every day. Rate it as reasonably secure, because that's accurate.
+
+The qualifiers are the honest part. Its default cloud-brokered, closed-source model means you're trusting AnyDesk's operational security, which took a real hit in 2024. And its most common real-world harm comes from scammers exploiting how easy it is to install — a human problem, not a cryptographic one. If those trade-offs sit wrong with you, an [open-source, self-hosted alternative](/blog/anydesk-alternative-self-hosted) changes the assurance basis: auditable code and brokering you control, at the cost of running a server yourself.
+
+Whatever tool you choose, the rule that prevents the most damage is the cheapest one: never install remote-access software because someone who contacted _you_ asked you to.
@@ -0,0 +1,70 @@
+---
+publishDate: 2026-07-07T00:00:00Z
+lang: en
+translationKey: is-chrome-remote-desktop-safe
+draft: false
+title: 'Is Chrome Remote Desktop Safe? An Honest Review'
+excerpt: 'Is Chrome Remote Desktop safe? A fair look at its encryption, PIN and Google-account model, the real risks, and where self-hosting differs.'
+image: ~/assets/images/blog/is-chrome-remote-desktop-safe-og.png
+category: Security
+tags:
+  - Chrome Remote Desktop
+  - security
+author: RustDesk Team
+faq:
+  - question: 'Is Chrome Remote Desktop safe to use?'
+    answer: "For casual personal use, Chrome Remote Desktop is reasonably safe. Google states that all remote desktop sessions are fully encrypted, access requires a PIN, and remote-support sessions use one-time access codes. The main risks are weak PINs, compromise of the Google account it's tied to, and — as with any remote tool — scammers talking you into granting access. It gives you limited administrative control and runs entirely on Google's cloud."
+  - question: 'Is Chrome Remote Desktop encrypted?'
+    answer: "Yes. Google's support documentation states that all Chrome Remote Desktop sessions are fully encrypted, and third-party reviews describe it as using standard web transport security. Google does not publish a detailed protocol breakdown on its consumer help pages, so for anything beyond casual use, treat the encryption as adequate but not independently auditable."
+  - question: 'What are the security risks of Chrome Remote Desktop?'
+    answer: 'The three practical risks are a weak or guessable PIN (the minimum is six digits), compromise of the Google account the host is tied to, and social-engineering scams where someone talks a victim into installing it and sharing an access code. Enabling two-factor authentication on your Google account and never sharing a code with someone who contacted you removes most of the real-world danger.'
+  - question: 'Can I self-host Chrome Remote Desktop?'
+    answer: "No. Chrome Remote Desktop is brokered entirely through Google's infrastructure and tied to your Google account; there is no option to run the connection service on your own server or to audit the client code. If self-hosting and code you can inspect matter to you, an open-source alternative is a different assurance model."
+metadata:
+  description: 'Is Chrome Remote Desktop safe? A fair look at its encryption, PIN and Google-account model, the real risks, and where self-hosting differs.'
+  keywords: 'is Chrome Remote Desktop safe, Chrome Remote Desktop security, Chrome Remote Desktop encryption, Chrome Remote Desktop PIN, Chrome Remote Desktop risks, CRD safe'
+---
+
+Short version: for casual personal use, Chrome Remote Desktop (CRD) is reasonably safe. It's a free, no-frills tool from Google that encrypts your session and gates access behind a PIN and your Google account. The honest caveats are that it's closed, entirely Google-cloud-brokered, gives you little administrative control, and — like every remote tool — can be turned against you by a scammer. Here's the fair, sourced breakdown.
+
+## The short answer
+
+CRD is safe enough for the job it's built for: reaching your own machine, or helping a family member, over a connection Google secures for you. Per [Google's own support documentation](https://support.google.com/chrome/answer/1649523), all remote desktop sessions are fully encrypted, unattended access requires a PIN, and one-off support sessions use a single-use access code that only works once. That's a sensible baseline for personal use.
+
+Where you should pause is anything beyond casual use. CRD is tied to your Google account and runs on Google's infrastructure with limited admin controls, and its practical weak points are a guessable PIN, a compromised Google account, and social engineering. None of that makes it dangerous to install — it shapes how much you should rely on it.
+
+## How Chrome Remote Desktop protects a session
+
+Three mechanisms do the real work, all documented on [Google's help pages](https://support.google.com/chrome/answer/1649523):
+
+- **Encryption.** Google states that "all remote desktop sessions are fully encrypted." Independent reviews describe the connection as using standard web transport security (TLS with AES). Google doesn't publish a detailed protocol breakdown on its consumer pages, so treat the encryption as adequate but not something you can independently audit.
+- **PIN for unattended access.** To reach a computer you've set up for ongoing remote access, you enter a PIN. This is what stops a random person with your Google session from silently connecting.
+- **One-time access codes for support.** When you're helping someone in real time, the host generates a code that, per Google, works only once, and continued sharing requires re-confirmation periodically.
+
+Layered on top is the Google account itself, which can — and for remote access, absolutely should — be protected with two-factor authentication. For personal use on a trusted network, this stack is genuinely fine.
+
+## Where the real risks actually are
+
+CRD's weak points aren't exotic. They're the three that follow from its design.
+
+**Weak PINs.** The PIN is the lock on unattended access, and Google's minimum is only six digits. Six digits is fine against a stranger guessing once, but people pick predictable numbers — birthdays, repeats, sequences — which shrinks the real search space well below what the digit count implies. For a machine you leave reachable 24/7, a lazy PIN is the most likely way in. Choose something non-obvious.
+
+**Google-account compromise.** Because unattended CRD is bound to your Google account, that account _is_ the perimeter. If someone phishes your Google password and you don't have two-factor authentication on, your remote desktop is part of what they inherit. This isn't a CRD flaw so much as a consequence of putting all your eggs in the Google-account basket — which is exactly why enabling 2FA on that account is non-negotiable if you use CRD.
+
+**Scams.** As with every remote tool, the biggest real-world harm isn't a cryptographic break — it's social engineering. The [FBI has warned](https://www.fbi.gov/contact-us/field-offices/boston/news/press-releases/fbi-warns-public-to-beware-of-tech-support-scammers-targeting-financial-accounts-using-remote-desktop-software) that tech-support scammers routinely talk victims into installing remote-desktop software and sharing access, then loot their accounts. CRD's one-time codes are easy to read aloud to a "helpful technician" on the phone, which is precisely the problem. To be fair, this is a usage risk, not a CRD vulnerability — the identical trick works with [AnyDesk](/blog/is-anydesk-safe), TeamViewer, or RustDesk. We cover the defensive habits in [how to avoid remote-desktop scams](/blog/avoid-remote-desktop-scams).
+
+## What CRD doesn't give you
+
+CRD is deliberately minimal, and for a lot of people that's the appeal. But it's worth being clear about the trade-offs, especially if you're weighing it for anything past personal use.
+
+You can't self-host it. Every CRD connection is brokered through Google's cloud and tied to a Google account; there's no option to run the rendezvous service on your own server, and no source code to audit — you trust Google that the host behaves as described. There's also little in the way of team administration, centralized policy, access-control lists, session logging, or device grouping. That's not a knock on Google; it's just not what CRD is for. If you need those, you've outgrown it, and a [more capable free remote-desktop tool](/blog/best-free-remote-desktop-software) or a [dedicated Chrome Remote Desktop alternative](/blog/chrome-remote-desktop-alternative) is the honest next step.
+
+This is where an open-source, self-hosted model offers a different _kind_ of assurance rather than just more features. With RustDesk, the client is [open source under the AGPL](/blog/case-for-open-source-remote-access), so the code is auditable and buildable — you don't take the vendor's word for what it does. And self-hosting means the ID/rendezvous and relay servers run on your own machine or VPS, so brokering and access policy stay on infrastructure you control instead of Google's cloud — which maps directly onto [data-sovereignty and GDPR](/blog/remote-desktop-data-sovereignty-gdpr) concerns.
+
+In fairness, that assurance comes with strings. Open source means RustDesk's own bugs are public too; track the [latest releases](https://github.com/rustdesk/rustdesk/releases) and current vulnerability records. Self-hosting does not automatically make a deployment compliant or secure—direct sessions still flow between endpoints, and you own server patching.
+
+## The verdict
+
+Is Chrome Remote Desktop safe? For casual personal use — reaching your own PC, helping a relative — yes, it's reasonably safe, and it's hard to beat for zero-cost simplicity. Rate it accordingly. Turn on two-factor authentication for your Google account, pick a PIN that isn't your birthday, and never read an access code to someone who contacted you first, and you've handled the risks that actually matter.
+
+Where CRD runs out of road is control and scale: it's closed, Google-cloud-brokered, and thin on administration. If you need to audit the code, keep brokering on your own infrastructure, or manage more than a couple of machines, that's the point to look at an open-source, self-hosted option — not because CRD is unsafe, but because it was never trying to be that tool.
@@ -0,0 +1,94 @@
+---
+publishDate: 2026-07-06T00:00:00Z
+lang: en
+translationKey: open-source-remote-desktop-software
+draft: false
+title: 'Open-Source Remote Desktop Software: The Options (2026)'
+excerpt: 'Why teams choose open source remote desktop software — auditability, self-hosting, no lock-in — and where RustDesk fits among the options.'
+image: ~/assets/images/blog/open-source-remote-desktop-software-og.png
+category: Guides
+tags:
+  - RustDesk
+  - open-source
+  - comparison
+author: RustDesk Team
+metadata:
+  description: 'Comparing open source remote desktop software? See why teams pick auditable, self-hosted tools over TeamViewer and AnyDesk — and where RustDesk fits.'
+  keywords: 'open source remote desktop software, self-hosted remote desktop software, open source remote desktop comparison, AGPL remote desktop'
+---
+
+## Open-Source Remote Desktop Software: The Options
+
+Teams shopping for **open source remote desktop software** typically want to inspect the code, control infrastructure, and reduce dependence on a vendor's pricing and hosting decisions.
+
+If that's you, this page lays out what "open source" actually buys you in a remote-desktop tool, what it doesn't, and where RustDesk sits among the options.
+
+### Why teams want open source in the first place
+
+Closed remote-desktop tools ask for a lot of trust. The client runs with high privileges on every machine you support, and the session traffic usually flows through the vendor's cloud. You're trusting a black box — with your customers' desktops on the other end.
+
+Open source changes the trust model in four concrete ways:
+
+- **Auditability.** You (or a security team) can read exactly what the client does. No guessing about telemetry or hidden behavior.
+- **No lock-in.** If the vendor changes direction, you still have the source. You can build it yourself and keep running.
+- **Self-hosting.** The infrastructure can live on hardware you control, instead of a cloud you don't.
+- **Cost predictability.** Open-source cores don't carry a per-seat cloud subscription baked in.
+
+Those concerns are structural: closed tools can change price, packaging, and hosting terms without giving customers control over the underlying software.
+
+### The open-source options, at a glance
+
+"Open source remote desktop" covers a wide range — from protocol-level building blocks to full support platforms. A rough map:
+
+| Option                         | Open source?    | Self-host the server?                    | Built for unattended/[MSP](/blog/rustdesk-for-msps) support? |
+| ------------------------------ | --------------- | ---------------------------------------- | ------------------------------------------------------------ |
+| VNC (TigerVNC, TightVNC, etc.) | Yes             | Yes                                      | Basic; you assemble the rest                                 |
+| Apache Guacamole               | Yes             | Yes                                      | Clientless gateway; needs setup                              |
+| RustDesk                       | Yes (AGPL core) | Yes (Server Pro / free community server) | Yes — device groups, address book, custom client             |
+| TeamViewer                     | No              | No                                       | Yes (vendor cloud)                                           |
+| AnyDesk                        | No              | On-premises offering available           | Yes                                                          |
+
+VNC variants are proven and genuinely open, but you're building the connection, NAT traversal, and access control around them. Guacamole is a great browser-based gateway if you want clientless access, though it's an infrastructure project in its own right. RustDesk aims to give you the auditable, self-hostable core _plus_ the support-team features that closed tools sell — without the closed part.
+
+### Where RustDesk fits: auditable and self-hosted
+
+RustDesk's core is open source under the **AGPL**. You can read the code, audit exactly what the client does, build it yourself, and run the free community server indefinitely. That's the "read the black box" promise made real.
+
+When you move to Server Pro, it's **[self-hosted by design](/blog/why-self-host-remote-desktop-software)**: the ID/rendezvous and relay servers run on your own machine — on-prem or a VPS you rent. You control those services and managed-device data. Sessions connect directly when hole punching succeeds and use your relay when it does not, so endpoint location and routing still matter for [data-residency and GDPR assessments](/blog/remote-desktop-data-sovereignty-gdpr).
+
+### Plan-specific concurrency and licensing
+
+A recurring frustration with closed tools is the pricing model itself. RustDesk standard plans include unlimited concurrent connections and are sized by login users plus managed devices. **Customized V2 is different:** it limits and prices concurrent connections separately. For current allowances and rates, [see rustdesk.com/pricing](https://rustdesk.com/pricing).
+
+It also scales past the "small shop" ceiling: RustDesk publishes [large-fleet planning guidance](/blog/rustdesk-scale-50000-200000-devices) for teams evaluating much larger estates.
+
+### Built for IT teams and MSPs
+
+Open source doesn't have to mean "bring your own everything." RustDesk ships a self-hosted web console, and Basic or higher adds the custom client generator and identity features listed in the current plan matrix. Device groups and a shared address book support scoped access.
+
+### What you get with RustDesk
+
+- **Unlimited [concurrent connections](/blog/rustdesk-concurrent-connections-limit) on standard plans; limited on Customized V2.** Several technicians can run sessions at the same time — you pay [per login-user and per managed-device](/blog/rustdesk-pro-license-cost-how-to-pay), not per channel.
+- **Server-side services you host and control.** Run the ID/relay and management services on your infrastructure; direct sessions still flow between endpoints.
+- **Open source.** The client core is [AGPL](/blog/case-for-open-source-remote-access) — audit it, build it yourself, and run the free community server for as long as you like.
+- **Custom, branded clients.** Generate your own preconfigured, logo-branded installer for the platforms you deploy to.
+- **Access control that fits teams.** [Device groups and a shared address book](/blog/rustdesk-per-user-access-control-device-groups-shared-address-book) decide who can reach which machines; [LDAP/SSO](/blog/rustdesk-active-directory-ldap-sso) (OIDC) is available from the Basic plan and up.
+- **Unattended and attended access.** Permanent-password unattended access for your fleet, plus ad-hoc sessions for one-off support.
+- **Every major platform.** Windows, macOS, Linux, Android, and iOS clients, managed from a [self-hosted web console](/blog/rustdesk-web-console-custom-client-generator-port-21114).
+
+### The honest caveat
+
+Self-hosting is the whole point — and it's also the trade-off. **Someone on your side has to run the server**: provision a host, open the right ports, set up TLS, and patch it over time. That's real, ongoing operational work. If what you actually want is a [zero-maintenance managed SaaS](/blog/rustdesk-self-hosted-vs-cloud-saas-option) with no server to run, be clear-eyed: RustDesk Server Pro is self-hosted by design and is _not_ that. The upside is control and auditability; the cost is that you own the box. Only you can decide if that trade is worth it for your team.
+
+### Try it without a sales call
+
+You can evaluate on your own terms. Self-host the free, open-source community server today, or email [sales@rustdesk.com](mailto:sales@rustdesk.com) for current evaluation terms for the Pro features — or compare plans at [rustdesk.com/pricing](https://rustdesk.com/pricing). Stand it up, point a couple of devices at it, and see whether the trade-offs fit before you commit a cent of real budget. Prefer to watch first? There's a full [video walkthrough](/blog/see-rustdesk-in-action) on the [RustDesk YouTube channel](https://www.youtube.com/@rustdesk).
+
+### Related reading
+
+- [Best free remote desktop software for business (2026)](/blog/best-free-remote-desktop-software)
+- [The case for open-source remote access](/blog/case-for-open-source-remote-access)
+- [RustDesk vs VNC: what the open protocol leaves you to build](/blog/rustdesk-vs-vnc)
+- [Chrome Remote Desktop alternative: self-hosted and open source](/blog/chrome-remote-desktop-alternative)
+- [Why self-host your remote desktop software?](/blog/why-self-host-remote-desktop-software)
+- [Compare RustDesk with Dameware, BeyondTrust, Supremo, Parsec, and RemotePC](/blog/remote-desktop-alternatives-dameware-bomgar-supremo-parsec-remotepc)
@@ -0,0 +1,89 @@
+---
+publishDate: 2026-07-06T00:00:00Z
+lang: en
+translationKey: remote-desktop-alternatives-dameware-bomgar-supremo-parsec-remotepc
+draft: false
+title: 'RustDesk vs Dameware, BeyondTrust, Supremo, Parsec, RemotePC'
+excerpt: 'A comparison hub for teams evaluating RustDesk against Dameware, BeyondTrust/Bomgar, Supremo, Parsec, and RemotePC.'
+image: ~/assets/images/blog/remote-desktop-alternatives-dameware-bomgar-supremo-parsec-remotepc-og.png
+category: Alternatives
+tags:
+  - RustDesk
+  - alternative
+  - comparison
+faq:
+  - question: 'Which of these tools is closest to a self-hosted RustDesk deployment?'
+    answer: 'The products serve different jobs, so there is no single closest match. Dameware and BeyondTrust are commonly evaluated for enterprise administration and support, Supremo and RemotePC for general remote access, and Parsec for low-latency visual workloads. RustDesk is differentiated by its open-source client and self-hosted ID and relay services.'
+  - question: 'Can RustDesk replace Parsec for CAD or creative work?'
+    answer: 'Do not assume so from a feature list. Codec support, color behavior, input latency, GPU use, display topology, and WAN conditions all affect creative workloads. Benchmark the exact applications and hardware before choosing.'
+  - question: 'Is RustDesk cheaper than Dameware, BeyondTrust, Supremo, or RemotePC?'
+    answer: 'It depends on the same users, managed devices, concurrency, support, features, hosting, and operating labor. Compare current written quotes and include self-hosting costs; list prices from different packaging models are not directly comparable.'
+metadata:
+  description: 'A comparison hub for teams evaluating RustDesk against Dameware, BeyondTrust/Bomgar, Supremo, Parsec, and RemotePC.'
+  keywords: 'Dameware alternative, BeyondTrust alternative, Supremo alternative, Parsec alternative, RemotePC alternative'
+author: RustDesk Team
+---
+
+TeamViewer, AnyDesk, and ScreenConnect are not the only tools buyers compare with RustDesk. This page is a comparison hub for several less-searched but still common alternatives, grouped by decision criteria rather than pretending one page can replace a dedicated head-to-head for every brand.
+
+## Start with the workload, not the brand
+
+| Product                    | Typical evaluation focus                                            | What RustDesk changes                                  | Main proof-of-concept risk                                      |
+| -------------------------- | ------------------------------------------------------------------- | ------------------------------------------------------ | --------------------------------------------------------------- |
+| Dameware                   | Windows administration, on-premises control, SolarWinds environment | Open-source client and self-hosted ID/relay services   | Administrative workflow and integration parity                  |
+| BeyondTrust Remote Support | Enterprise support, privileged workflows, governance                | Different licensing and infrastructure model           | Security, audit, approval, and integration requirements         |
+| Supremo                    | Simple attended and unattended support                              | Self-hosted control and centralized Pro administration | Technician workflow and deployment effort                       |
+| Parsec                     | Low-latency graphics and creative work                              | Infrastructure ownership and general remote support    | Codec, GPU, color, audio, and input performance                 |
+| RemotePC                   | Cloud-based access to managed computers                             | Self-hosted brokering and open-source client           | Remote printing, browser/mobile workflow, and server operations |
+
+This table describes evaluation intent, not full feature parity. Use each vendor's current documentation and test the workflows that are mandatory in your environment.
+
+## Replacing Dameware (SolarWinds)
+
+Dameware comparisons usually focus on open-source availability, administrative visibility, deployment platform, and total cost. Confirm the RustDesk Server Pro installation requirements before reusing existing server hardware.
+
+That maps closely to what RustDesk offers: a [self-hosted web console](/blog/rustdesk-web-console-custom-client-generator-port-21114) showing every connected device, unattended access for fleets IT never has to babysit in person, and — because the core client is open source — the "cheaper and auditable" combination Dameware switchers are usually looking for.
+
+## Replacing BeyondTrust (Bomgar)
+
+BeyondTrust/Bomgar comparisons often focus on cost and consolidation. Use current written quotes and a feature-by-feature requirements list.
+
+RustDesk's [per login-user and per managed-device](/blog/rustdesk-pro-license-cost-how-to-pay) licensing, on infrastructure you control, is a direct answer to "the cost has gone out of control": you're not paying an escalating [enterprise](/blog/rustdesk-for-enterprise)-support contract for a cloud you don't own.
+
+## Replacing Supremo
+
+Supremo comparisons tend to focus on performance and price. Benchmark both products on the same network and compare current concurrency terms: RustDesk standard plans are unlimited, while Customized V2 is limited.
+
+## Replacing Parsec
+
+Parsec comparisons often involve VDI, CAD, or creative workloads. Performance-sensitive buyers should run a proof of concept on their own hardware rather than infer results from someone else's benchmarks.
+
+For this group, the self-hosted web client is usually the first thing they want to test — RustDesk lets you validate real-world performance on your own infrastructure before committing at scale, rather than taking a vendor's word for it.
+
+## Replacing RemotePC
+
+RemotePC and RealVNC comparisons typically cover price, reliability, and self-hosting. Test the exact workflows you depend on before committing.
+
+## Use a weighted replacement scorecard
+
+Assign each requirement a weight and score only after a hands-on test. At minimum include attended support, unattended access, elevation, file transfer, multi-monitor, platform coverage, client deployment, identity, per-device authorization, audit events, relay performance, recovery, and operating effort. Price the configuration that passes the scorecard—not the cheapest tier from each vendor.
+
+RustDesk standard plans include unlimited concurrent connections, while Customized V2 has a defined allowance. All commercial plans must also fit both login-user and managed-device counts. Features such as custom client generation and identity controls vary by plan, so verify the current [pricing matrix](https://rustdesk.com/pricing).
+
+## More focused comparisons
+
+- For cloud access to a fixed set of computers, see the [self-hosted GoToMyPC alternative](/blog/gotomypc-alternative-self-hosted).
+- For browser-led support teams and Zoho users, see the [Zoho Assist alternative](/blog/zoho-assist-alternative-self-hosted).
+- For LogMeIn Central, Pro, or Rescue workflows, see [RustDesk vs LogMeIn](/blog/rustdesk-vs-logmein).
+- For protocol-level trade-offs, compare [RustDesk vs RDP](/blog/rustdesk-vs-rdp) and [RustDesk vs VNC](/blog/rustdesk-vs-vnc).
+- For MSP support operations, use [RustDesk vs ScreenConnect](/blog/rustdesk-vs-screenconnect).
+
+## The honest caveat
+
+Self-hosting means someone on your side runs the server: provisioning, ports, TLS, and patching. If your team wants a fully managed cloud with nothing to maintain, that's a real trade-off to weigh — RustDesk Server Pro is [self-hosted by design](/blog/why-self-host-remote-desktop-software).
+
+## Try it without a sales call
+
+- **Self-host the free community server today** — open source, no cost, no expiry.
+- **Want to try the Pro features?** Email [sales@rustdesk.com](mailto:sales@rustdesk.com) to ask about current evaluation terms, or check [rustdesk.com/pricing](https://rustdesk.com/pricing) for standard plan rates.
+- **Prefer to see it first?** Watch a full [video demo](/blog/see-rustdesk-in-action) on the [RustDesk YouTube channel](https://www.youtube.com/@rustdesk) — no booking required.
@@ -0,0 +1,83 @@
+---
+publishDate: 2026-07-06T00:00:00Z
+lang: en
+translationKey: remote-desktop-data-sovereignty-gdpr
+draft: false
+title: 'Remote Desktop Data Sovereignty & GDPR: Self-Hosting'
+excerpt: 'How self-hosting gives regulated teams control over rendezvous, relay, and device data — and which GDPR and compliance questions remain.'
+image: ~/assets/images/blog/remote-desktop-data-sovereignty-gdpr-og.png
+category: Security
+tags:
+  - RustDesk
+  - security
+  - GDPR
+  - self-hosting
+author: RustDesk Team
+metadata:
+  description: 'Remote desktop data sovereignty & GDPR: what self-hosting controls, how direct and relayed sessions differ, and why compliance needs more than server location.'
+  keywords: 'remote desktop data sovereignty, GDPR remote access, remote desktop data residency, self-hosted remote access compliance'
+---
+
+If your organization is bound by GDPR, healthcare privacy rules, or a public-sector "our data stays on our infrastructure" mandate, one question decides which remote desktop tool you can even shortlist: **where does the session data actually go?**
+
+With most mainstream remote-access products, the answer is "through the vendor's cloud." Your technician connects, your endpoint connects, and the traffic is brokered by servers you don't own, in a jurisdiction you may not control. For a lot of buyers that's fine. For regulated teams, it's a compliance problem before anyone has even shared a screen.
+
+This guide is about **remote desktop data sovereignty**: what it means, why it matters for regulated and EU buyers, and which parts of a remote-access deployment self-hosting lets you control. We'll use RustDesk as the worked example.
+
+## What "data sovereignty" means for remote access
+
+Data sovereignty is the principle that data is subject to the laws of the country where it's physically stored and processed. For remote support, the sensitive data isn't just files you transfer — it's the session itself: what's on the screen, the list of devices you manage, the connection metadata, and often the routing of the pixels in real time.
+
+The core questions are: **which systems store metadata, which systems relay traffic, and where are both endpoints?** Self-hosting can remove a vendor-operated rendezvous or relay service from the path, but it cannot guarantee that a session between endpoints in different countries remains in one jurisdiction.
+
+## The core difference: vendor cloud vs. your infrastructure
+
+This is where architecture, not marketing, decides the outcome.
+
+**RustDesk Server Pro is self-hosted.** The ID/rendezvous server, relay server, web console, and managed-device data run on infrastructure you choose. RustDesk first attempts a direct peer-to-peer connection through hole punching; if that fails, session traffic uses your configured relay. This gives you control over the rendezvous/relay layer and stored device data, but the endpoints and their network routes still determine where direct traffic travels.
+
+|                                | Vendor-cloud tools     | Self-hosted RustDesk                                                                        |
+| ------------------------------ | ---------------------- | ------------------------------------------------------------------------------------------- |
+| Where sessions are coordinated | Vendor's cloud         | Your ID/rendezvous server                                                                   |
+| Where session traffic flows    | Vendor-defined routing | Direct between endpoints when possible; otherwise through your relay                        |
+| Who controls data residency    | The vendor             | You choose server-side location and relay policy; endpoints still matter                    |
+| Auditability of the client     | Usually closed source  | [Open source (AGPL)](/blog/case-for-open-source-remote-access) — read and build it yourself |
+| Who runs the server            | Vendor                 | Your team                                                                                   |
+
+Teams evaluating self-hosting often cite the ability to choose the location and operator of the rendezvous, relay, and management systems. That is a meaningful control, but it must be documented together with endpoint locations and routing behavior.
+
+## Benefit 1: You control the server-side data location
+
+Placing the ID, relay, and management services in a German data center lets you document where those services and their stored data reside. If both endpoints are also within the required boundary and policy forces traffic through an approved relay, you can design a more constrained route. Without those additional controls, server placement alone does not establish that all session traffic remains in Germany.
+
+## Benefit 2: Open source means you can prove it, not just trust it
+
+Data sovereignty isn't only about location — it's about knowing what the software does. RustDesk's core is **open source under AGPL**. You (or your security team) can read the code, audit exactly what the client does, build it yourself, and run the free community server indefinitely. That auditability matters more than usual right now: buyers in regulated sectors have grown wary after publicly reported incidents such as [AnyDesk's 2024 security incident](https://www.infosecurity-magazine.com/news/anydesk-hit-cyberattack-customer/) and the [2024 ConnectWise ScreenConnect vulnerability](https://www.cisa.gov/news-events/alerts/2024/02/22/cisa-adds-one-known-exploited-connectwise-vulnerability-cve-2024-1709-catalog). Being able to inspect the client yourself is a concrete answer to "how do we know?"
+
+## Benefit 3: Sovereignty without a licensing tax
+
+RustDesk standard plans are licensed **per login-user plus per managed-device** and include unlimited concurrent connections; Customized V2 instead limits and prices concurrent connections. You can [upgrade a license](/blog/upgrade-rustdesk-license-mid-subscription) as requirements change. Check the current plan matrix before purchasing.
+
+The architecture also scales with your estate: RustDesk publishes [large-fleet planning guidance](/blog/rustdesk-scale-50000-200000-devices) for teams evaluating bigger deployments. For [per-user access control](/blog/rustdesk-per-user-access-control-device-groups-shared-address-book), self-hosted deployments include a [web console](/blog/rustdesk-web-console-custom-client-generator-port-21114), a custom-branded client generator, device groups with a shared address book, and [LDAP/SSO](/blog/rustdesk-active-directory-ldap-sso) (OIDC) available from the Basic plan and up.
+
+## The honest caveat: someone has to run the server
+
+Self-hosting has a real cost: **someone on your side runs and secures the server.** You provision a host, restrict ports, configure TLS, manage access, retain logs, patch components, and document data flows. Self-hosting can support a GDPR program, but it does not by itself make a deployment GDPR-compliant; lawful basis, processor/controller roles, retention, access controls, endpoint locations, incident response, and other obligations still apply.
+
+## GDPR and sovereignty deployment checklist
+
+Self-hosting gives you choices; the deployment has to turn those choices into controls:
+
+- Document where the ID server, relay, console, backups, logs, and administrators are located.
+- Map direct peer-to-peer routes separately from relayed routes. A server in Germany does not keep a direct session between Germany and another country inside Germany.
+- Decide when relay must be forced because routing through a controlled location matters more than peer-to-peer performance.
+- Record the purpose, retention period, and access policy for device, account, audit, and connection metadata.
+- Apply least-privilege device groups, MFA/SSO where available, and a joiner-mover-leaver process for technicians.
+- Put the web console behind HTTPS, restrict administrative network access, and test backup restoration.
+- Complete the appropriate legal assessment—such as records of processing, processor review, transfer assessment, and DPIA—based on your use case.
+
+RustDesk can support a sovereignty architecture, but the controller remains responsible for the architecture and its legal basis.
+
+## Try it without a sales call
+
+You can evaluate on your own terms. Self-host the free, open-source community server today, or email [sales@rustdesk.com](mailto:sales@rustdesk.com) for current evaluation terms for the Pro features. Check current plans and exact features at [rustdesk.com/pricing](https://rustdesk.com/pricing). Prefer to watch first? There's a full [video walkthrough](/blog/see-rustdesk-in-action) on the [RustDesk YouTube channel](https://www.youtube.com/@rustdesk).
@@ -0,0 +1,58 @@
+---
+publishDate: 2026-07-06T00:00:00Z
+lang: en
+translationKey: rustdesk-active-directory-ldap-sso
+draft: false
+title: 'RustDesk LDAP, Active Directory & SSO Support'
+excerpt: "RustDesk Server Pro supports LDAP, Active Directory, and OIDC SSO from the Basic plan up. Here's how identity keying works and the one setup gotcha to avoid."
+image: ~/assets/images/blog/rustdesk-active-directory-ldap-sso-og.png
+category: Deployment
+tags:
+  - RustDesk
+  - deployment
+  - enterprise
+author: RustDesk Team
+faq:
+  - question: 'Does RustDesk Server Pro support LDAP and Active Directory login?'
+    answer: 'Yes. RustDesk Server Pro supports LDAP / Active Directory authentication starting from the Basic plan (the entry-level Individual tier does not include it). Users sign in with their existing directory credentials, and the username acts as the stable unique identifier, so it is best not to change it once accounts are provisioned. Always check rustdesk.com/pricing for the current plan matrix.'
+  - question: 'Does RustDesk support single sign-on (SSO) in addition to LDAP?'
+    answer: 'OIDC-based single sign-on is available from the Basic plan and up, alongside LDAP / Active Directory. For SAML specifically, or for the current list of supported identity providers, check the RustDesk docs, since supported protocols change between releases.'
+  - question: "What happens to a user's access if I move them to another AD organizational unit?"
+    answer: 'Access is unaffected. RustDesk keys identity on the username, not the full Distinguished Name (DN), so moving a user between OUs changes their DN but not their RustDesk identity. Renaming the username, however, breaks the mapping, so treat usernames as immutable once provisioned.'
+  - question: 'Is LDAPS with an internal certificate authority supported?'
+    answer: 'LDAPS with a custom PKI certificate was not yet supported as of this writing. If your policy requires LDAP over TLS validated against your own internal CA, confirm current status with the RustDesk team and raise the request so your use case is counted.'
+
+metadata:
+  description: 'RustDesk Server Pro supports LDAP, Active Directory, and OIDC SSO from the Basic plan up. How identity keying works and the setup gotcha to avoid.'
+  keywords: 'RustDesk LDAP Active Directory, RustDesk SSO, RustDesk OIDC, RustDesk LDAP setup'
+---
+
+Yes. RustDesk Server Pro supports LDAP and Active Directory-style authentication starting from the Basic plan (the entry-level Individual tier does not include it). Users log in with their existing directory credentials, so you do not maintain a second set of accounts.
+
+## The short answer
+
+LDAP / Active Directory (AD) authentication is available starting from RustDesk's **Basic plan** — it is not included in the entry-level Individual tier. OIDC-based single sign-on (SSO) is available from the same Basic plan and up. Which plan you choose depends on your number of users and devices, whether you need a custom client (also available from the Basic plan and up), and whether you want a self-hosted web client. The one thing to know before you start: the **username is the unique identifier**, so keep it stable once accounts exist. LDAPS with a custom PKI certificate was not implemented as of this writing — confirm current status with the team. Always check [rustdesk.com/pricing](https://rustdesk.com/pricing) for the current plan matrix, since tiers and feature gating change over time.
+
+## In detail
+
+LDAP is gated to the Basic plan and above rather than included in every paid tier — the entry-level Individual plan is aimed at solo users and doesn't include directory authentication. If LDAP/AD login is a requirement, budget for at least the Basic tier, then size up from there based on your user and device counts, whether you need a [custom-branded client](/blog/rustdesk-web-console-custom-client-generator-port-21114), or a self-hosted web client. [rustdesk.com/pricing](https://rustdesk.com/pricing)
+
+The most important operational detail is how RustDesk keys user identity. It uses the **username as the unique identifier**, not the full Distinguished Name (DN). That distinction matters in real AD environments where objects get reorganized. If you move a user between Organizational Units (OUs), their DN changes, but as long as the username stays the same their RustDesk identity remains stable and their access is unaffected. Conversely, renaming a username can create a mismatch. The practical rule: reorganize your directory freely, but treat usernames as immutable once provisioned.
+
+One current limitation to plan around: **LDAPS with a custom PKI certificate is not yet supported**. If your security policy requires LDAP over TLS validated against your own internal certificate authority, that specific configuration is on RustDesk's feature-request list rather than shipping today. It is worth raising with the team so your use case is counted. [rustdesk.com](https://rustdesk.com)
+
+For setup, you point Server Pro's LDAP configuration at your directory server (bind account, base DN, user search filter) through the admin console. Because the exact fields and console layout evolve between releases, follow the current [RustDesk LDAP documentation](https://rustdesk.com/docs) rather than relying on a static screenshot.
+
+## Who asks this
+
+This comes up most from IT admins, [MSPs](/blog/rustdesk-for-msps), and businesses standardizing on a single identity source. If users move to another Active Directory OU and their DN changes, preserve the username used as RustDesk's unique identifier and validate synchronization in a test environment.
+
+## Related questions
+
+- [Does RustDesk support SSO or SAML in addition to LDAP / Active Directory?](https://rustdesk.com/docs)
+- [Which RustDesk plan do I need for a custom-branded client?](/blog/rustdesk-web-console-custom-client-generator-port-21114)
+- [How does per-user versus per-device licensing work in Server Pro?](/blog/rustdesk-pro-license-cost-how-to-pay)
+- [Can I self-host the RustDesk web client, and which plan includes it?](/blog/rustdesk-web-console-custom-client-generator-port-21114)
+- [Is LDAPS (LDAP over TLS) supported with an internal certificate authority?](https://rustdesk.com/docs)
+
+Evaluating RustDesk for your directory-backed environment? Check the current plan and LDAP details at rustdesk.com, and reach out to the team if you need LDAPS with a custom PKI certificate so they can weigh your requirement.
@@ -0,0 +1,118 @@
+---
+publishDate: 2026-07-08T00:00:00Z
+lang: en
+translationKey: rustdesk-and-remote-access-scams
+draft: false
+title: 'RustDesk and Remote Access Scams: What We Are Doing'
+excerpt: 'Why RustDesk left Google Play, added warnings and public-server login requirements, and how users can harden controlled devices with passwords, 2FA, and IP allowlists.'
+image: ~/assets/images/blog/rustdesk-and-remote-access-scams-og.png
+category: Security
+tags:
+  - RustDesk
+  - security
+  - scams
+author: RustDesk Team
+faq:
+  - question: 'Is RustDesk a scam?'
+    answer: 'No. RustDesk is legitimate open-source remote-access software. Like other remote-desktop tools, however, it can be abused when a scammer persuades someone to install it, start its service, and grant access. RustDesk publishes scam warnings and has added distribution and public-server restrictions to reduce that abuse, but no remote-access product can make social engineering impossible.'
+  - question: 'Why is RustDesk not available on Google Play?'
+    answer: 'RustDesk voluntarily unpublished its Android app from Google Play in September 2023 to prevent further scams targeting users. Android builds remain available from the official RustDesk GitHub releases and F-Droid. Download only from sources you have verified independently, not from a link sent by an unsolicited caller.'
+  - question: 'Why does the RustDesk public server require login?'
+    answer: 'RustDesk says controller login is currently required on its public server because of ongoing scam and botnet abuse. Login is free through supported third-party identity providers. The public server is intended for demonstration and testing rather than production or sensitive work; self-hosting remains available for organizations that need to operate their own infrastructure and policies.'
+  - question: 'How should I protect a device that accepts RustDesk connections?'
+    answer: 'Set a strong, unique permanent password on the controlled device, enable the client’s TOTP connection 2FA, and use its IP allowlist when your controller addresses or CIDR ranges are predictable. Keep trusted-device exceptions narrow. These layers reduce password and network-origin risks, but they cannot protect someone who deliberately gives a scammer the password, current 2FA code, or manual approval.'
+metadata:
+  description: 'How RustDesk responds to remote-access scams through public warnings, Google Play withdrawal, public-server login, controlled-device 2FA, and CIDR IP allowlists.'
+  keywords: 'RustDesk scam, is RustDesk a scam, RustDesk Google Play, RustDesk login required, RustDesk 2FA, RustDesk IP whitelist, remote access scam prevention'
+---
+
+RustDesk is legitimate open-source remote-access software, but legitimate software can be abused. A scammer can call a victim, invent an urgent problem, and persuade that person to install a remote-control tool and grant access. RustDesk is not exempt from that risk, and encryption cannot fix consent obtained through deception.
+
+Our response has been to put warnings and friction at several points in that path: on our website, inside the Android controlled-device flow, at a major distribution channel, and on the public server. Those measures inconvenience legitimate users too. This article documents what we have done, why we did it, and where the limits remain.
+
+## What has RustDesk done about remote-access scams?
+
+| Action                              | What it addresses                                                  | Cost or limitation                                                       |
+| ----------------------------------- | ------------------------------------------------------------------ | ------------------------------------------------------------------------ |
+| Website and client warnings         | A person being instructed to install RustDesk by an unknown caller | A warning can still be ignored                                           |
+| Voluntary Google Play withdrawal    | Easy scam-driven installation through a familiar app store         | Legitimate Android users lose store discovery and automatic Play updates |
+| Login on the public server          | Anonymous scam and botnet use of shared infrastructure             | Legitimate users must sign in and some existing workflows are disrupted  |
+| Controlled-device security controls | Password theft, broad network exposure, and unattended-access risk | They must be configured correctly and cannot defeat willing disclosure   |
+
+These are risk-reduction measures, not a claim that RustDesk is scam-proof.
+
+## Warnings where a potential victim may see them
+
+The [RustDesk support page](https://rustdesk.com/support) opens with a direct scam warning. It tells people who are on the phone with someone they do not know and trust, and who were asked to install RustDesk, to stop. The [RustDesk GitHub repository](https://github.com/rustdesk/rustdesk) also carries a misuse disclaimer against unauthorized access, control, and invasion of privacy.
+
+The warning is also inside the official Android client distributed through [GitHub Releases](https://github.com/rustdesk/rustdesk/releases). On an unlogged-in Android device that will be controlled, tapping **Start service** opens a warning before the screen-capture service starts. The warning tells a user who was directed by an unknown and untrusted caller to stop and hang up. Official builds impose a countdown before the user can continue. Both the [current controlled-side flow](https://github.com/rustdesk/rustdesk/blob/6c578292e8ebbbec708b76986ba8c4bc7c509747/flutter/lib/mobile/pages/server_page.dart#L244-L421) and the [English warning text](https://github.com/rustdesk/rustdesk/blob/6c578292e8ebbbec708b76986ba8c4bc7c509747/src/lang/en.rs#L192-L194) are visible in the open-source repository.
+
+That placement matters. A general security page may reach someone researching a product; a warning at **Start service** reaches the person at the moment an incoming Android session is about to become possible. It still cannot force that person to distrust a convincing caller.
+
+## Why RustDesk is not on Google Play
+
+On September 3, 2023, the official RustDesk X account said: [“We have temporarily unpublished RustDesk from Google Play to prevent further scams targeting users.”](https://x.com/rustdesk/status/1698372220379349421) The link and text are also preserved in the answered [GitHub Discussion #5660](https://github.com/rustdesk/rustdesk/discussions/5660), and the current RustDesk [FAQ states that the project removed itself from Google Play because of scamming](https://github.com/rustdesk/rustdesk/wiki/FAQ#apple--google-store).
+
+RustDesk is therefore **not currently distributed through Google Play**. This was not a claim that the Android client was malware or that every person installing it was at risk. It was a distribution decision intended to reduce a common path used in scam instructions.
+
+The trade-off is real: leaving Google Play reduces discoverability, familiar installation, and automatic store updates for legitimate users. Current Android builds are available from the [official RustDesk GitHub releases](https://github.com/rustdesk/rustdesk/releases) and [F-Droid](https://f-droid.org/packages/com.carriez.flutter_hbb/). Verify the destination yourself. Do not install an APK from a download link sent by an unsolicited support caller. Our [Android and iOS guide](/blog/rustdesk-remote-control-android-ios) lists the current mobile capabilities and installation sources.
+
+## Why the public server requires login
+
+RustDesk's current [public-server login guide](https://github.com/rustdesk/rustdesk/wiki/Login-required-for-public-server) says that controller login is required because of ongoing scamming and botnet abuse. Login is free and uses a supported third-party identity provider such as Google or GitHub; a separate username and password are not offered on the public server. The guide currently says only controllers are required to log in.
+
+This adds an identity step and removes some anonymous access to infrastructure that RustDesk operates for demonstration and testing. It does not govern a private RustDesk server, and it cannot stop a scammer who uses other infrastructure or establishes a new identity.
+
+It also caused disruption. In a [Reddit discussion about the new login error](https://www.reddit.com/r/rustdesk/comments/1sm91xv/getting_this_error_when_trying_to_connect_anyone/), some legitimate users reported being unable to reach home or family devices until they understood and completed the login step. Others objected to linking a third-party identity. Those comments are not evidence that the restriction works or fails against scammers, but they do document its operational cost. Abuse prevention that adds friction should acknowledge that cost plainly.
+
+## How do you secure a controlled RustDesk device?
+
+Platform-level restrictions are only one layer. The owner or administrator of a controlled device should also reduce who can connect and what a stolen credential can do.
+
+### 1. Set a strong, unique permanent password
+
+For [unattended access](/blog/rustdesk-unattended-access-setup), set a **strong, unique permanent password** under the controlled device's RustDesk security settings. Do not reuse the operating-system login, email password, or a password used on another service. Change it immediately if it may have been disclosed.
+
+For attended support, prefer a temporary one-time password or explicit click approval when practical. A strong permanent password reduces guessing, credential stuffing, and password-reuse risk. It does not help if a victim reads that password to a caller.
+
+### 2. Enable 2FA on the controlled device
+
+RustDesk includes TOTP 2FA for incoming connections to a controlled device. On the device that will accept connections, open its security settings, enable **2FA**, scan the QR code with an authenticator, and confirm setup with the six-digit code.
+
+Once enabled, accepting the normal connection password is not enough: the controller must also provide the current six-digit TOTP code before the controlled device authorizes the session. The feature was introduced specifically as [2FA for unattended access](https://github.com/rustdesk/rustdesk/commit/44e6b7dbb0125dc0c288c19a16a944b5d605852b), and its [TOTP implementation is public](https://github.com/rustdesk/rustdesk/blob/master/src/auth_2fa.rs).
+
+RustDesk can optionally trust a controller device and skip later 2FA prompts. Leave that bypass disabled for the strictest behavior. If you use it, review the trusted-device list and remove devices that are lost, replaced, shared, or no longer authorized.
+
+2FA protects against a password that has been guessed, reused, or exposed. It cannot protect someone who gives a scammer both the password and the current authenticator code.
+
+### 3. Restrict incoming connections with an IP allowlist
+
+The RustDesk interface calls this feature **IP Whitelisting**. In explanatory terms, it is an IP allowlist: the controlled device rejects a connection whose source address is outside the configured list before password and 2FA authorization.
+
+Configure it at:
+
+- **Desktop controlled device:** **Settings → Security → Security → Use IP Whitelisting**
+- **Mobile controlled device:** **Settings → Share screen → Use IP Whitelisting**
+
+The setting accepts individual IPv4 or IPv6 addresses and CIDR ranges. CIDR combines a network address with a prefix length. The prefix says how many leading bits are fixed: a larger prefix means a smaller permitted range.
+
+- `203.0.113.10` or `203.0.113.10/32`: one IPv4 address.
+- `203.0.113.0/24`: 256 IPv4 addresses, from `203.0.113.0` through `203.0.113.255`.
+- `2001:db8::10/128`: one IPv6 address.
+- `2001:db8:1234::/64`: one IPv6 subnet.
+
+These are documentation-only example ranges; do not copy them unchanged. Enter your actual controller addresses or networks. Multiple entries may be separated by commas, semicolons, spaces, or new lines. RustDesk documents the setting in its [advanced client configuration reference](https://rustdesk.com/docs/en/self-host/client-configuration/advanced-settings/#whitelist), and the [controlled-side enforcement is visible in source](https://github.com/rustdesk/rustdesk/blob/master/src/server/connection.rs#L1347-L1374).
+
+Use the smallest practical ranges. Fixed office egress addresses and known VPN ranges are good candidates. Dynamic residential addresses and roaming controllers are not. Confirm which source address RustDesk sees in your NAT, VPN, direct, or relay topology, and test the new rule from another session before closing the working session. A wrong address or CIDR can lock out legitimate support staff.
+
+An allowlist narrows where a connection may originate. It does not replace a password or 2FA, and it cannot stop a malicious controller already operating from an allowed network.
+
+## What these measures cannot do
+
+Warnings, store withdrawal, login requirements, strong passwords, 2FA, and IP allowlists each remove part of an attacker's opportunity. None removes the central social-engineering risk: a person can still be persuaded to approve access or disclose every factor.
+
+Self-hosting does not make abuse impossible either. It gives an organization control of its RustDesk server and policies, but a scammer can also operate private infrastructure or distribute a modified client. RustDesk's public-server restrictions should not be mistaken for protection that automatically extends to every self-hosted deployment.
+
+If an unknown caller tells you to install RustDesk, start its service, share a password, disclose a 2FA code, or open a banking site, stop. Our vendor-neutral guide to [spotting, preventing, and recovering from remote-desktop scams](/blog/avoid-remote-desktop-scams) explains the warning signs and what to do if access has already been granted.
+
+Responsibility here is not a single setting or a statement of good intentions. It is the continuing work of warning users, accepting friction where abuse demands it, providing technical controls, documenting their limits, and changing the response as attackers change their methods.
@@ -0,0 +1,58 @@
+---
+publishDate: 2026-07-06T00:00:00Z
+lang: en
+translationKey: rustdesk-concurrent-connections-limit
+draft: false
+title: 'Does RustDesk Limit Concurrent Connections?'
+excerpt: 'Standard RustDesk plans do not cap concurrent connections; Customized V2 does. Learn how plan, user, and device counts affect licensing.'
+image: ~/assets/images/blog/rustdesk-concurrent-connections-limit-og.png
+category: Pricing
+tags:
+  - RustDesk
+  - pricing
+  - licensing
+author: RustDesk Team
+faq:
+  - question: 'How many concurrent connections does RustDesk allow?'
+    answer: 'Standard RustDesk plans (Individual, Basic, and standard Customized) include unlimited concurrent connections. Customized V2 is the exception: it caps concurrent connections and prices additional ones separately. Every paid deployment must also fit its licensed login-user and managed-device counts.'
+  - question: 'What is the difference between a login user and a managed device?'
+    answer: 'The login-user count covers the people who sign in to your RustDesk deployment; the managed-device count covers the endpoints under management. Both must fit your license, and on standard plans concurrency is not metered separately. Concurrency becomes a sizing input only on Customized V2.'
+  - question: 'Can multiple people control the same device at the same time?'
+    answer: 'On Individual, Basic, and standard Customized plans there is no separate concurrency meter, so simultaneous sessions are not capped. On Customized V2, concurrent connections are part of the licensed allowance, so size the plan for the peak number you need.'
+  - question: 'Does RustDesk charge extra for peak-hour usage or overages?'
+    answer: 'Standard plans do not add peak-hour or overage charges, because they count login users and managed devices rather than live sessions. Customized V2 licenses a defined number of concurrent connections and prices additional connections separately, so plan for your busiest period.'
+
+metadata:
+  description: 'Standard RustDesk plans include unlimited concurrent connections, while Customized V2 limits them. Learn how plan, user, and device counts work.'
+  keywords: 'RustDesk concurrent connections, RustDesk concurrent connection limit, RustDesk user vs device licensing, RustDesk concurrent sessions, remote desktop concurrent channels, RustDesk licensing for MSPs'
+---
+
+Standard RustDesk plans include unlimited concurrent connections. **Customized V2 is the exception:** it limits concurrent connections and prices additional connections separately. All paid plans also enforce their licensed login-user and managed-device allowances.
+
+## The short answer
+
+On Individual, Basic, and standard Customized plans, concurrent connections are unlimited. If you choose Customized V2, size the plan for the number of simultaneous connections you need. In either case, also count **login users** (the people who sign in) and **managed devices** (the machines they control).
+
+## In detail
+
+Remote-desktop vendors package simultaneous sessions in different ways. A channel-based model ties capacity to peak live sessions; RustDesk standard plans do not, while Customized V2 does define a concurrency allowance. Compare the busiest support window, not only average use.
+
+Most RustDesk plans use a different model: you count the people who need access and the endpoints they connect to, without a separate concurrency meter. Customized V2 offers different packaging for buyers who prefer to license a defined number of concurrent connections.
+
+The counts mean different things. The **login-user count** covers the people who sign in, while the **managed-device count** covers the endpoints under management. Both must fit the license. Concurrency is an additional sizing input only for Customized V2.
+
+For current allowances and per-connection pricing on Customized V2, check [rustdesk.com/pricing](https://rustdesk.com/pricing).
+
+## Who asks this
+
+This question comes up most from IT admins and [MSPs](/blog/rustdesk-for-msps) evaluating a move from tools that price simultaneous channels separately. The important step is to compare the exact RustDesk plan: standard plans and Customized V2 handle concurrency differently.
+
+## Related questions
+
+- [What is the difference between a user and a device in RustDesk licensing?](/blog/what-counts-as-a-managed-device)
+- [Do I need a separate license for every technician on my team?](/blog/rustdesk-pro-license-cost-how-to-pay)
+- [Can multiple people control the same device at the same time?](/blog/rustdesk-per-user-access-control-device-groups-shared-address-book)
+- [How do I count devices for unattended access?](/blog/what-counts-as-a-managed-device)
+- [Does RustDesk charge extra for peak-hour usage or overages?](/blog/rustdesk-custom-quote-minimum-users-invoice-fees)
+
+Sizing a plan for your team? Count login users and managed devices, then include concurrent connections if you are considering Customized V2.
@@ -0,0 +1,106 @@
+---
+publishDate: 2026-07-07T00:00:00Z
+lang: en
+translationKey: rustdesk-connected-waiting-for-image
+draft: false
+title: 'RustDesk Connected Waiting for Image: Full Fix Guide'
+excerpt: '"Connected, waiting for image" means the remote screen isn''t being captured. Here''s every cause — headless machines, sleep, codecs, drivers — and its fix.'
+image: ~/assets/images/blog/rustdesk-connected-waiting-for-image-og.png
+category: Troubleshooting
+tags:
+  - RustDesk
+  - troubleshooting
+author: RustDesk Team
+faq:
+  - question: 'Why does RustDesk say "Connected, waiting for image"?'
+    answer: "The session established successfully, but the remote machine is not producing a screen image to send. The most common reason is that there is no active display to capture — a headless server with no monitor, a screen that has gone to sleep or locked, or a display the OS won't let RustDesk record. Fix the capture source and the image appears."
+  - question: 'How do I fix RustDesk waiting for image on a headless computer?'
+    answer: 'A machine with no monitor has no framebuffer to capture, so RustDesk has nothing to send. Attach a real monitor, plug in an inexpensive HDMI dummy plug that makes the GPU think a display is connected, or on Linux use the documented headless support path. Waking or keeping the display awake resolves most cases.'
+  - question: 'Does changing the video codec fix the black screen?'
+    answer: 'Often, yes. In the remote session toolbar or settings you can switch between H.264, VP8, and VP9. A codec the remote hardware cannot encode will show a blank or frozen image. On Linux the matching hardware codec library must be present for your CPU or GPU, because it is not always installed automatically.'
+  - question: 'RustDesk shows the image on one PC but not another. Why?'
+    answer: "That points to something local on the failing machine — an asleep or absent display, missing screen-recording permission on macOS, an outdated GPU driver, a hardware-acceleration conflict, or a codec the hardware can't handle. Work through the per-cause fixes in this guide on the machine that fails, not the one that works."
+  - question: 'Could my self-hosted server cause "waiting for image"?'
+    answer: 'Usually the session is already connected by the time you see this message, so the server is doing its job. But an overloaded public relay or a blocked relay port can stall the video stream. For the standard server path, allow TCP 21115-21117 and UDP 21116; allow TCP 21118-21119 only if you use WebSocket clients. Consider self-hosting the relay for more consistent throughput.'
+
+metadata:
+  description: '"RustDesk connected, waiting for image"? Fix the black screen: headless displays, sleep/lock, video codecs, GPU drivers, Wayland, and firewall ports.'
+  keywords: 'RustDesk connected waiting for image, RustDesk black screen, RustDesk waiting for image fix, RustDesk no image, RustDesk HDMI dummy plug, RustDesk video codec, RustDesk hardware acceleration'
+---
+
+If RustDesk says **"Connected, waiting for image"** and then shows a black screen, the good news is that the hard part already worked: the two ends found each other and the session is established. What's missing is the _picture_. Something on the remote machine isn't producing a screen image to send. This guide walks through every known cause, from the single most common one to the edge cases, with a concrete fix for each.
+
+## The short answer
+
+The session connected, but there is no framebuffer to capture. On a remote machine with **no monitor, an asleep or locked display, or a screen the OS won't let RustDesk record**, the video stream has nothing to encode. Give RustDesk a real, awake display to capture — a monitor, an HDMI dummy plug, the right permission, or a compatible codec — and the image appears.
+
+## Start here: is there anything to capture?
+
+By far the most reported cause is a **headless machine** — a server, mini-PC, or workstation running with no monitor attached, or with the display asleep. With no active display, the GPU produces no framebuffer, so RustDesk connects but has nothing to send. This pattern shows up repeatedly in the RustDesk issue tracker, including [reports of black screens specifically when the target's monitor is off](https://github.com/rustdesk/rustdesk/issues/9884) and the long-running ["Connected, waiting for image" thread](https://github.com/rustdesk/rustdesk/issues/222).
+
+Three ways to give it something to capture:
+
+- **Attach a monitor** and make sure it's powered on and awake.
+- **Use an HDMI (or DisplayPort) dummy plug.** These inexpensive adapters make the GPU believe a display is connected, so it keeps rendering a framebuffer for RustDesk to grab. This is the standard fix for headless desktops and home servers.
+- **On Linux, use the documented headless path.** RustDesk supports headless Linux setups, but the configuration differs from a normal desktop session — see the [Linux client documentation](https://rustdesk.com/docs/en/client/linux/).
+
+If a monitor _is_ attached, the next suspect is that it went to sleep.
+
+## Fix by cause
+
+| Cause                          | Signal                              | Fix                                                                                   |
+| ------------------------------ | ----------------------------------- | ------------------------------------------------------------------------------------- |
+| Headless / no display          | Black screen on a server or mini-PC | Attach a monitor, add an HDMI dummy plug, or use the Linux headless path              |
+| Screen asleep / locked         | Worked earlier, black after idle    | Wake the screen; disable sleep/screensaver; on macOS keep it awake with `caffeinate`  |
+| Missing permission (macOS)     | Connects, permanent black           | Grant Screen Recording in Privacy & Security; install the helper for the login screen |
+| Codec mismatch                 | Blank or frozen image               | Switch between H.264 / VP8 / VP9; on Linux install the matching hardware codec        |
+| Hardware acceleration conflict | Black on specific GPUs              | Disable with `--hwaccel=0` or `--render=software`; on Windows try `--render=d3d`      |
+| Outdated GPU driver            | Black after a driver/OS update      | Update the GPU driver (NVIDIA especially)                                             |
+| Wayland session (Linux)        | No consent prompt, blank            | Use an X11/Xorg session, or accept the per-connect PipeWire prompt                    |
+| Network / relay stall          | Sticks on "waiting for image"       | Allow TCP 21115-21117 and UDP 21116; add TCP 21118-21119 for WebSocket clients        |
+
+### Screen sleep, lock, and screensavers
+
+If it worked earlier and went black after the machine sat idle, the display went to sleep.
+
+- **Windows:** set the power plan so the display and the machine never sleep during the hours you need remote access, and disable the screensaver (or set it not to require a password mid-session).
+- **macOS:** keep the display awake with the built-in `caffeinate` command over SSH, e.g. `caffeinate -u -t 3600` to simulate user activity for an hour. Community threads note this reliably wakes a dozing Mac so RustDesk can capture again ([discussion #12574](https://github.com/rustdesk/rustdesk/discussions/12574)).
+- **Android:** the screen must be on to be shared. Touch the display to wake it, and on Android 9+ enable **"Disable permission monitoring"/screen-share protections in Developer options** so the OS doesn't block capture. iOS-to-Android connections to a dozing device with the screen off are a [known "waiting for image" case](https://github.com/rustdesk/rustdesk/issues/11479).
+
+### macOS permissions
+
+macOS refuses to let any app record the screen without explicit consent. If RustDesk connects but stays black on a Mac, open **System Settings → Privacy & Security → Screen Recording** and enable RustDesk, then restart the app. A black screen specifically _at the login window_ means the RustDesk service/helper isn't installed to run before a user logs in — install it for pre-login capture.
+
+### Video codec mismatch
+
+RustDesk can encode the stream several ways, and the default doesn't always suit the remote hardware. In the session toolbar (or Settings), switch the codec between **H.264, VP8, and VP9** and watch for the image to appear ([discussion #12574](https://github.com/rustdesk/rustdesk/discussions/12574)). On Linux there's an extra wrinkle: hardware codecs rely on a library matched to your CPU/GPU, and it is **not always installed automatically**, so a hardware codec can silently produce nothing until the right package is present ([Linux docs](https://rustdesk.com/docs/en/client/linux/)).
+
+### Hardware acceleration and GPU drivers
+
+Some GPUs — NVIDIA configurations come up most often — clash with RustDesk's hardware-accelerated capture and render paths. Two levers help:
+
+- **Disable hardware acceleration** by launching with `--hwaccel=0`, or force software rendering with `--render=software`.
+- **On Windows, try the DirectX path** with `--render=d3d`, which lets the OS grab the screen more dependably on some setups.
+- **Update the GPU driver.** A black screen that started after a driver or OS update is frequently fixed by moving to a current driver, particularly on NVIDIA hardware ([discussion #12574](https://github.com/rustdesk/rustdesk/discussions/12574)).
+
+### Linux and Wayland
+
+On Linux, **Wayland screen capture is experimental**: it goes through PipeWire and the `xdg-desktop-portal`, pops a consent dialog on each connect, and only works inside an active login session — not at the greeter and not truly headless. If you get a blank screen on Wayland, the most reliable move is to log into an **X11/Xorg session** instead, or use the documented headless configuration. See the [Linux client docs](https://rustdesk.com/docs/en/client/linux/) for the current state.
+
+### Network and relay
+
+Because the message contains the word "connected," the session is usually already up — but the _video_ can still stall if the relay is overloaded or a relay port is blocked. For the standard server path, make sure **TCP 21115-21117 and UDP 21116** are reachable end to end. Open **TCP 21118-21119 only if you use WebSocket clients**. The public demo server is shared and its throughput isn't guaranteed, so if you rely on RustDesk daily, [self-hosting your own relay](/blog/self-host-rustdesk-server-hardware-at-scale) gives you far more consistent behavior. If the session itself is dropping or never establishing, that's a different problem — see our guide to [RustDesk not connecting](/blog/rustdesk-not-connecting-troubleshooting).
+
+## Keep everything current
+
+Old builds carry old capture bugs. Update **both** the controlling client and the controlled client to the latest release, and if you self-host, update the server too. Several black-screen reports simply disappear after an update on both ends.
+
+## The open-source advantage
+
+When a black screen defies the checklist, RustDesk gives you something closed-source tools don't: the [actual capture code](/blog/open-source-remote-desktop-software) under an AGPL license. You (or a contractor) can read exactly how capture works on your platform, reproduce the issue, and file a precise report against the public repository — instead of waiting on a vendor's support queue. And because you can [run the relay on your own machine](/blog/why-self-host-remote-desktop-software), you remove the shared-server variable entirely.
+
+## An honest caveat
+
+There is no single switch that fixes "waiting for image," because it isn't one bug — it's a family of capture problems. A headless server, a dozing Mac, a Wayland session, and a stale NVIDIA driver all surface the same message. Work top-down: confirm there's an awake display to capture, then permissions, then codec, then acceleration and drivers. That order resolves the large majority of cases.
+
+Running this across a fleet? A [self-hosted RustDesk deployment](/blog/why-self-host-remote-desktop-software) with the free community server lets you standardize capture settings and eliminate the public relay as a variable — and it costs nothing to start. For commercial features, see [rustdesk.com/pricing](https://rustdesk.com/pricing) or email sales@rustdesk.com.
@@ -0,0 +1,59 @@
+---
+publishDate: 2026-07-06T00:00:00Z
+lang: en
+translationKey: rustdesk-custom-quote-minimum-users-invoice-fees
+draft: false
+title: 'RustDesk Custom Quote: Users, Devices & Billing'
+excerpt: 'How to get a custom RustDesk self-hosted Pro quote, size login users and managed devices, and confirm current billing terms.'
+image: ~/assets/images/blog/rustdesk-custom-quote-minimum-users-invoice-fees-og.png
+category: Pricing
+tags:
+  - RustDesk
+  - pricing
+  - licensing
+author: RustDesk Team
+faq:
+  - question: 'How do I get a custom RustDesk Pro quote?'
+    answer: 'RustDesk publishes Basic, Customized, and Customized V2 self-hosting plans. Size a quote by login users and managed devices, plus concurrent connections for Customized V2. For invoice, bank transfer, taxes, or billing workflow, confirm the current terms on the pricing page or with sales.'
+  - question: 'Does RustDesk license per user or per device?'
+    answer: 'Both. A Customized quote scales along login-user and managed-device counts, and Customized V2 adds a defined number of concurrent connections as a third input. See rustdesk.com/pricing for current allowances.'
+  - question: 'What is the difference between the Basic and Customized self-hosted Pro plans?'
+    answer: 'Basic includes fixed login-user and managed-device allowances. Customized starts from the Basic feature set and adds separately priced users and devices, while Customized V2 also lets you select a limited number of concurrent connections.'
+  - question: 'Is there a minimum number of users required for RustDesk Pro?'
+    answer: 'No fixed public minimum is quoted here. If your team is small, confirm the current entry-level allowances and any minimum with the RustDesk team at sales@rustdesk.com before you buy.'
+  - question: 'Can I pay for RustDesk by bank transfer or invoice?'
+    answer: 'Online checkout follows the displayed flow. For bank transfer or invoice, contact RustDesk for the current fee, tax, and payment instructions rather than assuming a threshold or surcharge that is not shown on the pricing page.'
+
+metadata:
+  description: 'How to size a RustDesk self-hosted Pro custom quote by login users and managed devices, and confirm invoice, bank transfer, and current billing terms.'
+  keywords: 'RustDesk custom quote, RustDesk self-hosted Pro pricing, RustDesk minimum users, RustDesk per-user per-device, RustDesk invoice fee, RustDesk volume pricing'
+---
+
+RustDesk publishes fixed allowances for Basic and configurable user/device allowances for Customized. Customized V2 additionally lets buyers select a limited number of concurrent connections. For larger plans or invoice requirements, contact the sales team.
+
+## The short answer
+
+Choose capacity for both login users and managed devices. If you use Customized V2, include the required concurrent connections as well. For bank transfer, invoice handling, taxes, or settlement timing, use the current pricing page or confirm the terms with sales rather than assuming historical billing rules.
+
+## In detail
+
+Because Customized licensing scales along login-user and managed-device counts, there is no single total for every organization. Customized V2 adds a third input: concurrent connections.
+
+Basic currently includes fixed login-user and managed-device allowances. Customized starts from the Basic feature set and adds separately priced users and devices. Use the live calculator rather than relying on historical quote rules.
+
+The payment method affects timing and total cost. Online checkout follows the displayed flow. For bank transfer or invoice, contact RustDesk for the current fee, tax, and payment instructions. Do not assume a threshold, surcharge, or turnaround time that is not shown on the current pricing page or confirmed in writing.
+
+To keep the process quick, gather your user count, device count, and any billing constraints before you request a quote. That reduces back-and-forth and helps you compare options against the current plan matrix.
+
+## Who asks this
+
+This comes up most often with IT admins, MSPs, and businesses evaluating RustDesk against tools like TeamViewer or AnyDesk, where per-seat pricing can climb quickly at scale. These buyers typically know their headcount and endpoint counts and want a concrete, volume-based number they can take to finance — which is exactly what the custom-quote process is built to deliver.
+
+## Related questions
+
+- [How does RustDesk's per-user and per-device licensing work?](/blog/what-counts-as-a-managed-device)
+- [What is the difference between the Basic and Custom self-hosted Pro plans?](/blog/rustdesk-pro-license-cost-how-to-pay)
+- [Can I pay for RustDesk by bank transfer or invoice?](/blog/rustdesk-pro-license-cost-how-to-pay)
+- Which currencies does RustDesk accept for payment?
+
+Ready for numbers? Enter your required capacity in the live calculator or contact the team for larger plans and bank-transfer terms. [rustdesk.com/pricing](https://rustdesk.com/pricing)
@@ -0,0 +1,95 @@
+---
+publishDate: 2026-07-06T00:00:00Z
+lang: en
+translationKey: rustdesk-for-enterprise
+draft: false
+title: 'RustDesk for Enterprise: Self-Hosted, Scalable, AD-Ready'
+excerpt: 'Why enterprise IT teams choose RustDesk: self-hosted data control, AD/LDAP, device-group access control, and predictable pricing for large fleets.'
+image: ~/assets/images/blog/rustdesk-for-enterprise-og.png
+category: Guides
+tags:
+  - RustDesk
+  - enterprise
+  - self-hosting
+author: RustDesk Team
+metadata:
+  description: 'RustDesk for enterprise: self-host on your own servers for data control, LDAP/AD, device-group access control, and no per-channel pricing.'
+  keywords: 'RustDesk for enterprise, RustDesk enterprise deployment, AD-integrated remote support, enterprise RustDesk architecture'
+---
+
+## RustDesk for enterprise: keep your remote access on your own infrastructure
+
+Enterprise evaluations usually focus on infrastructure control, identity, access policy, auditability, scale, and licensing predictability. Those requirements can be compared directly against public product capabilities and documentation.
+
+If you're evaluating **RustDesk for enterprise** use, the core question is usually the same: can we run remote support at scale, keep the data on infrastructure we control, and tie access to our existing identity system — without a per-channel bill that grows every renewal? This article walks through how RustDesk answers that, and where the honest trade-offs are.
+
+## The core difference: you host it, so you control it
+
+RustDesk Server Pro is **self-hosted**. The ID/rendezvous server, relay, console, and stored deployment data run on infrastructure you operate. Direct sessions still flow between endpoints, while relayed sessions use your configured relay.
+
+That single architectural fact drives most of the enterprise benefits below. It's also why RustDesk's core being **[open source (AGPL)](/blog/case-for-open-source-remote-access)** matters here: your security team can read the code, audit exactly what the client does, build it themselves, and run the free community server indefinitely. For organizations that have to justify every piece of software touching a production endpoint, "you can read the source" is not a marketing line — it's a procurement requirement you can actually satisfy.
+
+## Enterprise architecture questions to answer first
+
+Before comparing feature matrices, make the deployment design explicit:
+
+| Decision            | What the design must state                                                             |
+| ------------------- | -------------------------------------------------------------------------------------- |
+| Identity            | OIDC or LDAP source, MFA policy, break-glass access, and account lifecycle             |
+| Authorization       | Device-group ownership, technician roles, contractor boundaries, and approval model    |
+| Network             | ID and relay placement, direct-vs-relay policy, exposed ports, and regional routing    |
+| Availability        | Capacity assumptions, monitoring, backups, recovery objectives, and multi-relay design |
+| Endpoint management | Supported OS versions, client packaging, configuration enforcement, and update SLA     |
+| Security operations | Logging, retention, alerting, vulnerability response, and incident ownership           |
+| Licensing           | Required login users, managed devices, and any Customized V2 concurrency allowance     |
+
+RustDesk supplies the remote-access components and enterprise controls; your architecture determines whether they meet the organization's availability, compliance, and operating requirements.
+
+Operational monitoring must include unexpected registrations. If a new device appears, follow the [unknown-device investigation workflow](/blog/rustdesk-unknown-devices-antivirus-scanning) and check logs, configuration exposure, credentials, and keys before attributing it to antivirus scanning.
+
+## How RustDesk lines up for enterprise IT
+
+| Enterprise requirement              | RustDesk approach                                                                                                                                   |
+| ----------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------- |
+| What data location can you control? | ID/relay services, console, and stored deployment data; endpoint and direct-session routes still matter.                                            |
+| Concurrent technician sessions      | Standard plans unlimited; Customized V2 limited                                                                                                     |
+| Licensing model                     | Per login-user + per managed-device; [upgrade any time](/blog/upgrade-rustdesk-license-mid-subscription), prorated. No per-channel model.           |
+| Identity integration                | LDAP/SSO (OIDC), available from the Basic plan and up ([see rustdesk.com/pricing](https://rustdesk.com/pricing))                                    |
+| Scale planning                      | Large-fleet guidance is available; validate capacity against your rollout design and operating model.                                               |
+| Source availability                 | Core is open source (AGPL) — auditable and self-buildable.                                                                                          |
+| Evaluation                          | Free community server today, or email sales@rustdesk.com for a Pro trial (or watch a [video walkthrough](https://www.youtube.com/@rustdesk) first). |
+
+## Data control and compliance
+
+Self-hosting lets you choose the location and operator of the rendezvous, relay, console, and stored device data. Direct sessions still flow between endpoints, so server location alone does not guarantee in-country traffic or GDPR compliance. Document the complete [data flow and compliance controls](/blog/remote-desktop-data-sovereignty-gdpr).
+
+This is also a quiet reason cost-driven migrations happen. Many enterprise teams are not only frustrated by price; they are paying for a cloud service and feature bundle they do not fully use. Self-hosting inverts that: you provision what you need, and you're not renting someone else's data center as a mandatory middleman.
+
+## Scale without a per-channel tax
+
+Enterprise deployments fail on two axes: technical ceiling and pricing ceiling. RustDesk addresses both.
+
+On the technical side, RustDesk publishes large-fleet planning guidance for deployments in the tens of thousands of devices, with larger targets requiring workload validation, sizing work, and tuning. Treat that as architecture planning, not as a blanket out-of-the-box benchmark.
+
+RustDesk charges **per login-user and per managed-device**, and upgrades can be prorated. Standard plans include unlimited concurrent connections; Customized V2 limits and prices them separately. Size all relevant counts against the current plan matrix.
+
+## AD/LDAP and access control your admins expect
+
+Enterprise remote access has to answer "who can reach which machines, and can we prove it." RustDesk's paid plans include **LDAP/SSO (OIDC) available from the Basic plan and up**, so you provision technician access against the identity source you already run rather than maintaining a parallel user list.
+
+For structuring access, the self-hosted web console provides **device groups and a shared address book for per-user access control**. The custom client generator and identity features are plan-dependent; [check current availability](https://rustdesk.com/pricing).
+
+## The honest caveat: someone has to run the server
+
+Self-hosting is the whole value proposition — and it's also the cost. It means **someone on your side runs the server**: provision a host, open the right ports, configure TLS, and keep it patched. That's routine work for an enterprise IT team, but it is real work, and it never disappears.
+
+So be clear-eyed. If what you actually want is a [zero-maintenance managed SaaS](/blog/rustdesk-self-hosted-vs-cloud-saas-option) with no server to operate, RustDesk Server Pro is **[self-hosted by design](/blog/why-self-host-remote-desktop-software) and is not that**. The teams happiest with RustDesk are the ones who see running their own server as a feature — the same control that satisfies their compliance team is the control that puts a box on their maintenance schedule. If your organization values data sovereignty and predictable licensing over never touching infrastructure, that trade goes your way.
+
+## Try it before you commit
+
+You can evaluate **[without a sales call](/blog/see-rustdesk-in-action)**. Two paths:
+
+- **Self-host the free, open-source community server today.** It's yours to run indefinitely — good for validating the architecture on your own network.
+- **Want to try the Pro features?** Email [sales@rustdesk.com](mailto:sales@rustdesk.com) to ask about current evaluation terms, or check [rustdesk.com/pricing](https://rustdesk.com/pricing) for standard plan rates.
+
+Either way, stand up a server against your own environment and validate it before you commit.
@@ -0,0 +1,94 @@
+---
+publishDate: 2026-07-07T00:00:00Z
+lang: en
+translationKey: rustdesk-for-linux
+draft: false
+title: 'RustDesk for Linux: The Open-Source Remote Desktop'
+excerpt: 'Install and run RustDesk on Linux: .deb, .rpm, Flatpak and AppImage, X11 vs Wayland, headless and unattended access, and self-hosting the server.'
+image: ~/assets/images/blog/rustdesk-for-linux-og.png
+category: Guides
+tags:
+  - RustDesk
+  - Linux
+  - self-hosting
+author: RustDesk Team
+faq:
+  - question: 'Does RustDesk work on Wayland?'
+    answer: 'Yes, but Wayland support is still experimental. On Wayland, RustDesk captures the screen through PipeWire and the XDG desktop portal, which shows a consent dialog asking you to pick a display, and it works only for the active logged-in session. You cannot capture the Wayland login greeter, and unattended pre-login access still requires X11. For reliable unattended access on Linux, log in with an X11 (Xorg) session.'
+  - question: 'Which package should I install on Linux?'
+    answer: 'Use the .deb on Debian, Ubuntu and Linux Mint, the .rpm on Fedora, RHEL and openSUSE, the Flatpak from Flathub if you want a sandboxed build, or the portable AppImage on other distributions. The .deb and .rpm packages register and start a systemd service so RustDesk survives reboots; the Flatpak and AppImage do not by default.'
+  - question: 'Why does my headless Linux box show a black screen?'
+    answer: "With no monitor attached, X or Wayland never allocates a framebuffer, so there is nothing for RustDesk to capture and the viewer shows a black or waiting-for-image screen. Attach a dummy HDMI/DisplayPort plug, configure a virtual display such as xserver-xorg-video-dummy or VKMS, or enable RustDesk's experimental Linux headless mode so a virtual display is created for you."
+  - question: 'Can I self-host the RustDesk server on Linux?'
+    answer: 'Yes. The RustDesk server (the hbbs ID/rendezvous and hbbr relay processes) is built for Linux and is the standard way to run it. The free open-source community server runs indefinitely at no cost, and Server Pro adds a web console, device groups and a custom client generator on top. Both install on a plain Linux VM or bare-metal host.'
+metadata:
+  description: 'Install and run RustDesk on Linux: .deb, .rpm, Flatpak and AppImage, X11 vs Wayland, headless and unattended access, and self-hosting the server.'
+  keywords: 'RustDesk for Linux, RustDesk Ubuntu, RustDesk Wayland, RustDesk X11, RustDesk Linux install'
+---
+
+Linux users have never had a huge choice of good remote desktop tools, and the ones that exist are usually either closed-source commercial products or aging VNC stacks. RustDesk sits in a different spot: it is an [open-source remote desktop](/blog/open-source-remote-desktop-software) client licensed under the AGPL, it runs natively on all the major distributions, and you can point it at a server you host yourself. That combination — auditable code, native Linux client, and self-hostable infrastructure — is why RustDesk has become one of the go-to answers when someone asks for an open-source remote desktop for Linux.
+
+This guide covers how to install it, the one thing that trips everyone up (X11 versus Wayland), how to get unattended and headless access working, and where the server fits in.
+
+## Installing RustDesk on Linux
+
+RustDesk ships packages for every common Linux packaging format, so you rarely have to build from source. Grab the current release from the [RustDesk releases page on GitHub](https://github.com/rustdesk/rustdesk/releases) or from the [Linux install docs](https://rustdesk.com/docs/en/client/linux/) and pick the format that matches your distribution.
+
+| Format   | Best for                      | Auto-starts a service? | Notes                                                                                                       |
+| -------- | ----------------------------- | ---------------------- | ----------------------------------------------------------------------------------------------------------- |
+| `.deb`   | Debian, Ubuntu, Linux Mint    | Yes (systemd)          | `sudo apt install ./rustdesk-*.deb`                                                                         |
+| `.rpm`   | Fedora, RHEL/CentOS, openSUSE | Yes (systemd)          | `sudo dnf install ./rustdesk-*.rpm`                                                                         |
+| Flatpak  | Any distro, sandboxed         | No                     | `flatpak install flathub com.rustdesk.RustDesk` ([Flathub](https://flathub.org/apps/com.rustdesk.RustDesk)) |
+| AppImage | Any distro, portable          | No                     | May need `libfuse2` on recent Ubuntu; `chmod +x` then run                                                   |
+| AUR      | Arch, Manjaro                 | Depends on package     | Community-maintained (`rustdesk-bin`, `rustdesk-appimage`)                                                  |
+
+The `.deb` and `.rpm` packages are the ones to use if you want RustDesk running as a background service that survives reboots — both register and start a systemd unit automatically. The Flatpak (`com.rustdesk.RustDesk` on [Flathub](https://flathub.org/apps/com.rustdesk.RustDesk)) is a sandboxed build that is convenient for desktop use but does not install a system service by default. The AppImage is the truly distribution-independent option: one file, no installation, runs almost anywhere — handy on distros RustDesk does not package directly, though on newer Ubuntu you may need to install `libfuse2` first.
+
+In practice RustDesk is used across Ubuntu, Debian, Fedora, RHEL/CentOS, openSUSE, Arch and NixOS. If your distribution isn't on that list, the AppImage almost always works.
+
+## X11 vs Wayland: the part that matters
+
+This is the single most important thing to understand about RustDesk on Linux, because it determines whether remote control "just works" or leaves you staring at a black screen.
+
+**X11 (Xorg) is the reliable path.** Under X11, RustDesk reads the framebuffer directly and injects input directly, so screen capture and mouse/keyboard control behave the way you'd expect, and RustDesk can dynamically detect monitor changes. If you want the least-surprising experience — especially for unattended access — log in with an Xorg session. On many display managers you can pick "Xorg"/"X11" from a gear menu on the login screen.
+
+**Wayland works, but it is experimental.** RustDesk has had experimental Wayland support since version 1.2.0. Because Wayland compositors don't allow direct framebuffer access, RustDesk captures the screen through the `xdg-desktop-portal` service and [PipeWire](https://deepwiki.com/rustdesk/rustdesk/6.3.1-wayland-support), and injects input via the kernel's `uinput` module. Two consequences follow from that design:
+
+- **Consent per connection.** The portal shows a dialog asking you to select which display to share. That is a deliberate Wayland security feature, not a RustDesk bug — a background app cannot silently start recording your screen. Portal v4 and newer support a "restore token" so you aren't re-prompted every single time, but the first share requires an on-screen click.
+- **Active session only.** Wayland capture is tied to the logged-in graphical session. You cannot capture the Wayland login greeter, and monitor changes aren't detected mid-session the way they are on X11. Remote access to the login screen still requires X11.
+
+Wayland support keeps improving — RustDesk 1.4.3 (October 2025) [added multi-monitor sharing for Wayland](https://ubuntuhandbook.org/index.php/2025/10/rustdesk-released-1-4-3-with-multi-monitor-for-wayland-virtual-mouse/), for example. But if you connect and see a black screen on a Wayland box, that is almost always the portal/PipeWire path not being satisfied. Our dedicated write-up on [RustDesk connected but waiting for image](/blog/rustdesk-connected-waiting-for-image) walks through the Wayland black-screen case specifically.
+
+## Unattended access on Linux
+
+Unattended access means connecting to a machine with nobody sitting in front of it — the classic remote-support scenario. On Linux the recipe is:
+
+1. Install via `.deb` or `.rpm` so the systemd service is registered, or click **Enable Service** in the app.
+2. In RustDesk, set a strong **permanent password** under the connection settings (and ideally enable two-factor authentication).
+3. Log the machine into an **X11 session** if you need access before or across user logins — Wayland's consent-per-connect model makes true unattended capture awkward.
+
+The honest caveat: unattended access on Wayland is genuinely harder than on X11 because the portal is designed to require a human to approve screen sharing. If unattended reliability matters, choose X11 for that machine. This isn't unique to RustDesk; every Wayland screen-sharing tool wrestles with the same portal model.
+
+## Headless Linux: servers with no monitor
+
+A very common Linux use case is a box with no display attached at all — a home server, a lab machine, a VM. Here the problem isn't RustDesk, it's the graphics stack: with no monitor plugged in, X or Wayland never allocates a framebuffer, so there is literally no image to capture and you get a black screen.
+
+Three ways to give it something to render:
+
+- **A dummy plug** — a cheap physical HDMI/DisplayPort "headless" dongle that makes the GPU think a monitor is attached.
+- **A virtual display driver** — `xserver-xorg-video-dummy` on X11, or a kernel-level option like VKMS.
+- **RustDesk's experimental headless mode** — enable it with `sudo rustdesk --option allow-linux-headless Y`. Per the [Headless Linux Support wiki](https://github.com/rustdesk/rustdesk/wiki/Headless-Linux-Support) it is disabled by default, tested mainly on Ubuntu with GNOME, and expects packages like `xserver-xorg-video-dummy` and `lightdm`. You can fetch the machine's ID with `sudo rustdesk --get-id` and set a password with `sudo rustdesk --password <password>`.
+
+Headless mode is still rough around the edges, so treat it as "works, with care" rather than turnkey.
+
+## Self-hosting the RustDesk server on Linux
+
+Everything above is the _client_. The other half of RustDesk's Linux story is that the **server** — the `hbbs` ID/rendezvous service and the `hbbr` relay — is a Linux-native application and Linux is its natural home. That's what lets you keep session brokering and relayed traffic on infrastructure you own instead of routing through a vendor's cloud.
+
+You have two options. The free, open-source **community server** runs indefinitely at no cost and covers the core connect-and-relay function. **RustDesk Server Pro** adds a self-hosted web console, device groups, a shared address book, a custom-branded client generator, and [LDAP/Active Directory and OIDC SSO](/blog/rustdesk-active-directory-ldap-sso). You are not forced into Docker either — see [running Server Pro without Docker](/blog/rustdesk-server-pro-without-docker) for a plain-VM or bare-metal install. If you're sizing hardware for a large fleet, [self-hosting hardware at scale](/blog/self-host-rustdesk-server-hardware-at-scale) has the capacity planning.
+
+One honest note on self-hosting, the same as everywhere in RustDesk's docs: the free community server and Server Pro are yours to run, patch, and secure. There's no managed NOC watching it for you. That ownership is the whole point — it's also real operational work, and worth being clear-eyed about before you commit. (Server Pro's license also needs an outbound path to rustdesk.com to activate and stay licensed.)
+
+## Getting started
+
+Install the package for your distro, log into an Xorg session if you want the smoothest experience, set a permanent password for unattended access, and — if data sovereignty is your reason for being here — stand up the free community server. For current plan details, [rustdesk.com/pricing](https://rustdesk.com/pricing) is the source of truth, and [sales@rustdesk.com](mailto:sales@rustdesk.com) can talk through Server Pro. Want to see it working first? [See RustDesk in action](/blog/see-rustdesk-in-action).
@@ -0,0 +1,84 @@
+---
+publishDate: 2026-07-07T00:00:00Z
+lang: en
+translationKey: rustdesk-for-mac
+draft: false
+title: 'RustDesk for Mac: Install, Permissions & Unattended'
+excerpt: 'Install RustDesk on Apple Silicon or Intel Macs, grant the right macOS permissions, set up unattended access and file transfer, and connect to your own server.'
+image: ~/assets/images/blog/rustdesk-for-mac-og.png
+category: Guides
+tags:
+  - RustDesk
+  - macOS
+author: RustDesk Team
+faq:
+  - question: 'Which RustDesk build do I need for Apple Silicon?'
+    answer: 'Download the current macOS build from the RustDesk releases and pick the one matching your chip. Recent releases publish separate Apple Silicon (aarch64) and Intel (x86_64) disk images, so choose the aarch64 build for M-series Macs and the x86_64 build for Intel Macs. If a universal build is offered it runs on both.'
+  - question: 'Which macOS permissions does RustDesk need?'
+    answer: "To be controlled, a Mac needs Screen Recording (so RustDesk can capture the display) and Accessibility (so it can move the mouse and type). Some setups also need Input Monitoring. Grant them under System Settings, Privacy and Security. If the remote screen stays black after you granted Screen Recording, remove RustDesk's entry with the minus button and add it back, or reset it with tccutil, then relaunch."
+  - question: 'How do I set up unattended access on a Mac?'
+    answer: 'Open RustDesk, click Install to register it as a background service, set a strong permanent password, and confirm it starts at boot. Then grant Screen Recording and Accessibility so control actually works. For fleet deployment there is an install_service.sh script and MDM path that installs the LaunchDaemon and LaunchAgent, but privacy permissions still have to be granted separately, typically via an MDM PPPC profile.'
+  - question: 'Can RustDesk transfer files to and from a Mac?'
+    answer: 'Yes. RustDesk supports two-way file transfer between the local and remote machine, including to and from macOS, alongside remote view and control. Granting Full Disk Access can help RustDesk reach protected locations.'
+metadata:
+  description: 'Install RustDesk on Apple Silicon or Intel Macs, grant the right macOS permissions, set up unattended access and file transfer, and connect to your own server.'
+  keywords: 'RustDesk for Mac, RustDesk macOS, RustDesk Apple Silicon, RustDesk mac permissions, RustDesk screen recording accessibility, RustDesk mac unattended access, RustDesk mac install'
+---
+
+RustDesk runs natively on macOS, on both Apple Silicon and Intel Macs, and it's one of the few remote desktop tools that is fully [open source](/blog/open-source-remote-desktop-software) and can be pointed at a server you host yourself. The install itself takes a minute. The part that actually determines whether it works is macOS's privacy model — Apple deliberately makes screen capture and input control opt-in, so a couple of permission toggles stand between "installed" and "I can control this Mac." This guide covers the install, exactly which permissions to grant and why, file transfer, unattended access, and connecting to your own server.
+
+## Installing RustDesk on macOS
+
+Download the current macOS build from the [RustDesk releases page](https://github.com/rustdesk/rustdesk/releases) or the [macOS docs](https://rustdesk.com/docs/en/client/mac/), open the `.dmg`, and drag **RustDesk** into your **Applications** folder.
+
+Pick the build that matches your hardware:
+
+- **Apple Silicon (M-series):** the `aarch64` build.
+- **Intel:** the `x86_64` build.
+
+If a universal build is published it runs on both, but when separate images are offered, choosing the right one avoids Rosetta overhead. Because RustDesk is distributed outside the App Store, the first launch may trigger Gatekeeper — if macOS blocks it, open **System Settings → Privacy & Security**, scroll to the security notice, and click **Open Anyway**.
+
+## The permissions that make or break it
+
+This is the section to read carefully, because nearly every "RustDesk connects but the screen is black" report on macOS comes down to a missing permission. macOS gates the two capabilities remote control depends on, and it won't warn you loudly when they're absent.
+
+| Permission           | What it enables                           | Required for                                |
+| -------------------- | ----------------------------------------- | ------------------------------------------- |
+| **Screen Recording** | Capturing and streaming the Mac's display | Seeing the remote screen at all             |
+| **Accessibility**    | Moving the mouse and sending keystrokes   | Controlling the Mac                         |
+| **Input Monitoring** | Reading certain input events              | Some control scenarios                      |
+| **Full Disk Access** | Reaching protected file locations         | File transfer to protected paths (optional) |
+
+Grant them under **System Settings → Privacy & Security**, then find each category (Screen Recording, Accessibility, Input Monitoring) and enable RustDesk. On first launch macOS usually prompts for these automatically; if you dismissed the prompt, you can add RustDesk manually.
+
+A known wrinkle: sometimes Screen Recording _looks_ granted but the remote side still shows a black screen — a [documented macOS permission quirk](https://github.com/rustdesk/rustdesk/issues/3261). The fix is to remove RustDesk from the Screen Recording list with the **minus (−)** button, click **plus (+)** to re-add it from Applications, or reset the permission from Terminal with `tccutil reset ScreenCapture` (and `tccutil reset Accessibility`), then relaunch RustDesk. If you're chasing a black screen, our [connected but waiting for image](/blog/rustdesk-connected-waiting-for-image) guide covers the macOS case in detail.
+
+One more thing to expect: **major macOS upgrades can reset these permissions.** After a big system update, it's worth re-checking that Screen Recording and Accessibility are still enabled for RustDesk, especially on machines you rely on for unattended access.
+
+## File transfer
+
+RustDesk supports two-way file transfer between the local and remote machine, so you can push files to a Mac or pull them off it during a session — no separate tool required. If you need to reach protected folders (Desktop, Documents, or system-managed locations), granting **Full Disk Access** to RustDesk clears the way. For everyday transfers into your user folders, Screen Recording and Accessibility are usually enough.
+
+## Unattended access on a Mac
+
+Unattended access lets you connect to a Mac when nobody's there to click "accept" — the everyday remote-support and remote-work scenario. The manual setup is short:
+
+1. Open RustDesk and click **Install** to register it as a background service (this is what lets it accept connections without a logged-in user clicking through).
+2. Set a strong **permanent password** in the connection settings, and enable **two-factor authentication** if you want the extra layer.
+3. Confirm RustDesk is set to **start at boot**, and that Screen Recording plus Accessibility are granted — without them the service runs but control silently fails.
+
+For deploying across many Macs, RustDesk provides a scriptable path. Per the [macOS auto-start service setup wiki](<https://github.com/rustdesk/rustdesk/wiki/macOS-Auto%E2%80%90Start-Service-Setup-(for-Remote---MDM-Deployment)>), an `install_service.sh` script installs RustDesk (or your custom-branded client) as a service without needing the GUI **Install** button, creating a LaunchDaemon at `/Library/LaunchDaemons/com.carriez.RustDesk_service.plist` and a LaunchAgent at `/Library/LaunchAgents/com.carriez.RustDesk_server.plist`. The daemon starts at boot; the agent starts at the login-window session and persists through login.
+
+The honest catch for fleet admins: **that script does not grant the privacy permissions.** Screen Recording, Accessibility and Input Monitoring must still be provisioned separately — in a managed environment, that means shipping an MDM **PPPC** (Privacy Preferences Policy Control) profile so the permissions are pre-approved. Skip that step and the service will be running but remote control won't work. For the full walk-through beyond macOS specifics, see the [unattended access setup guide](/blog/rustdesk-unattended-access-setup).
+
+## Connecting to your own server
+
+The reason many people choose RustDesk on macOS over a proprietary tool is the same reason it's chosen anywhere: you can run the server yourself. Point the client at your own [self-hosted RustDesk server](/blog/why-self-host-remote-desktop-software)—the free community server or Server Pro—under **Settings → Network → ID/Relay Server**. The ID and relay services are then operated by you; direct sessions still flow between endpoints.
+
+If your workflow crosses desktop and mobile devices, check the separate [Android and iOS control matrix](/blog/rustdesk-remote-control-android-ios), because mobile hosting and control capabilities are not symmetric.
+
+That's also the honest trade-off worth naming: self-hosting means _you_ run and secure that server. There's no managed uptime SLA unless you build one. For a lot of teams — particularly anyone with data-residency requirements — that control is exactly the point; for others, a managed option is a more comfortable fit. Both are legitimate.
+
+## Getting started
+
+Drag RustDesk into Applications, grant Screen Recording and Accessibility, set a permanent password if you need unattended access, and — if you care about keeping session data on your own infrastructure — connect it to the free community server. Current plan details live at [rustdesk.com/pricing](https://rustdesk.com/pricing); for Server Pro questions, email [sales@rustdesk.com](mailto:sales@rustdesk.com). Prefer to watch first? [See RustDesk in action](/blog/see-rustdesk-in-action).
@@ -0,0 +1,87 @@
+---
+publishDate: 2026-07-06T00:00:00Z
+lang: en
+translationKey: rustdesk-for-msps
+draft: false
+title: 'RustDesk for MSPs: One Self-Hosted, Brandable Tool'
+excerpt: 'Compare consolidating TeamViewer, AnyDesk, and ScreenConnect onto one self-hosted, brandable remote-support platform.'
+image: ~/assets/images/blog/rustdesk-for-msps-og.png
+category: Guides
+tags:
+  - RustDesk
+  - MSP
+  - self-hosting
+author: RustDesk Team
+metadata:
+  description: 'RustDesk for MSPs: a self-hosted ScreenConnect/TeamViewer alternative — consolidate remote support with branding, access control, and plan-based concurrency.'
+  keywords: 'RustDesk for MSPs, self-hosted remote support for MSPs, white label remote desktop, ScreenConnect alternative, TeamViewer alternative for MSPs, open source remote support tool, AnyDesk alternative, per-technician remote desktop licensing'
+---
+
+Most MSPs are not looking for another remote-support tool. They are looking for _fewer_ of them.
+
+MSPs often evaluate consolidation when multiple remote-support tools create separate consoles, contracts, and operating procedures. Build the comparison from current contracts and technical requirements.
+
+This is a guide to **RustDesk for MSPs**: how one self-hosted, open-source, brandable tool can replace that pile — and, just as important, where the trade-offs are.
+
+## Why consolidation keeps stalling
+
+The reason MSPs run three tools is rarely preference. It is that each vendor's pricing and limits push you toward a workaround.
+
+The recurring decision factors are price, security, hosting control, and workflow consolidation. Public disclosures and current vendor documentation provide a reliable basis for comparison.
+
+Different vendors, same three complaints: cost that climbs, licensing that limits how you work, and control you never actually had.
+
+## The core difference: you host it, you own it
+
+RustDesk Server Pro is **self-hosted**. The ID/rendezvous server, relay, console, and stored deployment data run on infrastructure you control. Direct sessions still flow between endpoints; relayed sessions use the relay you operate.
+
+The client core is **[open source (AGPL)](/blog/case-for-open-source-remote-access)**. You can read the code, audit exactly what it does on a customer's machine, build it yourself, and run the free community server indefinitely. For an MSP that has to answer "what is this agent doing on our endpoints?" during a security review, that is a materially different conversation than pointing at a closed binary.
+
+Here is how that maps against the tools MSPs commonly consolidate away from:
+
+|                     | Typical cloud RMM/remote tool | RustDesk Server Pro                                                               |
+| ------------------- | ----------------------------- | --------------------------------------------------------------------------------- |
+| Hosting             | Vendor cloud                  | Self-hosted (on-prem or your VPS)                                                 |
+| Source              | Closed                        | Open source (AGPL) core                                                           |
+| Concurrent sessions | Often capped / per-channel    | Unlimited on standard plans; limited on Customized V2                             |
+| Licensing basis     | Per seat / per channel        | [Per login-user + per managed-device](/blog/rustdesk-pro-license-cost-how-to-pay) |
+| Session data path   | Through vendor infrastructure | Server-side services on infrastructure you control                                |
+| Branding            | Add-on or unavailable         | Custom-branded client generator                                                   |
+
+For exact plan tiers and current prices, see [rustdesk.com/pricing](https://rustdesk.com/pricing).
+
+## Plan-dependent concurrent connections
+
+RustDesk standard plans include unlimited [concurrent connections](/blog/rustdesk-concurrent-connections-limit); Customized V2 limits and prices them separately.
+
+You pay per login-user (your technicians) and per managed-device (the machines you support). Several techs can run sessions at the same time without buying "channels." If three engineers are on three different client sites at once during an outage, that is just Tuesday — not a metered event. If you have been rationing simultaneous sessions or timing your team around a channel count, that constraint disappears.
+
+## Brand it, and put access control on it
+
+RustDesk ships the pieces an MSP actually needs to operate at scale: a self-hosted **[web console](/blog/rustdesk-web-console-custom-client-generator-port-21114)**, a **custom-branded client generator**, and **[device groups plus a shared address book](/blog/rustdesk-per-user-access-control-device-groups-shared-address-book)** for per-user access control. **[LDAP/SSO](/blog/rustdesk-active-directory-ldap-sso) (OIDC) is available from the Basic plan and up.**
+
+The branded client matters because clients install a tool configured for your service. Access control can scope technicians to assigned device groups. Custom client generation and identity features are plan-dependent, so verify the current matrix before relying on them.
+
+## Control over server-side data location
+
+Self-hosting gives an MSP control over rendezvous, relay, console, and stored device data. It does not guarantee that direct endpoint traffic stays in one country or establish GDPR compliance by itself; map endpoint locations, routing, retention, and legal obligations.
+
+It also scales beyond proof-of-concept. RustDesk publishes large-fleet planning guidance for teams that need to support bigger estates; validate the rollout against your concurrency, relay, and operating model before treating any sizing figure as universal.
+
+## The honest caveat: someone has to run the server
+
+Self-hosting is the whole point — and it is also the trade-off. **Someone on your side runs the server.** You provision a host, open the right ports, set up TLS, and patch it over time. That is normal infrastructure work for an MSP (arguably you do this for clients every day), but it is real work.
+
+If what you actually want is a [zero-maintenance managed SaaS](/blog/rustdesk-self-hosted-vs-cloud-saas-option) with no server to run and no patching to own, be clear-eyed: **RustDesk Server Pro is [self-hosted by design](/blog/why-self-host-remote-desktop-software), and it is not that.** The upside — control, no concurrent cap, no vendor cloud, no per-channel bill — comes _because_ you host it, not in spite of it. A common evaluation path is simple: start with the free community server on a test VM or small internal host, validate a representative client workflow, then decide whether the Pro features are worth adding.
+
+## Try it without a sales call
+
+You can evaluate RustDesk today with no meeting booked:
+
+- **Self-host the free community server** — open source, run it indefinitely, no time limit.
+- **Want to try the Pro features?** Email [sales@rustdesk.com](mailto:sales@rustdesk.com) to ask about current evaluation terms, or check [rustdesk.com/pricing](https://rustdesk.com/pricing) for standard plan rates.
+- **Prefer to see it first?** [See RustDesk in action](/blog/see-rustdesk-in-action), or head to the [RustDesk YouTube channel](https://www.youtube.com/@rustdesk) — no booking required.
+
+Licensing is per login-user + per managed-device, and you can **[upgrade any time](/blog/upgrade-rustdesk-license-mid-subscription) (prorated)** — no per-channel model, no per-seat cloud subscription stacked on top. Start at [rustdesk.com/pricing](https://rustdesk.com/pricing).
+
+If you are running several remote-support tools today, spin up the community server on a test VM and validate a representative client session before planning migration.
@@ -0,0 +1,56 @@
+---
+publishDate: 2026-07-06T00:00:00Z
+lang: en
+translationKey: rustdesk-lifetime-perpetual-license
+draft: false
+title: 'Does RustDesk Offer a Lifetime License?'
+excerpt: "RustDesk's public Server Pro pricing is term-based rather than lifetime. Confirm current annual or multi-year purchase options before budgeting."
+image: ~/assets/images/blog/rustdesk-lifetime-perpetual-license-og.png
+category: Pricing
+tags:
+  - RustDesk
+  - pricing
+  - licensing
+author: RustDesk Team
+faq:
+  - question: 'Does RustDesk offer a lifetime or perpetual license?'
+    answer: 'The public Server Pro pricing is term-based and does not list a lifetime or perpetual license. Check the current pricing page or written sales terms before purchase.'
+  - question: 'Can I buy RustDesk for multiple years up front?'
+    answer: 'Do not assume a specific multi-year limit or discount. Ask RustDesk to confirm the available term, per-year rate, renewal date, and refund or cancellation conditions in writing.'
+  - question: 'Can I self-host RustDesk Server without a Server Pro license?'
+    answer: 'Yes. The open-source client and community ID and relay server have their own open-source terms. Server Pro is the term-licensed commercial offering for centralized administration and enterprise features.'
+metadata:
+  description: "RustDesk's public Server Pro pricing is term-based rather than lifetime. Confirm current annual or multi-year purchase options before budgeting."
+  keywords: 'RustDesk lifetime license, RustDesk perpetual license, RustDesk multi-year license, RustDesk license term'
+---
+
+RustDesk's public Server Pro pricing is term-based and does not list a lifetime or perpetual license. Confirm any multi-year option and its conditions before budgeting.
+
+## Lifetime and multi-year are not the same
+
+A lifetime license is a one-time payment for indefinite use. A multi-year purchase still ends on a defined date and may have specific renewal, refund, transfer, or capacity-change conditions. Do not describe a long prepaid term as perpetual.
+
+The open-source components are separate from Server Pro. You can run the community ID and relay server under its open-source license; the commercial Server Pro features require the applicable license term.
+
+## What procurement should confirm
+
+Use the current [pricing page](https://rustdesk.com/pricing) for standard plans. If your organization wants a longer term, request written confirmation of:
+
+- start and end dates;
+- covered plan and features;
+- login-user and managed-device allowances;
+- any Customized V2 concurrency allowance;
+- total and per-year price;
+- treatment of mid-term upgrades;
+- renewal, cancellation, refund, and transfer conditions.
+
+Budget Server Pro as a recurring software line unless the signed terms state otherwise. A long term can reduce procurement work, but it also reduces flexibility if requirements change.
+
+## Related questions
+
+- [How much does Server Pro cost?](/blog/rustdesk-pro-license-cost-how-to-pay)
+- [How are users and managed devices counted?](/blog/what-counts-as-a-managed-device)
+- [Can a license be upgraded during its term?](/blog/upgrade-rustdesk-license-mid-subscription)
+- [How do custom quotes and billing work?](/blog/rustdesk-custom-quote-minimum-users-invoice-fees)
+
+Treat only the current pricing page and written order terms as authoritative for the term you are buying.
@@ -0,0 +1,112 @@
+---
+publishDate: 2026-07-07T00:00:00Z
+lang: en
+translationKey: rustdesk-not-connecting-troubleshooting
+draft: false
+title: 'RustDesk Not Connecting: Troubleshooting Guide'
+excerpt: "RustDesk won't connect? Work through ID/relay server settings, firewall and NAT, key mismatches after a reinstall, and when to stop using the public server."
+image: ~/assets/images/blog/rustdesk-not-connecting-troubleshooting-og.png
+category: Troubleshooting
+tags:
+  - RustDesk
+  - troubleshooting
+author: RustDesk Team
+faq:
+  - question: "Why won't RustDesk connect at all?"
+    answer: 'When the session never establishes, the usual causes are a wrong or unreachable ID/rendezvous server, a firewall or NAT blocking the required ports, or a key mismatch after a self-hosted server was reinstalled. Confirm the ID server and key on both clients, then confirm the ports are reachable end to end. That resolves most cases.'
+  - question: 'What is a RustDesk "Key Mismatch" error?'
+    answer: 'It means the public key configured on the client no longer matches the key pair on the server. It commonly appears after you reinstall or migrate a self-hosted server, which generates a fresh key. Copy the current public key from the server and set it in every client under Settings, Network, Key so the client and server agree again.'
+  - question: 'Which ports does RustDesk need open to connect?'
+    answer: 'Core self-hosted ports are TCP 21115-21117 and UDP 21116. TCP 21118-21119 are used for WebSocket clients. Server Pro may use TCP 21114 for HTTP/API access without an SSL proxy, while an HTTPS reverse proxy normally exposes 443. Open only the ports required by your deployment.'
+  - question: "What's the difference between a direct and a relayed connection?"
+    answer: 'RustDesk first tries a direct peer-to-peer link by punching through NAT. If that fails, traffic falls back through the relay server so the session still works, just with more latency. You can force relay mode to sidestep flaky NAT traversal, but relay throughput matters, which is a reason to self-host rather than lean on the public server.'
+  - question: 'Should I stop using the public RustDesk server?'
+    answer: 'The public rendezvous and relay servers are shared and offered without a performance guarantee, so under load they can be slow or refuse new sessions. If connections are unreliable, self-hosting your own server on a VPS or local machine gives you dedicated capacity, a stable key, and full control. The community server is free to run indefinitely.'
+
+metadata:
+  description: 'RustDesk not connecting? Fix ID/relay server settings, firewall and NAT, key mismatch after a reinstall, direct vs relay, and public server overload.'
+  keywords: "RustDesk not connecting, RustDesk won't connect, RustDesk key mismatch, RustDesk failed to connect to relay server, RustDesk ID server, RustDesk firewall ports, RustDesk relay"
+---
+
+When RustDesk connects but shows a black screen, that's a _capture_ problem — covered in our guide to [RustDesk "Connected, waiting for image"](/blog/rustdesk-connected-waiting-for-image). This article is about the other failure: when the **session never establishes at all**. The client spins, times out, or throws an error like "Key Mismatch" or "Failed to connect to relay server." Here's how to diagnose it methodically.
+
+## The short answer
+
+A session that never connects almost always comes down to one of three things: the **ID/rendezvous server is wrong or unreachable**, a **firewall/NAT is blocking the required ports**, or the **client's key no longer matches the server** after a reinstall. Verify the ID server and key on both ends, confirm the ports are open, and most connections come back.
+
+## Diagnose by symptom first
+
+| Symptom                                         | Most likely layer                          | First check                                                                            |
+| ----------------------------------------------- | ------------------------------------------ | -------------------------------------------------------------------------------------- |
+| Client shows “Not ready” or cannot obtain an ID | ID server or DNS reachability              | Resolve the server name and test TCP/UDP 21116 from that client network                |
+| “Key mismatch” or “invalid public key”          | Client/server configuration                | Compare the client key with the server's current `id_ed25519.pub`                      |
+| Peer is found but the session times out         | Firewall, NAT, or relay path               | Test TCP 21117 and review cloud security groups, host firewall, and NAT rules          |
+| Direct connection fails but forced relay works  | NAT traversal                              | Check UDP 21116 and accept relay for symmetric NAT or restrictive networks             |
+| Both direct and relay fail                      | Server address, key, or relay availability | Confirm both peers use the same ID server and inspect `hbbs`/`hbbr` logs               |
+| Session connects but no desktop image appears   | Capture/display permissions                | Use the separate [waiting-for-image guide](/blog/rustdesk-connected-waiting-for-image) |
+| Web console works only over `http://host:21114` | TLS/reverse proxy                          | Configure a certificate and HTTPS reverse proxy on 443                                 |
+
+Change one layer at a time and record the result. Randomly editing the ID server, relay, key, and firewall together makes the root cause harder to identify.
+
+## Step 1: Confirm the ID and relay server settings
+
+RustDesk's ID (rendezvous) server is what lets two peers find each other. If it's wrong, blank, or pointing at a server that's down, nothing connects.
+
+On both the controlling and controlled clients, open **Settings → Network** and check:
+
+- **ID/Rendezvous server** — the domain or IP of your server, entered _without_ a port (the default `21116` is implied). If you use the public network, leave it blank.
+- **Relay server** — likewise entered without a port (`21117` implied) when self-hosting.
+- **Key** — the server's public key (more on this below).
+
+Both peers must point at the **same** server. A frequent mistake is configuring the host you're connecting _to_ but forgetting the machine you're connecting _from_. The [official client-configuration guide](https://rustdesk.com/docs/en/self-host/client-configuration/) explains the ID, relay, API, and public-key fields.
+
+## Step 2: Fix "Key Mismatch"
+
+The **"Key Mismatch"** (or "invalid public key") error means the public key configured on the client doesn't match the key pair the server is running. The classic trigger is **reinstalling or migrating a self-hosted server**, which generates a brand-new key while your clients still hold the old one. This is one of the most common self-hosting stumbles, discussed at length in [RustDesk discussion #1418](https://github.com/rustdesk/rustdesk/discussions/1418) and the [official FAQ](https://github.com/rustdesk/rustdesk/wiki/FAQ).
+
+To fix it:
+
+1. On the server, read the current public key. On a standard install it lives at `/var/lib/rustdesk-server/id_ed25519.pub` (or inside the Docker data volume).
+2. In every client, go to **Settings → Network → Key** and paste that exact value.
+3. Note the key normally **ends in `=`** — that character is part of the key, not a separator, so include it.
+4. For Docker relay setups, make sure the same `id_ed25519` / `id_ed25519.pub` pair is present for both the `hbbs` and `hbbr` components, per the [relay configuration docs](https://rustdesk.com/docs/en/self-host/rustdesk-server-pro/relay/).
+
+To avoid this entirely next time, **back up your key pair before you reinstall** and restore it afterward so clients never need reconfiguring.
+
+## Step 3: Open the right ports
+
+If the ID server and key are correct but sessions still fail — especially with "Failed to connect to relay server" — suspect the firewall or NAT. A self-hosted RustDesk server needs these open end to end:
+
+| Port        | Protocol  | Role                                                  |
+| ----------- | --------- | ----------------------------------------------------- |
+| 21114       | TCP       | Pro web console / API (or 443 behind a reverse proxy) |
+| 21115       | TCP       | NAT type test                                         |
+| 21116       | TCP + UDP | ID registration, heartbeat, NAT hole punching         |
+| 21117       | TCP       | Relay (hbbr)                                          |
+| 21118-21119 | TCP       | Web client / WebSocket support                        |
+
+Open only what your deployment uses: **TCP 21115-21117 and UDP 21116** are the core ports; **TCP 21118-21119** support WebSocket clients. Server Pro can use **TCP 21114** for HTTP/API access without an SSL proxy, while an HTTPS reverse proxy normally exposes **443**. Check every layer: the host firewall (`ufw`, `firewalld`, Windows Defender Firewall), cloud **security groups**, and router **NAT/port-forwarding** rules. The [official self-hosting port table](https://rustdesk.com/docs/en/self-host/) is the source of truth.
+
+## Step 4: Understand direct vs. relayed connections
+
+RustDesk tries a **direct peer-to-peer** connection first, using the ID server to coordinate NAT hole punching. When both peers sit behind cooperative NATs, you get a fast direct link. When hole punching fails—symmetric NAT, strict corporate firewalls, carrier-grade NAT—traffic **falls back to the relay** when that path is reachable, usually with extra latency ([self-hosting architecture](https://rustdesk.com/docs/en/self-host/)).
+
+If direct connections are flaky, you can **force relay mode** to make sessions more deterministic. That trades a little latency for reliability — and it makes relay capacity matter, which is the next point.
+
+Direct IP access is also available for LAN or port-forwarded scenarios: you can enter a target's IP directly to bypass the ID server, though you then lose automatic NAT traversal and relay failover, so both ends must be reachable on the network you configure.
+
+## Step 5: Stop fighting the public server
+
+The public rendezvous and relay are shared infrastructure and are not a substitute for a capacity plan or service commitment. If connections are unreliable and the client, network, and endpoint checks above pass, compare the result with a self-hosted test server before attributing the failure to the public service.
+
+The durable fix is to **self-host**. Running your own server on a small VPS or a local machine gives you dedicated capacity, a stable key you control, and no dependence on someone else's uptime. The **free community server runs indefinitely** at no cost, and you don't need a container runtime to do it — see [running the server without Docker](/blog/rustdesk-server-pro-without-docker). Because the [client is open source](/blog/open-source-remote-desktop-software) and the server is yours, there's no black-box vendor deciding whether your session goes through.
+
+## Step 6: Update everything
+
+Version drift causes connection failures on its own. Older clients and servers can disagree on protocol and key formats, so update **both clients and the server** to current releases before deeper debugging. Several "won't connect" reports resolve at this step alone.
+
+## An honest caveat
+
+Not every connection problem is on RustDesk's side. Symmetric NAT, deep-packet-inspection firewalls, and captive-portal networks can block peer-to-peer traffic in ways no client setting overrides — in those environments, forcing relay through a server _you_ control is the realistic answer, not direct P2P. And self-hosting means you own the uptime: a misconfigured reverse proxy or a lapsed certificate becomes your problem to fix, not a vendor's. For most teams that trade is worth it for the control and privacy; go in clear-eyed about it.
+
+Ready to get off the shared server? Spin up the free community server, point your clients at it, and you're independent — see [why self-hosting is worth it](/blog/why-self-host-remote-desktop-software), or for commercial capabilities check [rustdesk.com/pricing](https://rustdesk.com/pricing) or email sales@rustdesk.com.
@@ -0,0 +1,88 @@
+---
+publishDate: 2026-07-06T00:00:00Z
+lang: en
+translationKey: rustdesk-per-user-access-control-device-groups-shared-address-book
+draft: false
+title: 'RustDesk Per-User Access Control: Restrict Device Access'
+excerpt: 'Use Server Pro Access Control, user assignments, device groups, and cross-group rules to limit which RustDesk users can connect to which devices.'
+image: ~/assets/images/blog/rustdesk-per-user-access-control-device-groups-shared-address-book-og.png
+category: Deployment
+tags:
+  - RustDesk
+  - deployment
+  - MSP
+author: RustDesk Team
+faq:
+  - question: 'How do I restrict a RustDesk user to only certain devices?'
+    answer: 'Use RustDesk Server Pro Access Control. Assign the device directly to the user, or place it in a device group and grant that user or user group access to the group. Review cross-group rules because access permissions are cumulative: any applicable allow rule can broaden the result.'
+  - question: 'How do I set up a shared address book and share it with specific users?'
+    answer: 'A shared address book gives selected users a curated list of devices for visibility and convenience; it is not connection authorization. A user who knows another device ID and its credentials may still attempt a connection, so enforce eligibility with Server Pro Access Control.'
+  - question: 'What are device groups and how do I use them to scope access?'
+    answer: 'A device can be assigned to one device group, and Access Control can grant users or user groups permission to connect to that group. Device-group permissions combine with user-group permissions, so audit both paths and test with real restricted accounts.'
+  - question: 'How do I give a contractor temporary access and revoke it later?'
+    answer: 'Create a dedicated contractor account, assign only the required device or device group, remove broad cross-group access, and test both an allowed device and a known device ID outside the scope. Disable the contractor account when the engagement ends.'
+
+metadata:
+  description: 'Configure RustDesk Server Pro Access Control with user assignments, device groups, and cross-group rules to restrict device access.'
+  keywords: 'RustDesk per-user access control, RustDesk restrict device access, RustDesk device groups, RustDesk Access Control, RustDesk contractor access, limit user access RustDesk'
+---
+
+To restrict which users can connect to which devices, use [RustDesk Server Pro Access Control](https://rustdesk.com/docs/en/self-host/rustdesk-server-pro/permissions/). It decides connection eligibility through **user assignments, device groups, and cross-group access settings**. A shared address book can simplify what a user sees, but it is not the authorization boundary.
+
+## The short answer
+
+For a contractor who should reach one machine:
+
+1. Create a dedicated Server Pro user for the contractor.
+2. Assign the required device directly to that user, or put it in a dedicated device group and grant the user access to that group.
+3. Review user-group and device-group cross-access rules. Access permissions are cumulative, so an allow rule on either path can grant access.
+4. Optionally share a narrow address book for convenience, but do not rely on it to block other device IDs.
+5. Test the contractor account against both the allowed device and a known device ID outside the permitted scope.
+6. Disable the contractor account when the engagement ends.
+
+The target device's password, 2FA, or click-to-confirm prompt remains a separate authentication layer. Access Control answers whether the logged-in user is eligible to reach the device in the first place.
+
+## Access Control and address books solve different problems
+
+**Access Control is authorization.** It determines which users or groups may establish connections to which devices. According to the current RustDesk documentation, a device may be assigned to one user, one device group, or both. Access may also come from user-group and cross-group settings.
+
+**A shared address book controls visibility and convenience, not authorization.** It gives selected users a curated list, aliases, and saved entries. Hiding a machine from that list does not prove the user cannot connect. If the user knows another RustDesk device ID and has valid credentials or receives approval, the address book alone is not the control that should reject the attempt.
+
+**Endpoint authentication is another layer.** A device password, controlled-device 2FA, or manual confirmation proves possession or obtains local consent. It does not replace the server-side decision about which logged-in users are eligible to attempt the connection.
+
+RustDesk also has [Control Roles](https://rustdesk.com/docs/en/self-host/rustdesk-server-pro/control-role/) for what an operator may do after connecting, such as file transfer or terminal access. Control Roles do not decide whether the connection is allowed.
+
+## How Access Control grants permission
+
+Server Pro provides two practical assignment patterns:
+
+- **Direct user assignment:** assign a device to the one user who should reach it. This is straightforward for a contractor and one machine.
+- **Device-group assignment:** place devices with the same access policy in a device group, then grant selected users or user groups access to that group. This is easier to maintain for teams and larger fleets.
+
+The important rule is that permissions are cumulative. Device-group permissions and user-group permissions can both allow access. Do not assume that a narrow direct assignment overrides a broader group rule. Review `Access with other groups`, including the `Can access to` and `Can be accessed from` directions, and review permissions granted directly on every relevant device group.
+
+RustDesk documents that device groups require RustDesk client 1.3.8 or later and RustDesk Server Pro 1.5.0 or later. Confirm current plan and version requirements before designing a production policy.
+
+## Contractor example: allow one device and deny the rest
+
+Use a dedicated contractor account rather than sharing an employee identity. Assign the one required device directly to that user. If you prefer group-based administration, create a narrowly scoped device group, add the device, and grant the contractor account or its user group access only to that device group.
+
+Next, inspect every cumulative permission path. Remove broad user-group cross-access and any device-group rule that would let the contractor reach another group. A narrow address book may still be useful, but treat it as presentation only.
+
+Test the policy with the actual contractor account before issuing it. Confirm that the assigned device connects. Then manually enter a known device ID outside the scope and confirm that Access Control rejects it; absence from the address book is not a sufficient test. Keep the test results with the access request or change record.
+
+When the work ends, disable the contractor user in the console. RustDesk documents that disabled users and disabled devices cannot be accessed. Remove stale group rules as well so they cannot affect a future account assigned to the same group.
+
+## Who asks this
+
+This comes up most from IT admins, [MSPs](/blog/rustdesk-for-msps), and businesses that need to give a contractor, vendor, or auditor access to one machine without authorizing access to the rest of the environment.
+
+## Related questions
+
+- [How does RustDesk Server Pro Access Control work?](https://rustdesk.com/docs/en/self-host/rustdesk-server-pro/permissions/)
+- [What are device groups and cross-group access rules?](/blog/enhanced-acl-in-rustdesk-server-pro-1-5-0)
+- [How do I create and later disable a temporary user account for external access?](/blog/rustdesk-for-enterprise)
+- [How does RustDesk handle per-device passwords and controlled-device 2FA?](/blog/rustdesk-unattended-access-setup)
+- [Does per-user access control require RustDesk Server Pro or a self-hosted server?](/blog/rustdesk-for-enterprise)
+
+Need to give an outside contractor access to one machine? Configure Access Control with a dedicated account, test both the allow and deny paths, and disable the account when the work is done.
@@ -0,0 +1,62 @@
+---
+publishDate: 2026-07-06T00:00:00Z
+lang: en
+translationKey: rustdesk-pro-license-cost-how-to-pay
+draft: false
+title: 'RustDesk Pro Pricing: Cost & Buying Guide'
+excerpt: 'How much does RustDesk Pro cost? Pricing scales with users and devices, with current plans and checkout options listed on rustdesk.com/pricing.'
+image: ~/assets/images/blog/rustdesk-pro-license-cost-how-to-pay-og.png
+category: Pricing
+tags:
+  - RustDesk
+  - pricing
+  - licensing
+author: RustDesk Team
+faq:
+  - question: 'How much does RustDesk Pro cost?'
+    answer: 'A RustDesk Pro license is priced by the number of users and devices you need, so there is no single flat number — check rustdesk.com/pricing. Use the current pricing page for plan details, checkout options, and evaluation terms.'
+  - question: 'Is the RustDesk client free, and what does Pro add?'
+    answer: 'Yes. The RustDesk client is open source and free, and you can self-host the basic relay and signal server at no license cost. A Pro license unlocks the Server Pro feature set — the management, control, and scale features aimed at businesses.'
+  - question: 'Does RustDesk license per user or per device?'
+    answer: 'Both. Pricing is tied to how many login users need seats and how many managed devices you connect to, so your total reflects your own configuration. See rustdesk.com/pricing for current figures.'
+  - question: 'Do you offer volume or annual pricing for MSPs and larger teams?'
+    answer: 'Because pricing scales with your user and device counts, larger deployments are quoted per configuration rather than a fixed sticker. For volume or annual terms, check rustdesk.com/pricing or email sales@rustdesk.com.'
+  - question: 'What are the current evaluation terms for RustDesk Server Pro?'
+    answer: 'Evaluation terms are not fixed in this article. Check the current evaluation path on rustdesk.com/pricing, or email sales@rustdesk.com to confirm what is available for your setup.'
+
+metadata:
+  description: 'How much does RustDesk Pro cost? Pricing scales with users and devices, with current plans and checkout options listed on rustdesk.com/pricing.'
+  keywords: 'RustDesk Pro cost, RustDesk Pro price, RustDesk license cost, how to buy RustDesk license, RustDesk pricing per user and device, RustDesk Server Pro pricing'
+---
+
+RustDesk Pro is priced by how many users and devices you need to cover, rather than as one flat fee — see [rustdesk.com/pricing](https://rustdesk.com/pricing). Use the current pricing page for checkout options and evaluation terms.
+
+## The short answer
+
+There is no single price for RustDesk Pro because it scales with your **number of users and devices** — check [rustdesk.com/pricing](https://rustdesk.com/pricing) for current figures. Because the OSS client itself is free, what you are paying for is Server Pro and its added capabilities. For evaluation terms, see the pricing page or email [sales@rustdesk.com](mailto:sales@rustdesk.com).
+
+## In detail
+
+The reason there is no one-line answer is that RustDesk licensing is tied to usage. Pricing depends on how many **users** (the people who need seats) and how many **devices** (the endpoints you connect to) you want the license to cover. A small team supporting a handful of machines and a larger [MSP](/blog/rustdesk-for-msps) managing hundreds will naturally land at different totals, which is why the price is quoted per your configuration rather than as a fixed sticker. Check [rustdesk.com/pricing](https://rustdesk.com/pricing) for current figures.
+
+If you want to evaluate the paid features before committing, check the current evaluation path on [rustdesk.com/pricing](https://rustdesk.com/pricing) or email [sales@rustdesk.com](mailto:sales@rustdesk.com).
+
+Payment is straightforward: use the current checkout flow shown on the pricing page. If your procurement process has billing or payment constraints, confirm the current options before you purchase.
+
+It is also worth remembering the free/paid split. The RustDesk **client is open source and free**, and you can even self-host the basic relay/signal server at no license cost. The Pro license unlocks the Server Pro feature set (the management, control, and scale features aimed at businesses). So the cost question is really about Server Pro, not about using RustDesk at all.
+
+## Who asks this
+
+This question comes up most often from **IT admins, MSPs, and businesses** comparing RustDesk against tools like TeamViewer and AnyDesk, where renewal pricing has pushed teams to look for alternatives. Many are running a proof of concept and want a concrete number and a clear buying path before they take it to a manager.
+
+## Related questions
+
+- [Is the RustDesk client really free, and what do I get only with Pro?](/blog/case-for-open-source-remote-access)
+- [How does per-user versus per-device licensing work for my team size?](/blog/what-counts-as-a-managed-device)
+- [Can I self-host RustDesk Server for free instead of buying Pro?](/blog/see-rustdesk-in-action)
+- [Do you offer volume or annual pricing for MSPs and larger teams?](/blog/rustdesk-custom-quote-minimum-users-invoice-fees)
+- [What are the current evaluation terms for Server Pro?](/blog/rustdesk-server-pro-free-trial)
+- [Does RustDesk offer a lifetime or perpetual license?](/blog/rustdesk-lifetime-perpetual-license)
+- [Can a reseller or MSP buy licenses for clients?](/blog/rustdesk-reseller-partner-program)
+
+Ready to see the numbers for your setup? Check [rustdesk.com/pricing](https://rustdesk.com/pricing), or email [sales@rustdesk.com](mailto:sales@rustdesk.com) if you need clarification on current evaluation or billing options.
@@ -0,0 +1,87 @@
+---
+publishDate: 2026-07-07T00:00:00Z
+lang: en
+translationKey: rustdesk-remote-control-android-ios
+draft: false
+title: 'RustDesk Android & iOS Remote Control: What Works'
+excerpt: 'How RustDesk remote-controls Android phones, uses mobile apps as controllers, and the honest truth about controlling an iPhone or iPad.'
+image: ~/assets/images/blog/rustdesk-remote-control-android-ios-og.png
+category: Guides
+tags:
+  - RustDesk
+  - mobile
+author: RustDesk Team
+faq:
+  - question: 'Can I remotely control an Android phone with RustDesk?'
+    answer: "Yes. On the Android device you start RustDesk's screen-capture service (which requires an on-screen consent prompt) and enable the RustDesk Input accessibility service so remote taps and swipes are injected. Screen sharing needs Android 6 or newer; sharing internal system audio needs Android 10 or newer. Some manufacturers restrict accessibility for sideloaded apps, so you may have to allow restricted settings first."
+  - question: 'Can RustDesk control an iPhone or iPad?'
+    answer: "No. As of 2026 RustDesk on iOS is controller-only: you can use an iPhone or iPad to control a remote computer, but you cannot view or control an iOS device from elsewhere. Apple's restrictive screen-recording and background APIs are the reason, and iOS host support remains a long-standing, unimplemented feature request. Do not expect to remote into an iPhone with RustDesk today."
+  - question: 'Can I use my phone to control my computer?'
+    answer: 'Yes. The Android and iOS RustDesk apps work as full controller clients. You can connect from either to a Windows, macOS or Linux machine and control it with an on-screen touchpad or mouse mode. This is the most reliable mobile use case and works the same as the desktop client.'
+  - question: 'Are the RustDesk mobile apps open source?'
+    answer: 'Yes. The mobile clients share the same open-source AGPL codebase as the desktop client. Android builds are available from the official RustDesk GitHub releases and F-Droid as com.carriez.flutter_hbb; the iOS controller is available from the Apple App Store. RustDesk is not currently distributed through Google Play.'
+  - question: 'Can I leave an Android device set up for unattended control?'
+    answer: 'Partially. RustDesk can keep its capture service alive with a foreground notification and restart it on boot, but the screen-capture consent, a blocked lock-screen keyboard, and needing to unlock manually after a reboot make truly unattended Android control unreliable. Treat Android control as attended support rather than set-and-forget access.'
+metadata:
+  description: 'How RustDesk remote-controls Android phones, uses mobile apps as controllers, and the honest truth about controlling an iPhone or iPad.'
+  keywords: 'RustDesk Android iOS remote control, remote control phone with RustDesk, RustDesk Android host, control Android remotely, RustDesk iOS, control iPhone remotely, RustDesk mobile app'
+---
+
+"Can I remote into a phone?" is one of the most common questions RustDesk gets, and it deserves an honest answer rather than a marketing one. The short version: RustDesk can genuinely control an Android device, both mobile apps make excellent _controllers_ for your computers, and — the part people don't want to hear — you cannot currently remote into an iPhone or iPad. This guide explains exactly what works, what doesn't, and why, so you can plan around real capabilities instead of assumptions.
+
+Both mobile apps are, like the rest of RustDesk, [open source](/blog/open-source-remote-desktop-software) under the AGPL. Android builds are available from the [official RustDesk GitHub releases](https://github.com/rustdesk/rustdesk/releases) and [F-Droid](https://f-droid.org/packages/com.carriez.flutter_hbb/) as `com.carriez.flutter_hbb`; the iOS controller is on the App Store. RustDesk is [not currently distributed through Google Play](/blog/rustdesk-and-remote-access-scams): it voluntarily unpublished the Android app in response to scam abuse. Same codebase, same auditable core.
+
+## The one-table summary
+
+| Scenario                                          | Supported? | Notes                                                |
+| ------------------------------------------------- | ---------- | ---------------------------------------------------- |
+| Control a Windows/macOS/Linux PC **from** Android | Yes        | Full controller; touchpad or mouse mode              |
+| Control a PC **from** iPhone/iPad                 | Yes        | Full controller                                      |
+| Control **an Android device** (as the host)       | Yes        | Needs screen-capture consent + accessibility service |
+| Control **an iOS device** (iPhone/iPad as host)   | **No**     | Apple restrictions; not implemented                  |
+| View an iOS screen remotely                       | **No**     | Not supported today                                  |
+
+The rest of the article is just the detail behind each row.
+
+## Using your phone as a controller (the easy part)
+
+This is the use case that "just works." Install RustDesk on your Android or iOS device, and it becomes a full controller for any RustDesk host — your Windows desktop, your [Mac](/blog/rustdesk-for-mac), your [Linux box](/blog/rustdesk-for-linux). Enter the target ID and password, and you get the remote screen with an on-screen touchpad, a mouse mode, a software keyboard, and file transfer. Nothing special is required on the phone side because you're only _sending_ control, not being controlled.
+
+If your job is "fix a computer from wherever I am," a phone running RustDesk is a legitimately good tool, and it behaves the same as the desktop client.
+
+## Controlling an Android device (as the host)
+
+This is where RustDesk does something most remote tools can't: it can turn an Android phone or tablet into a controllable host. Two Android subsystems make it work, and both require explicit setup.
+
+**Screen capture.** RustDesk uses Android's `MediaProjection` API to capture the display. When you tap **Start Service** in the app, Android shows a consent prompt asking permission to record the screen — that dialog is mandatory and cannot be silently bypassed. Screen sharing requires **Android 6 or newer**; capturing the phone's **internal system audio** requires **Android 10 or newer**. Until that capture permission is granted, no incoming connection can see anything.
+
+**Remote input.** Seeing the screen isn't the same as controlling it. To inject taps, swipes and key events, RustDesk registers an [`AccessibilityService`](https://deepwiki.com/rustdesk/rustdesk/6.5-mobile-platforms) called **RustDesk Input**, which you enable under **Settings → Accessibility**. It translates remote mouse and gesture events into Android gestures and can trigger system actions like Back, Home and Recents.
+
+**Staying alive.** RustDesk keeps a foreground-service notification and, optionally, a floating overlay window so Android doesn't kill the capture process, and it can restart the service on boot.
+
+Now the honest limitations, because Android's security model imposes real ones:
+
+- **Consent is required to start capture.** Someone (or a pre-approval) has to accept the screen-recording prompt.
+- **The lock screen blocks input.** Android does not let an accessibility service type into the secure lock screen, so if the device locks you generally can't enter the unlock code remotely — a limitation [documented by hands-on users](https://blog.wirelessmoves.com/2025/10/remote-android-support-with-rustdesk-part-1.html).
+- **Reboots need a manual unlock.** After a restart the device usually has to be unlocked in person before control resumes.
+- **OEM restrictions.** On some manufacturers' builds, the **RustDesk Input** accessibility toggle is greyed out for sideloaded apps until you grant "restricted settings" (long-press the app icon → App info → allow restricted settings). Aggressive battery managers on certain OEMs can also kill the background service.
+
+The practical takeaway: Android control is excellent for **attended support** — helping someone who is holding their phone — but it is not a reliable **set-and-forget unattended** solution the way a desktop is. Be honest with yourself about which one you need. (For desktops, the [unattended access setup guide](/blog/rustdesk-unattended-access-setup) covers the real thing.)
+
+## Controlling an iOS device: the honest answer
+
+Here's the part that gets asked constantly and answered vaguely elsewhere, so we'll be direct: **you cannot remotely view or control an iPhone or iPad with RustDesk.** The iOS app is a controller only — it connects _out_ to control your computers, but it cannot act as a host, share its screen, or be controlled from another device.
+
+The reason is Apple. iOS heavily restricts background execution, screen recording, and any form of synthetic input injection, which is why no third-party app offers true remote _control_ of an iPhone. This isn't a RustDesk oversight so much as a platform wall — iOS host support has been a repeatedly [requested feature on GitHub](https://github.com/rustdesk/rustdesk/discussions/4839) that remains unimplemented. Apple's broadcast APIs (ReplayKit) can in principle stream a screen, but full remote control of iOS from another device isn't something the OS permits to third parties.
+
+So if your requirement is "remote into an iPhone," RustDesk is not the tool today, and we'd rather tell you that up front than let you discover it after setup. This limitation is not unique to RustDesk — it's the same wall every remote-desktop vendor hits on iOS, as noted in our [RustDesk vs AnyDesk](/blog/rustdesk-vs-anydesk) comparison.
+
+## A note on privacy and self-hosting
+
+Because the mobile apps are open source and speak the same protocol as the desktop client, you can point them at your own [self-hosted RustDesk server](/blog/why-self-host-remote-desktop-software) instead of the public network — so mobile sessions are brokered by infrastructure you control, ID and all. For remote-support workflows that touch personal devices, that data-sovereignty angle matters more than usual.
+
+The honest caveat is the same as always: self-hosting means you run and secure that server yourself. It's the price of keeping session data on your own turf, and for many teams it's well worth it.
+
+## Getting started
+
+Download Android builds from the [official GitHub releases](https://github.com/rustdesk/rustdesk/releases) or install the package from [F-Droid](https://f-droid.org/packages/com.carriez.flutter_hbb/). RustDesk is [not currently distributed through Google Play](/blog/rustdesk-and-remote-access-scams); the iOS controller remains available from Apple's App Store. To control a phone, that phone must be Android — accept the screen-capture prompt and enable the RustDesk Input accessibility service. To control your computers from a phone, either mobile app works out of the box. Current plans are at [rustdesk.com/pricing](https://rustdesk.com/pricing), and [sales@rustdesk.com](mailto:sales@rustdesk.com) can help with Server Pro. Want to see it first? [See RustDesk in action](/blog/see-rustdesk-in-action).
@@ -0,0 +1,58 @@
+---
+publishDate: 2026-07-06T00:00:00Z
+lang: en
+translationKey: rustdesk-reseller-partner-program
+draft: false
+title: 'Does RustDesk Have a Reseller or Partner Program?'
+excerpt: "RustDesk's public pricing does not describe a formal reseller program. Confirm partner, account-ownership, and renewal terms before quoting clients."
+image: ~/assets/images/blog/rustdesk-reseller-partner-program-og.png
+category: Pricing
+tags:
+  - RustDesk
+  - pricing
+  - MSP
+author: RustDesk Team
+faq:
+  - question: 'Can I resell RustDesk licenses or get a partner discount?'
+    answer: 'The public pricing page does not describe a formal reseller tier or discount. Ask RustDesk to confirm current partner terms, whether an MSP can purchase for a client, and who owns the account and renewal before quoting.'
+  - question: 'Does RustDesk offer volume or bulk discounts for large orders?'
+    answer: 'No public bulk-discount schedule is stated here. Size login users, managed devices, and any plan-specific concurrency, then request written terms for a large order.'
+  - question: 'Does RustDesk integrate with WHMCS or other billing platforms?'
+    answer: 'Public pricing does not document WHMCS integration, deal registration, or automated reseller provisioning. If those are required, confirm current support and API options directly before designing the workflow.'
+  - question: 'Who should own the RustDesk license, the MSP or the client?'
+    answer: 'Decide before purchase. If a client will eventually control renewals or hold the license under their own account, confirm that account-ownership and renewal workflow up front so the billing path matches your service model.'
+
+metadata:
+  description: "RustDesk's public pricing does not describe a formal reseller program. Confirm partner, account-ownership, and renewal terms before quoting clients."
+  keywords: 'RustDesk reseller program, RustDesk partner program, RustDesk reseller discount, buy RustDesk on behalf of clients, RustDesk for MSPs, resell RustDesk licenses'
+---
+
+The public pricing page does not describe a formal reseller tier, partner discount, or channel workflow. If you plan to include RustDesk inside a managed service, confirm the buyer, account owner, renewal owner, support boundary, and commercial terms before quoting it.
+
+## The short answer
+
+If you're an [MSP](/blog/rustdesk-for-msps) or IT provider, do not infer partner rights or discounts from the absence of public documentation. Obtain written confirmation for the current purchase, account-ownership, support, and renewal workflow before building it into your offer.
+
+## In detail
+
+Many MSPs and IT resellers expect tiered discounts, deal registration, co-branded portals, and automated provisioning. Those capabilities are not documented on the public pricing page, so treat them as unanswered requirements until RustDesk confirms them.
+
+That doesn't block you from serving clients, though. The practical route is simply to align the license purchase and account ownership with your service model, then confirm the current process before you commit it to a proposal or contract.
+
+The one wrinkle worth planning for is account ownership. If your client ultimately needs to control renewals or hold the license under their own account, confirm that workflow before purchase so the billing path matches your service model.
+
+A practical note on pricing: build the proposal around services you can deliver—deployment, hosting, support, monitoring, and recovery—and list license charges separately unless written partner terms say otherwise. Confirm current user and device pricing at [rustdesk.com/pricing](https://rustdesk.com/pricing).
+
+## Who asks this
+
+This question comes mostly from MSPs, IT service providers, and regional distributors that want to standardize deployments across clients. They need a documented answer about channel contracts, discounts, deal registration, account ownership, support, and renewals; public silence is not a substitute for those terms.
+
+## Related questions
+
+- [Can I self-host RustDesk Server Pro for multiple clients on one server?](/blog/rustdesk-for-msps)
+- [How does RustDesk per-user vs. per-device licensing work?](/blog/rustdesk-pro-license-cost-how-to-pay)
+- What account ownership and renewal workflow should I confirm before buying for a client?
+- Do you offer volume or bulk discounts for large deployments?
+- [Is there a RustDesk white-label or co-branding option?](/blog/rustdesk-web-console-custom-client-generator-port-21114)
+
+Setting clients up on RustDesk? Review the current plans, then confirm the right billing and account workflow for your client setup at [rustdesk.com/pricing](https://rustdesk.com/pricing).
@@ -0,0 +1,64 @@
+---
+publishDate: 2026-07-06T00:00:00Z
+lang: en
+translationKey: rustdesk-scale-50000-200000-devices
+draft: false
+title: 'Can RustDesk Scale to 200,000 Devices?'
+excerpt: 'See RustDesk first-party operational context for large-fleet planning, what the public-server observation shows, and what a self-hosted rollout must still validate.'
+image: ~/assets/images/blog/rustdesk-scale-50000-200000-devices-og.png
+category: Deployment
+tags:
+  - RustDesk
+  - deployment
+  - enterprise
+author: RustDesk Team
+faq:
+  - question: 'How many devices can a self-hosted RustDesk server handle?'
+    answer: 'RustDesk internal telemetry recorded more than two million online endpoints on one 12-core, 32 GB public-server host on July 7, 2026. This was a point-in-time observation, not an independently audited benchmark or a Server Pro guarantee. Simultaneous sessions, relay traffic, database writes, and management features can change the hardware requirement.'
+  - question: 'What has to be tuned to reach 200,000 devices?'
+    answer: 'Validate online-device churn, simultaneous remote sessions, relay bandwidth, caching, database write performance, and management-console activity against your own workload. The public-server result demonstrates endpoint-presence scale; it does not reproduce every Server Pro workload.'
+  - question: 'Does RustDesk Server Pro support high availability or load balancing?'
+    answer: 'For very large fleets, high availability and load balancing are worth designing in, but the specifics such as relay redundancy, database failover, and how sessions are distributed should be validated with RustDesk against your workload rather than assumed as out-of-the-box defaults.'
+  - question: 'Is public RustDesk infrastructure sized the same as a self-hosted deployment?'
+    answer: 'Not necessarily. The public-server figure measures online endpoints, not two million simultaneous remote-control sessions. A self-hosted Server Pro deployment can add different database, console, policy, audit, and relay loads, so reproduce your expected concurrency and traffic profile before final sizing.'
+
+metadata:
+  description: 'See RustDesk first-party operational context for planning 200,000 devices and the workload variables a self-hosted Server Pro deployment must validate.'
+  keywords: 'rustdesk scale 200000 devices, rustdesk 50000 devices, rustdesk self-hosted server scalability, rustdesk enterprise deployment, rustdesk server pro capacity, remote desktop for large fleets'
+---
+
+RustDesk internal telemetry recorded **more than two million online endpoints** on one public-server host with a **12-core CPU and 32 GB of RAM** on July 7, 2026. This is a point-in-time internal production observation recorded on July 7, 2026, not a multi-day stability measurement.
+
+The scope matters: this is a production observation, not a reproducible Server Pro benchmark. It was not independently audited and has no public monitoring dashboard or downloadable dataset. “Online endpoints” means devices reported online at that point in time, not two million simultaneous remote-control sessions. RustDesk is intentionally publishing this limited topology summary without host identifiers or network details. A Server Pro deployment may also have different database writes, audit activity, console use, policy processing, and relay traffic.
+
+## The short answer
+
+Yes, 200,000 online devices is a credible planning target: RustDesk's point-in-time internal observation recorded more than ten times that number on one 12-core, 32 GB public-server host. Do not translate that ratio directly into a hardware guarantee. Size the deployment against online-device churn, simultaneous sessions, relay bandwidth, and Server Pro database and management workloads.
+
+## In detail
+
+Scale questions like this are among the most common we hear from IT teams migrating off TeamViewer or AnyDesk, especially those planning fleets in the tens or hundreds of thousands. The answer depends on how many devices stay online, how frequently their state changes, how many remote sessions run at once, and how much traffic uses the relay.
+
+The public-server observation provides a RustDesk-reported reference point: more than two million online endpoints on a single 12-core, 32 GB machine at the recorded moment. It is useful first-party operational context, but readers cannot independently reproduce it from a public report and should not treat it as proof of a monitoring period or service-level target.
+
+For a Server Pro rollout, validate the parts that do not follow from that public-server figure. Caching and database write performance matter as devices come and go. Relay bandwidth and CPU depend on the number, duration, resolution, and codec of simultaneous relayed sessions. Console queries, audit retention, device groups, policies, and integrations can add load that endpoint presence alone does not measure.
+
+Public and self-hosted environments are not identical. The public result is evidence that 200,000 online endpoints is within RustDesk's demonstrated operating scale; it is not evidence that every Server Pro workload will fit the same machine. Capture the intended online count, connection churn, simultaneous direct and relayed sessions, database retention, and administrative activity in a representative load test.
+
+High availability and load balancing fall into the same category. For very large fleets they are worth designing in, but the specifics — relay redundancy, database failover, and how sessions are distributed — should be validated with RustDesk against your workload rather than assumed as out-of-the-box defaults.
+
+For planning purposes, use the public server's more than two million online endpoints as first-party point-in-time context, then validate 200,000 devices against your Server Pro feature and session profile before procurement. Licensing at this scale uses per-user and per-device models, so confirm the exact tier for your fleet at [rustdesk.com/pricing](https://rustdesk.com/pricing).
+
+## Who asks this
+
+This question typically comes from enterprises, [MSPs](/blog/rustdesk-for-msps), and public-sector IT teams planning multi-year rollouts. These buyers are usually leaving a commercial tool for cost or data-sovereignty reasons and need confidence that a self-hosted platform will grow with them rather than hit a wall mid-contract.
+
+## Related questions
+
+- [How many concurrent sessions can a self-hosted RustDesk server handle?](/blog/rustdesk-concurrent-connections-limit)
+- What [server hardware](/blog/self-host-rustdesk-server-hardware-at-scale) do I need for a large RustDesk deployment?
+- Does RustDesk Server Pro support high availability or load balancing?
+- [How does RustDesk licensing work for tens of thousands of devices?](/blog/rustdesk-pro-license-cost-how-to-pay)
+- Can I migrate an existing TeamViewer or AnyDesk fleet to RustDesk?
+
+Planning a large-scale rollout? Reach out to the [RustDesk team](mailto:sales@rustdesk.com) to size a self-hosted deployment for your device count, performance requirements, and growth timeline.
@@ -0,0 +1,63 @@
+---
+publishDate: 2026-07-06T00:00:00Z
+lang: en
+translationKey: rustdesk-self-hosted-vs-cloud-saas-option
+draft: false
+title: 'Does RustDesk Host the Server? Self-Hosted vs Cloud'
+excerpt: "Does RustDesk offer a cloud or SaaS option? No. RustDesk Server Pro is self-hosted only — you deploy it on your own infrastructure. Here's what that means."
+image: ~/assets/images/blog/rustdesk-self-hosted-vs-cloud-saas-option-og.png
+category: Guides
+tags:
+  - RustDesk
+  - self-hosting
+  - deployment
+author: RustDesk Team
+faq:
+  - question: 'Does RustDesk offer a cloud or SaaS-hosted option?'
+    answer: 'No — RustDesk does not host the server for you. RustDesk Server Pro is a self-hosted solution only, with no SaaS or cloud-hosted option. You deploy and manage it on your own server infrastructure.'
+  - question: 'Can I run RustDesk Server Pro on a cloud VM like AWS, Azure, or a VPS?'
+    answer: 'Yes. Self-hosted means you run the server on infrastructure you control — an on-premises machine or a cloud VM such as a VPS, AWS, Azure, or GCP instance that you provision and administer. RustDesk supplies the software; hosting, uptime, and maintenance are your responsibility.'
+  - question: 'What is the difference between the free RustDesk OSS server and Server Pro?'
+    answer: 'Both are self-hosted. The free open-source server covers core connectivity you can run indefinitely. Server Pro adds a web console, user and device management, device groups, a shared address book, a custom branded client generator, and identity features such as LDAP/AD and OIDC SSO.'
+  - question: 'Does RustDesk offer a monthly Server Pro plan?'
+    answer: 'RustDesk Server Pro licenses are sold annually rather than month to month. Self-hosting and billing cadence are separate: you operate the server on infrastructure you control, while the commercial license is renewed yearly. Check the pricing page for current terms.'
+
+metadata:
+  description: "Does RustDesk offer a cloud or SaaS option? No. RustDesk Server Pro is self-hosted only — you deploy it on your own infrastructure. Here's what that means."
+  keywords: 'does RustDesk host the server, RustDesk self-hosted vs cloud, RustDesk monthly plan, RustDesk SaaS option'
+---
+
+No — RustDesk does not host the server for you. RustDesk Server Pro is a self-hosted product only, and there is currently no SaaS or cloud-hosted option. You run it on infrastructure you control.
+
+## The short answer
+
+RustDesk Server Pro is self-hosted. There is no managed cloud or SaaS tier where RustDesk operates the server on your behalf. If you buy Server Pro, you are responsible for deploying it on your own server — whether that's an on-premises machine or a cloud VM (like a VPS, AWS, Azure, or GCP instance) that you provision and administer yourself.
+
+## In detail
+
+The distinction matters because it's different from how most remote-desktop tools you may be leaving — TeamViewer, AnyDesk, and similar products — are sold. Those are typically SaaS: the vendor runs the relay and rendezvous infrastructure, and you connect to their cloud. RustDesk's Server Pro flips that model. You get the server software and a license, and you stand up the service yourself.
+
+In practice, "self-hosted" means you install the RustDesk server components (the rendezvous/ID server and relay server) on a host you own or rent, point your clients at it, and handle the usual operational duties: the operating system, networking and firewall rules, TLS certificates, backups, and updates. RustDesk provides the software; the hosting, uptime, and maintenance are on you.
+
+This has real trade-offs. On the plus side, self-hosting gives you control of the ID/rendezvous, relay, console, and stored deployment data. Direct sessions still flow between endpoints, so endpoint location and routing remain part of any compliance or privacy assessment. The cost is operational: you need someone comfortable provisioning a server and keeping it patched. If you were hoping to buy a login and have everything "just work" in someone else's cloud, that specific offering does not exist for Server Pro today.
+
+If a fully managed, RustDesk-hosted service is a hard requirement for you, it's worth checking [rustdesk.com](https://rustdesk.com) for the latest, since product offerings can change over time. As of this writing, the answer from the team is clear: self-hosted only.
+
+## Billing is annual, not monthly
+
+Server location and billing cadence are easy to conflate. Self-hosting describes **who operates the infrastructure**; it does not mean the commercial license is a one-time purchase. RustDesk Server Pro licenses are sold on a yearly basis, with no monthly Server Pro plan currently listed. Compare the current term, login-user allowance, and managed-device allowance together on the [pricing page](https://rustdesk.com/pricing).
+
+The free community server is different: it provides the core self-hosted ID and relay services and can be run indefinitely without a Server Pro subscription. Server Pro is the annual commercial option when you need the web console, centralized device administration, identity integration, access controls, or client generation.
+
+## Who asks this
+
+This question comes up constantly from IT admins, [MSPs](/blog/rustdesk-for-msps), and businesses evaluating RustDesk against TeamViewer or AnyDesk — often after trying a [free trial](/blog/rustdesk-server-pro-free-trial) and expecting a comparable cloud sign-up. Many phrase it as looking for "any cloud hosting option similar to the free trial," assuming the paid product is simply a hosted upgrade. It isn't: the free experience and the paid Server Pro are both built around infrastructure you run, not a vendor-operated cloud. Teams with the in-house ability to manage a server tend to see the self-hosted model as a feature rather than a limitation.
+
+## Related questions
+
+- [What do I need to deploy RustDesk Server Pro on my own server?](/blog/self-host-rustdesk-server-hardware-at-scale)
+- [How is RustDesk licensing structured — per user versus per device?](/blog/rustdesk-pro-license-cost-how-to-pay)
+- [Does self-hosting RustDesk keep my session data on my own infrastructure?](/blog/remote-desktop-data-sovereignty-gdpr)
+- [How much does Server Pro cost, and how do I buy it?](/blog/rustdesk-pro-license-cost-how-to-pay)
+
+Planning a migration from TeamViewer or AnyDesk? Spin up a server, point your clients at it, and you're in full control — see [rustdesk.com](https://rustdesk.com) for deployment guides and licensing details.
@@ -0,0 +1,56 @@
+---
+publishDate: 2026-07-06T00:00:00Z
+lang: en
+translationKey: rustdesk-server-pro-free-trial
+draft: false
+title: 'Does RustDesk Server Pro Have a Free Trial?'
+excerpt: 'RustDesk Server Pro does not publish a fixed free trial. Email sales@rustdesk.com to ask about current evaluation terms.'
+image: ~/assets/images/blog/rustdesk-server-pro-free-trial-og.png
+category: Pricing
+tags:
+  - RustDesk
+  - pricing
+author: RustDesk Team
+faq:
+  - question: 'Does RustDesk Server Pro have a free trial?'
+    answer: 'The public pricing page asks prospective buyers to contact RustDesk for current trial-license availability and terms. Do not assume a fixed duration, price, or feature set until sales confirms it in writing.'
+  - question: 'How can I evaluate RustDesk Server Pro?'
+    answer: 'Email sales@rustdesk.com to confirm the current evaluation path, duration, and included features in writing before you plan your proof of concept. Scope the pilot around the workflows you care about, such as custom branding, if you need to validate them.'
+  - question: 'Why are trial terms not listed in this article?'
+    answer: 'Evaluation availability, duration, price, and included features can change. This article avoids inventing a fixed policy and directs buyers to the current pricing page or written confirmation from RustDesk.'
+  - question: 'What happens to my server and connections when a test license expires?'
+    answer: 'This article does not specify what happens at expiry, and you should not assume connections keep working. Confirm the exact end-of-trial behavior for your server and active sessions with sales@rustdesk.com before you rely on a test license in production.'
+
+metadata:
+  description: 'RustDesk Server Pro does not publish a fixed free trial. Email sales@rustdesk.com to ask about current evaluation terms.'
+  keywords: 'RustDesk free trial, RustDesk Server Pro trial, RustDesk test license, evaluate RustDesk Server Pro, RustDesk trial license'
+---
+
+RustDesk does not publish a completely free, self-serve trial of Server Pro. Email [sales@rustdesk.com](mailto:sales@rustdesk.com) to ask about current evaluation terms instead.
+
+## The short answer
+
+Email [sales@rustdesk.com](mailto:sales@rustdesk.com) for current trial-license availability, duration, price, and included features. The public pricing page does not publish fixed trial terms.
+
+## In detail
+
+RustDesk Server Pro is a self-hosted platform, meaning you run the server on your own infrastructure. The public pricing page does not publish a fixed self-serve trial policy, and this article does not speculate about the reason.
+
+For genuine evaluators, the practical takeaway is simple: confirm the current evaluation path, duration, and included features in writing before you plan your proof of concept. Do not assume a fixed number of days, a specific price, or custom-client availability unless the current offer says so.
+
+If custom branding or a preconfigured client is part of what you need to validate — common for [MSPs](/blog/rustdesk-for-msps) and businesses rolling RustDesk out to end users — ask whether your evaluation can include those workflows. That way you test something representative of what you'd actually run in production.
+
+The practical takeaway: scope your proof of concept around the workflows you actually care about, then confirm the current evaluation terms before you start.
+
+## Who asks this
+
+This question comes overwhelmingly from IT admins, MSPs, and businesses evaluating remote-desktop tools — often teams migrating away from TeamViewer or AnyDesk who want to pilot a self-hosted alternative before signing off. The people asking generally want a low-risk way to prove the platform works in their environment before purchasing an annual license.
+
+## Related questions
+
+- [How much does RustDesk Server Pro cost, and how does per-user vs. per-device licensing work?](/blog/rustdesk-pro-license-cost-how-to-pay)
+- [What features are included in the Basic plan versus higher tiers?](/blog/rustdesk-custom-quote-minimum-users-invoice-fees)
+- [What is a custom client, and which licenses include it?](/blog/rustdesk-web-console-custom-client-generator-port-21114)
+- [Can I self-host RustDesk Server for free using the open-source version?](/blog/see-rustdesk-in-action)
+
+Ready to evaluate it? Email [sales@rustdesk.com](mailto:sales@rustdesk.com) and ask for the current evaluation terms that match your setup.
@@ -0,0 +1,55 @@
+---
+publishDate: 2026-07-06T00:00:00Z
+lang: en
+translationKey: rustdesk-server-pro-offline-air-gapped
+draft: false
+title: 'Can RustDesk Server Pro Run Offline or Air-Gapped?'
+excerpt: "No — self-hosted RustDesk Server Pro needs ongoing outbound access to rustdesk.com to validate its license, so a fully air-gapped deployment isn't supported."
+image: ~/assets/images/blog/rustdesk-server-pro-offline-air-gapped-og.png
+category: Deployment
+tags:
+  - RustDesk
+  - deployment
+  - self-hosting
+author: RustDesk Team
+faq:
+  - question: 'Can RustDesk Server Pro run offline or air-gapped?'
+    answer: 'No. The licensed Server Pro must keep an outbound connection to rustdesk.com to validate its license while it runs, so a fully air-gapped, never-phones-home deployment is not supported. You can still lock egress down tightly and route it through a proxy.'
+  - question: 'Does RustDesk Server Pro need a permanent internet connection?'
+    answer: 'It needs ongoing outbound access to rustdesk.com for license validation. Remote sessions themselves are brokered by your own self-hosted relay and ID (rendezvous) servers, but the Pro license will not stay valid without that outbound path.'
+  - question: 'Which outbound access does an isolated RustDesk Server Pro deployment need?'
+    answer: 'Allow outbound HTTPS from the server to rustdesk.com for license validation (and for custom-client provisioning if you use it). A proxy is supported, so the rest of the network can stay locked down. Confirm the exact domains and ports in the RustDesk docs.'
+  - question: 'Is there a fully air-gapped RustDesk licensing option?'
+    answer: 'The standard licensed product is not designed for a never-phones-home air gap. If you have hard air-gap requirements, confirm your exact scenario with RustDesk before committing.'
+metadata:
+  description: "Can self-hosted RustDesk Server Pro run air-gapped? No — the Pro license needs ongoing outbound access to rustdesk.com, so a full air gap isn't supported."
+  keywords: 'rustdesk server pro offline, rustdesk air-gapped, rustdesk self-hosted internet requirement, rustdesk server pro license check, rustdesk offline deployment, does rustdesk need internet'
+---
+
+No — a self-hosted RustDesk Server Pro deployment is not designed to run fully offline or air-gapped. The Pro license has to reach rustdesk.com over an outbound connection to stay valid — both when you activate it and on an ongoing basis while the server runs — so a truly never-phones-home network falls outside the supported model.
+
+## The short answer
+
+Server Pro needs an outbound path to rustdesk.com for license validation, and that requirement does not go away once the server is running. Your ID and relay services remain self-hosted; direct sessions flow between endpoints and relayed sessions use your relay. The license itself will not remain valid on a server that can never reach rustdesk.com. You can keep the network tightly restricted: a proxy is supported, so in practice you allow the required outbound HTTPS path and lock down the rest.
+
+## In detail
+
+Many teams evaluating a self-hosted remote-desktop tool assume "self-hosted" should mean "fully offline forever." With RustDesk Server Pro, remote sessions do not depend on a permanently live vendor cloud — but the **license** does require ongoing outbound connectivity. Activation is an online-only step, and validation continues while the server runs, so a server that is completely cut off from rustdesk.com is not a supported configuration for the licensed product.
+
+It is worth separating two things. The open-source RustDesk server you can self-host without a license is a different matter; the requirement here applies specifically to the **licensed Server Pro** feature set. If your objection is fundamentally about keeping session data on your own infrastructure, self-hosting already achieves that — the outbound requirement is about licensing, not about brokering every session.
+
+There is a second workflow to account for: **building a custom client**. If you generate a branded or pre-configured client from Server Pro, that provisioning step also expects outbound access. Confirm the current behavior for your version and plan.
+
+For a strictly air-gapped network, this is the deciding detail. A truly isolated server that can _never_ reach rustdesk.com falls outside the default model, so if you have hard air-gap requirements, confirm your exact scenario with RustDesk before committing. For the far more common "mostly isolated, tight egress" setup, the practical takeaway is to budget for one outbound HTTPS path to rustdesk.com — directly or via a proxy — and define the exact domains, ports, and approval workflow before you write the firewall policy. See the [RustDesk docs](https://rustdesk.com/docs), and note that the same license requirement is why you [cannot run Server Pro without any internet access even when installing without Docker](/blog/rustdesk-server-pro-without-docker).
+
+## Who asks this
+
+This question comes up repeatedly from IT admins, [MSPs](/blog/rustdesk-for-msps), and security teams standing up RustDesk in locked-down or regulated environments, often while migrating away from cloud-dependent tools like TeamViewer or AnyDesk. Their networks may sit behind strict egress firewalls, or they simply want to minimize external dependencies. Knowing that the license needs an ongoing outbound path — but only that — lets them write a precise firewall rule rather than either over-opening the network or wrongly assuming the product will run in a total vacuum.
+
+## Related questions
+
+- [Which domains and ports does RustDesk Server Pro need for outbound connectivity?](https://rustdesk.com/docs)
+- [Can I install RustDesk Server Pro without Docker on a plain VM?](/blog/rustdesk-server-pro-without-docker)
+- [How do I generate and distribute a custom-branded RustDesk client?](/blog/rustdesk-web-console-custom-client-generator-port-21114)
+
+Planning a locked-down or near-air-gapped rollout? Confirm the current connectivity and licensing specifics on rustdesk.com before you finalize your firewall policy.
@@ -0,0 +1,54 @@
+---
+publishDate: 2026-07-06T00:00:00Z
+lang: en
+translationKey: rustdesk-server-pro-without-docker
+draft: false
+title: 'Run RustDesk Server Pro Without Docker (VM & Offline)'
+excerpt: "No, Docker isn't required for RustDesk Server Pro. Install on a plain VM or bare metal, even offline — but the license must reach rustdesk.com to activate."
+image: ~/assets/images/blog/rustdesk-server-pro-without-docker-og.png
+category: Deployment
+tags:
+  - RustDesk
+  - deployment
+  - self-hosting
+author: RustDesk Team
+faq:
+  - question: 'Can I run RustDesk Server Pro without Docker?'
+    answer: 'No, you are not forced to use Docker. RustDesk Server Pro ships as plain binaries you can install directly on a VM or bare-metal server (for example a Debian box) using install.sh, and you can even install offline by downloading the release files first. The one hard requirement: the server must be able to reach https://rustdesk.com to activate its license — the license cannot be activated fully offline, though a proxy is supported.'
+
+metadata:
+  description: "No, Docker isn't required for RustDesk Server Pro. Install on a plain VM or bare metal, even offline — but the license must reach rustdesk.com to activate."
+  keywords: 'RustDesk Server Pro without Docker, install RustDesk Server Pro on a VM, RustDesk Server Pro offline install, RustDesk Server Pro bare metal, RustDesk license activation offline, RustDesk Server Pro Debian'
+---
+
+No, Docker is not mandatory. RustDesk Server Pro is distributed as standalone binaries that install straight onto a VM or bare-metal host, so spinning up a plain Debian VM and installing to it is a fully supported path. The only firm rule is licensing: the server must reach `https://rustdesk.com` to activate.
+
+## The short answer
+
+You can run RustDesk Server Pro without Docker. The `install.sh` script and the binary releases both work on a normal host — a VM, a bare-metal box, whatever you already run. Docker is one option, not a requirement.
+
+You can also install completely offline by grabbing the files from the rustdesk-server-pro releases beforehand. But license activation is a separate matter: it is not offline-capable. Your server needs network access to RustDesk's validation endpoint to activate and stay licensed. If your box sits behind a proxy, that is supported.
+
+## In detail
+
+There are two distinct questions hiding inside "do I need Docker," and it helps to separate them.
+
+The first is _how the software is installed_. Here you have full flexibility. `install.sh` pulls what it needs from the internet, but if you would rather not run the script against a live connection — or your server has no direct internet at all — you can download the binaries from the rustdesk-server-pro releases and place them on the server yourself. Nothing about the install ties you to a container runtime. A Debian VM, an Ubuntu LXC, or a dedicated physical server are all valid targets.
+
+The second is _license activation_, and this is where the offline story ends. Activation is an online-only step. Your server has to be able to reach `https://rustdesk.com` to validate the license — both at activation time and on an ongoing basis while running. An [air-gapped](/blog/rustdesk-server-pro-offline-air-gapped), never-phones-home deployment is not supported for the licensed product. The practical takeaway: if you are planning a locked-down or isolated network, you still need to allow outbound access to the license endpoint (directly or via a proxy, which is supported).
+
+So the honest summary for an IT admin is: install however you like, on whatever OS you like, with or without Docker — but budget for one outbound HTTPS path to `rustdesk.com`.
+
+## Who asks this
+
+This comes up constantly with IT admins and [MSPs](/blog/rustdesk-for-msps) standardizing on their own stack — teams that already manage VMs, hypervisors, or bare-metal hosts and do not want to add a container layer just to run one service. It is especially common among businesses migrating off TeamViewer or AnyDesk who want a self-hosted server on infrastructure they already control, and among security-conscious shops probing whether a fully offline deployment is possible before they commit.
+
+## Related questions
+
+- Can I install RustDesk Server Pro on Debian or Ubuntu without Docker?
+- Does RustDesk Server Pro work in an air-gapped network?
+- How do I activate a RustDesk Server Pro license behind a corporate proxy?
+- What outbound domains does RustDesk Server Pro need to reach?
+- Can I move my RustDesk Server Pro license to a different VM later?
+
+Planning your deployment? Provision the VM or host you prefer, keep an outbound path to `rustdesk.com` open for licensing, and you are set — [check current install steps at rustdesk.com](https://rustdesk.com) before you begin.
@@ -0,0 +1,96 @@
+---
+publishDate: 2026-07-07T00:00:00Z
+lang: en
+translationKey: rustdesk-unattended-access-setup
+draft: false
+title: 'RustDesk Unattended Access: Setup Guide'
+excerpt: 'Set up RustDesk unattended access the right way: a permanent password, run as a service so it starts on boot, and deploy at scale with a pre-configured client.'
+image: ~/assets/images/blog/rustdesk-unattended-access-setup-og.png
+category: Deployment
+tags:
+  - RustDesk
+  - deployment
+  - unattended-access
+author: RustDesk Team
+faq:
+  - question: 'How do I set up unattended access in RustDesk?'
+    answer: "Two things are required: set a permanent password under Settings, Security so you don't need someone to approve each connection, and install RustDesk as a system service so it runs before login and survives logout. With both in place you can reach the machine any time, including at the login screen, without a person present."
+  - question: 'Why does my RustDesk connection drop when the user logs out?'
+    answer: 'That happens when RustDesk is run as a portable executable instead of installed as a service. A portable session ends when the user logs out or a UAC prompt appears. Install RustDesk and enable the service (Start on boot) so it runs in the background independent of any logged-in user, which is what makes unattended access reliable.'
+  - question: 'Is unattended access with a permanent password safe?'
+    answer: 'It can be deployed safely when configured well. Use a long, unique permanent password, restrict who can connect, enable available identity and access controls, patch clients, and review logs. Self-hosting controls server-side services and stored deployment data; the endpoint still protects its local credentials.'
+  - question: 'Can I deploy RustDesk unattended access to many computers at once?'
+    answer: "Yes. On Basic and higher self-hosted plans, the Custom Client Generator produces a pre-configured installer with your server address, key, and settings baked in, so end users don't type anything. Push it with your existing deployment tooling and each device installs the service and registers against your server automatically."
+  - question: 'Does unattended access work at the Windows login screen?'
+    answer: 'Yes, once RustDesk is installed as a service with Start on boot enabled. Because the service runs before any user logs in, you can connect to the login screen, authenticate, and even trigger a reboot and reconnect. Running the portable executable cannot do this because it only exists inside a user session.'
+
+metadata:
+  description: 'Set up RustDesk unattended access: permanent password, run as a service for start on boot, per-platform notes for Windows/macOS/Linux, and fleet deployment.'
+  keywords: 'RustDesk unattended access, RustDesk permanent password, RustDesk start on boot, RustDesk service install, RustDesk unattended setup, RustDesk deploy at scale, unattended remote access'
+---
+
+Unattended access means reaching a computer when no one is sitting in front of it — a server in a rack, a kiosk, a family member's PC across the country. RustDesk does this well, but only if you configure two things correctly: a **permanent password** so no one has to approve each connection, and RustDesk running **as a service** so it's available before login and after logout. This guide covers both, plus how to roll it out across a fleet.
+
+## The short answer
+
+Set a **permanent password** (Settings → Security) and **install RustDesk as a system service** with _Start on boot_ enabled. The password removes the need for a human to accept the prompt; the service makes RustDesk run independently of any logged-in user, so you can connect at any time — including at the login screen. To deploy at scale, generate a pre-configured client so every machine installs itself against your server automatically.
+
+## Step 1: Set a permanent password
+
+By default, RustDesk shows a rotating one-time password that a person on the remote end would read to you. For unattended access you replace that with a fixed credential:
+
+1. Open RustDesk on the machine you want to reach.
+2. Go to **Settings → Security** (older builds: the password area on the main screen).
+3. Choose **Set permanent password** and enter a strong, unique value.
+
+The [RustDesk client documentation](https://rustdesk.com/docs/en/client/) describes this as the core of unattended access. One rule worth emphasizing: **do not reuse the operating-system login password.** Use a dedicated, high-entropy password for RustDesk so a leak of one credential doesn't compromise the other.
+
+## Step 2: Install as a service and start on boot
+
+This is the step people miss. If you just run the portable `.exe` or `.app`, the session **ends the moment the user logs out or a UAC/permission prompt appears** — because that process only exists inside the user's session. To be truly unattended, RustDesk must run as a background **system service**.
+
+- Run the RustDesk **installer** (not the portable build) and complete installation.
+- In **Settings → General**, make sure the **Service** toggle is **on** and **Start on boot** is enabled.
+
+Once RustDesk runs as a service, it loads before anyone logs in, which is what lets you connect to the **login screen**, authenticate remotely, and even reboot and reconnect without a person present. Community write-ups on [proper Windows service setup](https://www.smolkin.org/blog/2026/03/rustdesk-unattended-service-windows.html) stress the same distinction: portable equals attended-only; installed service equals unattended.
+
+## Per-platform notes
+
+| Platform | What to do                                         | Watch out for                                                                                       |
+| -------- | -------------------------------------------------- | --------------------------------------------------------------------------------------------------- |
+| Windows  | Install, enable Service + Start on boot            | Portable exe drops on logout/UAC; use the installer                                                 |
+| macOS    | Install, set permanent password, grant permissions | Screen Recording and Accessibility must be granted; login-screen capture needs the helper installed |
+| Linux    | Install the service package; prefer X11/Xorg       | Wayland capture is experimental and needs an active session                                         |
+| Android  | Set permanent password; enable capture             | Screen must be awake; enable Developer-options screen-share settings                                |
+
+### Windows
+
+The cleanest path. Install, toggle the service on, set the permanent password, done. Because the service runs at boot, unattended access to the login screen and through reboots works as expected.
+
+### macOS
+
+macOS gates screen capture and input behind permissions. After installing, open **System Settings → Privacy & Security** and grant RustDesk both **Screen Recording** and **Accessibility**. For access at the _login window_ (before any user logs in), the RustDesk service/helper must be installed so it can capture pre-login — otherwise you'll get a black screen there, the same [capture issue covered in our black-screen guide](/blog/rustdesk-connected-waiting-for-image).
+
+### Linux
+
+Install RustDesk so its service component runs at boot. For unattended reliability, prefer an **X11/Xorg** session: Wayland capture is experimental, prompts for consent on each connect, and only works inside an active session — awkward for a machine that may sit at the greeter. See [RustDesk for Linux](/blog/rustdesk-for-linux) for the details.
+
+## Step 3: Deploy at scale with a pre-configured client
+
+Configuring one machine by hand is fine. Configuring fifty isn't. On **Basic and higher self-hosted plans**, the **Custom Client Generator** in the web console builds an installer with your **server address, public key, and settings pre-baked**, so end users type nothing. Combined with your existing deployment tool (Group Policy, Intune, an MSP RMM, a shell script), each device installs the service and registers against _your_ server on first run.
+
+This is where self-hosting pays off for teams: you get an [unattended fleet you fully control](/blog/rustdesk-for-msps), with no per-seat cloud metering deciding how many endpoints you're "allowed" to reach. Set up the generator via the [web console on port 21114](/blog/rustdesk-web-console-custom-client-generator-port-21114). Note that RustDesk is licensed per **login-user and managed-device**, not per concurrent session, so budget by how many machines and admins you have — see [what counts as a managed device](/blog/what-counts-as-a-managed-device).
+
+## Lock it down
+
+Unattended access is a standing door into a machine, so treat the credentials seriously:
+
+- **Strong, unique permanent password**, rotated periodically.
+- **Two-factor authentication** and, on Pro, **access controls** so only authorized accounts can connect. Our write-up on [per-user access control and device groups](/blog/rustdesk-per-user-access-control-device-groups-shared-address-book) covers scoping who reaches what.
+- **Self-host the server-side services** when you need control of rendezvous, relay, console, and stored deployment data. Endpoint credentials remain an endpoint-security responsibility. Because the [client is open source under AGPL](/blog/open-source-remote-desktop-software), its authentication implementation can be reviewed.
+
+## An honest caveat
+
+Unattended access trades convenience for exposure: a machine that answers any time is a machine an attacker would love to answer to. That's a reason to insist on a strong, unique password and 2FA, not the OS login, and to prefer a **server you control** over the shared public one. Self-hosting also means the service's uptime is now yours to maintain — but in exchange, no third party can silently change the rules on who reaches your fleet. For most admins that ownership is the whole point.
+
+Getting started costs nothing: run the **free community server**, set a permanent password, install the service, and you have unattended access on infrastructure you own. For the Custom Client Generator, access controls, and other commercial features, see [rustdesk.com/pricing](https://rustdesk.com/pricing) or email sales@rustdesk.com — and if you'd like to see the workflow first, browse [RustDesk in action](/blog/see-rustdesk-in-action).
@@ -0,0 +1,76 @@
+---
+publishDate: 2026-07-06T00:00:00Z
+lang: en
+translationKey: rustdesk-unknown-devices-antivirus-scanning
+draft: false
+title: 'Unknown Devices in Your RustDesk Console? Investigate First'
+excerpt: 'Seeing unfamiliar devices in your RustDesk console? AV sandboxing is one possibility; leaked config or unauthorized registration must be ruled out first.'
+image: ~/assets/images/blog/rustdesk-unknown-devices-antivirus-scanning-og.png
+category: Deployment
+tags:
+  - RustDesk
+  - deployment
+  - security
+author: RustDesk Team
+faq:
+  - question: 'Why do unknown devices appear in my RustDesk console that I never installed?'
+    answer: 'Antivirus or endpoint-protection sandboxing can create temporary registrations, but an unknown device can also indicate leaked configuration, an exposed deployment token, unauthorized registration, or a deployment mistake. Treat it as a security event until logs, credentials, keys, tokens, and rollout records identify the cause; then restrict new-device enrollment.'
+  - question: 'How do I stop unknown devices from registering entirely?'
+    answer: 'If your device list is stable and you are not regularly adding machines, disable new-device registration in the console under Settings → Others → Disable new devices on web console. Nothing new can register after that, sandboxed or otherwise. If you still onboard devices regularly, use a deployment token instead so real rollouts keep working.'
+  - question: 'How do I require a deployment token for new devices?'
+    answer: 'Enable Require deployment for new devices in the console, generate a deploy token, and have your install process run the deploy command. The RustDesk client supports a deploy/token flag, but verify the exact flag in the current Server Pro docs, as syntax changes between releases. Only devices that present a valid token get added, so a sandboxed AV scan cannot register while your RMM or scripted rollout continues normally.'
+  - question: 'How do I tell a benign AV scan from a real intrusion?'
+    answer: 'A short-lived registration that lines up with a known security scan and shows no subsequent session may support the sandbox explanation. Unexpected sessions, repeated enrollment, use of valid credentials, or a configured client distributed outside its intended channel is not benign and warrants incident response.'
+
+metadata:
+  description: 'Unknown devices in your RustDesk console require investigation. Learn how to distinguish AV sandboxing from leaked configuration or unauthorized registration.'
+  keywords: 'rustdesk unknown device, rustdesk phantom device, rustdesk random device registration, rustdesk antivirus sandbox, disable new devices rustdesk, rustdesk --deploy'
+---
+
+An unfamiliar device in the RustDesk console is not enough to identify its cause. Antivirus sandboxing is a known possibility, but the same symptom can result from leaked configuration, unauthorized enrollment, an exposed token, or a deployment mistake.
+
+## The short answer
+
+Some AV/EDR products execute unfamiliar binaries in cloud sandboxes. If a sandbox receives a client build containing your server configuration and can reach the ID server, it may register briefly. However, a cloud-provider IP address or unusual hardware name does **not** prove this explanation; attackers also use cloud hosts. Preserve and review evidence before dismissing the event.
+
+## In detail
+
+### Why this happens
+
+RustDesk clients can register with the configured ID/rendezvous server when they run and can reach it. This makes sandbox execution a plausible cause, as discussed in a public [GitHub thread](https://github.com/rustdesk/rustdesk-server-pro/discussions/307), but it also means anyone who obtains a configured client or valid deployment material may produce a similar registration.
+
+Before classifying the event, review the server's registration and connection logs, the device's first-seen time and source IP, deployment records, and the distribution path for custom clients. Rotate exposed passwords, API/deployment tokens, and server configuration or keys as appropriate. Check whether the same credentials were reused elsewhere and whether the unknown device attempted or completed any session.
+
+### How to stop it
+
+Two console settings solve this, and which one fits depends on whether you're still actively onboarding real new devices.
+
+**Option 1 — disable new-device registration entirely.** If your device list is basically stable and you're not regularly adding machines, this is the simplest fix: go to **Settings → Others → Disable new devices on web console**. Nothing new can register at all, sandboxed or otherwise.
+
+**Option 2 — require a deployment token.** If you're still rolling out new devices regularly (an MSP onboarding clients, an IT team imaging new machines), a blanket "disable new devices" setting gets in your own way. Instead, enable **"Require deployment for new devices"**, generate a deploy token from the console, and have your install process run a deploy command such as:
+
+```
+rustdesk --deploy --token <api_token>
+```
+
+The exact flag can change between releases, so treat this as illustrative and verify the current syntax in the RustDesk Server Pro docs before scripting it. Only a device that presents a valid token gets added to your inventory. A sandboxed AV scan — which has no way to know or supply that token — fails to register, while your real rollout continues to work normally. This is also the mechanism MSPs use to enroll devices via RMM or a scripted install without a technician manually logging in on each machine.
+
+**A related, narrower control:** if you'd rather leave registration open but simply keep unassigned devices out of view until you've reviewed them, there's also **Settings → Others → Only admin can access unassigned devices** — this doesn't stop registration, but it does mean regular users won't see or be able to touch anything that shows up before you've had a chance to look at it.
+
+### How to assess the result
+
+Registration alone does not prove that an attacker controlled another endpoint, but it is still unauthorized activity until explained. A short-lived registration that aligns with a known security scan and shows no subsequent access may support the sandbox hypothesis. Unexpected sessions, repeated enrollment, use of valid credentials, or distribution of a configured client outside its intended channel requires incident response.
+
+## Who asks this
+
+This comes up most from IT admins and MSPs shortly after standing up a new self-hosted server, before registration controls have been tightened. Early investigation matters because benign scanning and unauthorized enrollment can look similar in the console.
+
+## Related questions
+
+- [How do I generate a custom-branded RustDesk client?](/blog/rustdesk-web-console-custom-client-generator-port-21114)
+- [What counts as a managed device in RustDesk?](/blog/what-counts-as-a-managed-device)
+- [Review current RustDesk releases and security fixes](https://github.com/rustdesk/rustdesk/releases)
+- [RustDesk for MSPs: one self-hosted, brandable tool](/blog/rustdesk-for-msps)
+- [How do I self-host RustDesk Server Pro at scale?](/blog/self-host-rustdesk-server-hardware-at-scale)
+
+Seeing a device you do not recognize? Preserve the relevant logs, restrict new enrollment, rotate any potentially exposed secrets, and contact RustDesk support with non-sensitive diagnostic details if the cause remains unclear.
@@ -0,0 +1,195 @@
+---
+publishDate: 2026-07-06T00:00:00Z
+lang: en
+translationKey: rustdesk-vs-anydesk
+draft: false
+title: 'RustDesk vs AnyDesk: Self-Hosted, Open-Source Remote Desktop'
+excerpt: 'A full comparison of RustDesk vs AnyDesk: features, OS support, security, pricing models, and the trade-offs of self-hosting and open source.'
+image: ~/assets/images/blog/rustdesk-vs-anydesk-og.png
+category: Comparisons
+tags:
+  - RustDesk
+  - AnyDesk
+  - comparison
+author: RustDesk Team
+metadata:
+  description: "RustDesk vs AnyDesk compared in depth: features, OS support, security (including AnyDesk's 2024 security incident), pricing models, and honest pros/cons."
+  keywords: 'RustDesk vs AnyDesk, AnyDesk vs RustDesk, RustDesk AnyDesk comparison, self-hosted AnyDesk comparison'
+---
+
+Buyers commonly compare RustDesk with AnyDesk after reviewing renewal cost, hosting control, and security requirements. This article does not reproduce private sales or support correspondence; product claims should be checked against current vendor documentation and dated public reporting.
+
+## Table of contents
+
+- [Overview](#overview)
+- [Feature comparison at a glance](#feature-comparison-at-a-glance)
+- [OS and platform support](#os-and-platform-support)
+- [Security and identity](#security-and-identity)
+- [Licensing and pricing models](#licensing-and-pricing-models)
+- [Where AnyDesk still wins](#where-anydesk-still-wins)
+- [Pros and cons](#pros-and-cons)
+- [Why teams switch to RustDesk anyway](#why-teams-switch-to-rustdesk-anyway)
+- [An honest caveat](#an-honest-caveat)
+- [Try RustDesk](#try-rustdesk)
+- [Related reading](#related-reading)
+- [Sources](#sources)
+
+## Overview
+
+**AnyDesk** is a proprietary, commercial remote-desktop product from AnyDesk Software GmbH (legally registered as philandro Software GmbH), founded in 2014 in Stuttgart, Germany. It built its reputation on a lightweight client and a low-latency proprietary codec (DeskRT), and today it is a mature, widely deployed tool used by individual technicians, help desks, and enterprises. AnyDesk is closed source: you connect through AnyDesk's cloud infrastructure by default, and the higher tiers add an on-premises appliance option. It is a polished, managed experience — you rent access to the network AnyDesk runs.
+
+**RustDesk** is an open-source remote-desktop platform whose core client is licensed under the AGPL. The defining difference is where it runs: with RustDesk Server Pro, the ID/rendezvous server and the relay server run on _your_ machine or VPS, so session brokering and traffic stay on infrastructure you control. Because the client is open source, it can be audited, built from source, and pointed at a free community server that runs indefinitely at no cost. RustDesk Pro adds a self-hosted web console, a custom-branded client generator, device groups, and a shared address book on top. It is aimed at teams that want ownership and data sovereignty and are comfortable running a server — which, as we'll get to, is both its biggest strength and the thing you have to be honest with yourself about.
+
+The rest of this article compares them feature by feature, then covers the parts of the decision that don't fit in a table.
+
+## Feature comparison at a glance
+
+Both tools cover the core remote-support workflow. The differences are less about "does it have feature X" and more about _how_ you get it — hosted vs self-hosted, per-seat vs per-user-and-device, gated behind a tier vs available in the open client.
+
+| Capability                | RustDesk                                              | AnyDesk                                            |
+| ------------------------- | ----------------------------------------------------- | -------------------------------------------------- |
+| Remote view and control   | Yes                                                   | Yes                                                |
+| Unattended access         | Yes (permanent password / managed devices)            | Yes                                                |
+| File transfer             | Yes (both directions)                                 | Yes (file-browser mode)                            |
+| In-session text chat      | Yes                                                   | Yes                                                |
+| Session recording         | Yes (can auto-record incoming/outgoing)               | Yes (stored locally; both ends)                    |
+| Remote printing           | Yes (remote printer for incoming connections)         | Yes (AnyDesk printer)                              |
+| Mobile clients            | Android and iOS                                       | Android; iOS/iPadOS outgoing-only                  |
+| Self-hosted server        | Yes — core to the product (Server Pro)                | Appliance available on the top tier only           |
+| Open source client        | Yes (AGPL)                                            | No (proprietary)                                   |
+| Custom-branded client     | Yes (built-in generator)                              | Yes (customization / custom namespace on top tier) |
+| REST API                  | Yes                                                   | Yes (my.anydesk console)                           |
+| Concurrent connection cap | Unlimited on standard plans; limited on Customized V2 | Tied to plan tier (see pricing)                    |
+
+The RustDesk feature rows above are confirmed against RustDesk's own documentation; the AnyDesk rows are from AnyDesk's support docs and feature pages. Two rows deserve a callout: **self-hosting** and the **plan-specific concurrency model**. RustDesk's Customized V2 must not be described as unlimited.
+
+## OS and platform support
+
+Both products are genuinely cross-platform on the desktop. The meaningful gaps are on mobile and on the less-common desktop targets.
+
+| Platform        | RustDesk                       | AnyDesk                                                                 |
+| --------------- | ------------------------------ | ----------------------------------------------------------------------- |
+| Windows         | Yes                            | Yes (XP SP2 and later)                                                  |
+| macOS           | Yes                            | Yes (11 Big Sur and later)                                              |
+| Linux           | Yes                            | Yes (Ubuntu/Debian/RHEL/SUSE/Mint)                                      |
+| Android         | Yes                            | Yes (control plugin required)                                           |
+| iOS / iPadOS    | Yes                            | Outgoing connections only (control unavailable, per Apple restrictions) |
+| Raspberry Pi    | Community/ARM builds           | Yes (Raspberry Pi OS 12+)                                               |
+| Chrome OS       | — (Android app via Play Store) | View-only (control not supported)                                       |
+| tvOS / Apple TV | Not verified, omitted          | Outgoing only (limited file transfer/recording)                         |
+
+RustDesk officially lists Windows, macOS, Linux, Android, and iOS. AnyDesk's supported-OS documentation covers a slightly wider spread of niche targets (Raspberry Pi OS, Chrome OS viewing, tvOS), but with the same Apple-imposed limitation everyone hits: on iOS/iPadOS you can control _out_ to another machine, but you can't be fully controlled _from_ one. If your fleet includes Raspberry Pi appliances or you specifically need a Chrome OS or Apple TV client, verify the current state on each vendor's page before deciding — those targets change.
+
+## Security and identity
+
+This is the section where the two products diverge philosophically, not just on a checkbox.
+
+**AnyDesk's security model.** AnyDesk secures sessions with TLS 1.2 (AEAD), an RSA-2048 asymmetric key exchange, 256-bit AES transport encryption, and Perfect Forward Secrecy via an ephemeral Diffie-Hellman handshake. It offers two-factor authentication (TOTP) for unattended access, an access-control list / allowlist to restrict who can connect, and salted-hash password storage. These are solid, industry-standard protections. The catch is that you are trusting a closed-source vendor and, by default, that vendor's cloud to broker your connections — you cannot audit the code, and you rely on AnyDesk's own operational security.
+
+That last point stopped being abstract in 2024, when AnyDesk publicly disclosed a security incident affecting its production systems. By its own account, the response included rotating its code-signing certificate, pushing a re-signed client build, and resetting web-portal passwords as a precaution; exact dates and scope were reported variously at the time, so confirm the specifics against AnyDesk's own advisories. The episode illustrates vendor-concentration risk when a third party operates remote-access infrastructure.
+
+**RustDesk's security model.** The client is open source under the AGPL, and Server Pro lets you operate the rendezvous, relay, and console. This removes a vendor-operated service from those roles, but it does not eliminate endpoint, credential, configuration, or software-vulnerability risk. Review the [latest RustDesk releases](https://github.com/rustdesk/rustdesk/releases) and public vulnerability records as part of deployment hardening.
+
+**Identity and directory integration.** For teams that live in Active Directory or an OIDC identity provider, LDAP and SSO matter. RustDesk offers **LDAP and SSO (OIDC) from the Basic plan and up**. AnyDesk's [official pricing page](https://anydesk.com/en/pricing), checked July 7, 2026, lists SSO on Ultimate; confirm directory requirements in a written quote. If single sign-on is mandatory, note which tier each vendor requires rather than treating identity as a generic checkbox. RustDesk's [LDAP and Active Directory setup guide](/blog/rustdesk-active-directory-ldap-sso) walks through its configuration.
+
+For teams whose whole reason for looking is keeping session data inside their own borders, [remote desktop and data sovereignty under GDPR](/blog/remote-desktop-data-sovereignty-gdpr) and [the case for open-source remote access](/blog/case-for-open-source-remote-access) go deeper than we can here.
+
+## Licensing and pricing models
+
+Prices change constantly, so this section compares _models_, not exact dollar amounts. The plan limits below come from [AnyDesk's official pricing page](https://anydesk.com/en/pricing), checked July 7, 2026; do not treat them as permanent.
+
+**AnyDesk** licenses on a plan-tier model and states that all listed plans are billed annually:
+
+- **Solo** — one licensed user, one non-scalable concurrent connection, three registered outgoing devices, and 100 managed devices.
+- **Standard** — up to 20 users, one included concurrent connection, connection add-ons up to 20, and 500 managed devices.
+- **Advanced** — up to 100 users, two included concurrent connections, connection add-ons up to 50, and 1,000 managed devices.
+- **Ultimate** — custom-quoted cloud or on-premises hosting, starting at five licensed users and 2,000 managed devices, with user and concurrency capacity defined in the quote.
+
+The two things to internalize about this model are annual billing and plan-specific concurrent-connection capacity. Scaling simultaneous connections can require add-ons or a different tier. Verify the current page and a dated written quote before budgeting because public packaging can change after this article's check date.
+
+**RustDesk** licenses by **login users plus managed devices**, with prorated upgrades. Standard plans include unlimited concurrent connections, while Customized V2 limits and prices them separately. Self-hosting is not guaranteed to be cheaper in every configuration; compare current quotes for the same user, device, feature, and concurrency requirements. See [RustDesk Pro pricing](/blog/rustdesk-pro-license-cost-how-to-pay) and [the concurrency FAQ](/blog/rustdesk-concurrent-connections-limit).
+
+Because RustDesk pricing itself shifts, this article deliberately doesn't quote a RustDesk dollar figure — the current numbers live at [rustdesk.com/pricing](https://rustdesk.com/pricing).
+
+## Where AnyDesk still wins
+
+A comparison that only lists the other product's weaknesses isn't worth reading, so here is the honest other side.
+
+- **Maturity and polish.** AnyDesk has been shipping since 2014 with a full-time company behind it. The client is refined, the connection experience is consistent, and edge cases that a decade of scale surfaces have largely been handled. That track record has real value.
+- **Zero-infrastructure setup for non-technical users.** With AnyDesk you install a client and you're connected — there's no server to stand up, secure, or patch. Third-party reviewers consistently position AnyDesk (and tools like it) as the simpler choice for non-technical users, while framing RustDesk as better suited to technical teams and self-hosters. That perception gap is real, and if the person setting this up doesn't want to touch a VPS, it matters.
+- **Managed cloud as a feature, not a bug.** For a small shop with no interest in running infrastructure, "someone else operates it" is a legitimate benefit. Self-hosting is not free — it costs attention.
+- **Breadth of niche platform targets.** AnyDesk's documented support for Raspberry Pi OS, Chrome OS viewing, and tvOS is broader on paper than RustDesk's official five-platform list, which can matter for unusual fleets.
+- **Established RMM/ITSM integration ecosystem.** AnyDesk has existing partnerships and documented integrations with RMM and help-desk tools, plus a REST API on the management console.
+
+If your priority is "install it and forget it" and you're happy renting access to a vendor-run network, AnyDesk is a perfectly reasonable choice, and you don't need the rest of this article.
+
+## Pros and cons
+
+**RustDesk**
+
+_Pros:_
+
+- Open-source client (AGPL) — auditable, buildable, no black box
+- Self-hosted server keeps session brokering and traffic on your own infrastructure
+- Unlimited concurrent connections on standard plans; Customized V2 is limited
+- Per-user + per-device licensing with prorated upgrades
+- LDAP/SSO from the Basic plan and up (not top-tier-only)
+- Custom-branded client generator, self-hosted web console, device groups, shared address book
+- Free community server runs indefinitely
+
+_Cons:_
+
+- You run, patch, and secure the server yourself — it is not managed SaaS
+- Smaller/younger ecosystem than AnyDesk; more technical audience
+- No fully free trial of Server Pro (email sales@rustdesk.com for a test license)
+- Fewer niche platform targets on the official list
+
+**AnyDesk**
+
+_Pros:_
+
+- Mature, polished, low-latency client with a long track record
+- Near-zero setup for non-technical users; nothing to self-host on lower tiers
+- Broad niche-platform coverage (Raspberry Pi, Chrome OS viewing, tvOS)
+- Established RMM/ITSM integrations and a REST API
+- Standard, well-documented encryption and 2FA
+
+_Cons:_
+
+- Closed source — you cannot audit the client
+- Default reliance on AnyDesk's cloud; on-premises appliance only on the top tier
+- Suffered a production-system compromise in 2024 (certificate revoked, passwords reset)
+- Concurrent sessions bounded by plan tier; annual up-front billing
+- SSO listed on Ultimate as of the July 7, 2026 pricing-page check
+
+## Why teams switch to RustDesk anyway
+
+Everything above is the neutral comparison. This section is the part where RustDesk's case is made plainly — read it as such.
+
+The teams that move to RustDesk after evaluating AnyDesk tend to cite the same handful of reasons: **self-hosting, customization, and a focus on security and privacy.**
+
+**Data sovereignty is the headline.** When the rendezvous and relay servers are yours, session metadata and relayed traffic don't have to leave your control, and there's no third-party portal holding a master credential list to be breached. For regulated environments and anyone doing business under GDPR, that's not a nice-to-have — it's frequently the whole requirement. See [why self-host your remote desktop software](/blog/why-self-host-remote-desktop-software) and [self-hosted vs cloud](/blog/rustdesk-self-hosted-vs-cloud-saas-option) for the full argument.
+
+**Open source is auditable trust.** You don't have to _believe_ the vendor about what the client does — you can read it, build it, and verify it. After a year like 2024 in the remote-access category, "we can inspect the code ourselves" resonates.
+
+**The concurrency model changes the math at scale.** Standard RustDesk plans include unlimited concurrent connections; Customized V2 has a defined allowance and prices additional concurrency. All plans must also fit login-user and managed-device limits. RustDesk publishes [large-fleet planning guidance](/blog/rustdesk-scale-50000-200000-devices), but capacity still needs validation against the actual rollout.
+
+**It's built for the people who'd be doing the switching.** MSPs get one self-hosted, brandable tool ([RustDesk for MSPs](/blog/rustdesk-for-msps)); enterprises get a self-hosted, AD-ready platform ([RustDesk for Enterprise](/blog/rustdesk-for-enterprise)). If you arrived here specifically because AnyDesk's pricing changed, [AnyDesk price increase: alternatives for teams](/blog/anydesk-price-increase-alternatives) and [the best AnyDesk alternative in 2026](/blog/anydesk-alternative-self-hosted) are written for exactly that moment.
+
+## An honest caveat
+
+Self-hosting is a trade, not a free win, and pretending otherwise would be doing you a disservice. When you run RustDesk Server Pro, **you** run, patch, and secure that server. There's no vendor NOC watching it for you, no managed uptime SLA unless you build one, and the responsibility for hardening it is yours. That's the price of the sovereignty and the uncapped concurrency — real ownership comes with real operational work.
+
+If your team has no one who wants to own a VPS and keep it patched, be honest about that up front; a managed product may genuinely serve you better, and that's a legitimate outcome. RustDesk is the right answer when control, cost-at-scale, and auditability outweigh the convenience of letting someone else operate the infrastructure. It is not a zero-maintenance managed SaaS, and we'd rather you know that before you commit than after.
+
+## Try RustDesk
+
+Self-host the free community server today. Want to try the Pro features? Email [sales@rustdesk.com](mailto:sales@rustdesk.com) to ask about current evaluation terms, or check [rustdesk.com/pricing](https://rustdesk.com/pricing) for standard plan rates. Prefer to watch first? There's a full video walkthrough on the [RustDesk YouTube channel](https://www.youtube.com/@rustdesk) — no booking required.
+
+If you'd like to see it running before you touch a server, [see RustDesk in action](/blog/see-rustdesk-in-action) walks through a demo, the free server, and the Pro trial.
+
+## Sources
+
+- [AnyDesk pricing](https://anydesk.com/en/pricing) — official plan limits, annual billing, concurrent connections, managed devices, and cloud/on-premises availability; checked July 7, 2026.
+- [AnyDesk client settings](https://support.anydesk.com/docs/settings) — direct connections, public-network relay fallback, unattended access, and access controls.
+- [AnyDesk public statement](https://anydesk.com/en/public-statement) — vendor disclosure of the 2024 production-system incident and response.
@@ -0,0 +1,77 @@
+---
+publishDate: 2026-07-06T00:00:00Z
+lang: en
+translationKey: rustdesk-vs-logmein
+draft: false
+title: 'RustDesk vs LogMeIn: The Self-Hosted Alternative'
+excerpt: "Replacing LogMeIn Central or Pro? Here's how RustDesk compares on cost, self-hosting, and data control — plus an honest look at the trade-offs."
+image: ~/assets/images/blog/rustdesk-vs-logmein-og.png
+category: Comparisons
+tags:
+  - RustDesk
+  - LogMeIn
+  - comparison
+metadata:
+  description: 'RustDesk vs LogMeIn compared: self-hosted control, open source, per-user/per-device pricing, and plan-dependent concurrency.'
+  keywords: 'RustDesk vs LogMeIn, LogMeIn Central alternative, LogMeIn Pro alternative, self-hosted LogMeIn alternative'
+author: RustDesk Team
+---
+
+Teams comparing LogMeIn and RustDesk usually focus on total cost and whether the service is vendor-hosted or self-hosted. This article does not reproduce private sales emails.
+
+If you're comparing RustDesk and LogMeIn, here's an honest look at how they differ.
+
+## The short version
+
+|                                                                           | LogMeIn               | RustDesk                                              |
+| ------------------------------------------------------------------------- | --------------------- | ----------------------------------------------------- |
+| **Hosting**                                                               | Vendor cloud (SaaS)   | Self-hosted on your own server                        |
+| **Server-side services and data**                                         | Vendor-operated       | Operated on infrastructure you control                |
+| **Source code**                                                           | Closed                | Open source                                           |
+| **Licensing model**                                                       | Per-seat subscription | Per login-user **+** per managed-device               |
+| **[Concurrent connections](/blog/rustdesk-concurrent-connections-limit)** | Plan-dependent        | Unlimited on standard plans; limited on Customized V2 |
+| **How you evaluate**                                                      | Vendor trial          | Self-host free, or email for a Pro trial              |
+
+## Why teams start looking
+
+Cost comparisons should use current written quotes for the same technician, device, concurrency, and feature requirements. Do not infer current pricing from another organization's private deployment details.
+
+The second trigger is control. LogMeIn is a pure cloud product — your sessions and device list live on LogMeIn's servers, on LogMeIn's terms. Some of the teams evaluating RustDesk specifically wanted a self-hosted option instead, so the server (and their data) sits on infrastructure they manage.
+
+## Central, Pro, and Rescue are different replacement jobs
+
+“LogMeIn” can mean several workflows. Define which one you are replacing before treating the table above as a buying decision:
+
+- **LogMeIn Pro-style access:** prioritize reliable unattended access to a known set of computers, multi-monitor behavior, file transfer, remote printing, mobile access, and ease of use.
+- **Central-style fleet administration:** add device inventory, groups, user authorization, policy rollout, deployment, updates, audit data, and integrations to the test plan.
+- **Rescue-style support:** prioritize attended session initiation, user consent, technician elevation, session handoff, chat, mobile support, and service-desk workflow.
+
+RustDesk covers attended and unattended remote access and adds self-hosted Pro administration, but a feature with a similar label may not reproduce a LogMeIn-specific workflow or integration. Test each required journey end to end.
+
+## Data and infrastructure model
+
+LogMeIn is vendor-operated SaaS. RustDesk lets you run the ID/rendezvous, relay, and Server Pro management services on infrastructure you control. Direct RustDesk sessions still travel between the endpoints, while relayed sessions traverse your relay. Self-hosting therefore controls the server-side services and stored deployment data; it does not mean every packet remains in the server's country.
+
+That distinction matters for network design, vendor review, and data-sovereignty work. It also transfers responsibility for capacity, certificates, backups, monitoring, and upgrades to your team.
+
+## Licensing and cost comparison
+
+Use current written quotes for the same technician count, managed endpoints, concurrency, support level, and required features. RustDesk commercial licensing counts **login users and managed devices**. Standard plans include unlimited concurrent connections; Customized V2 has a concurrency allowance. Hosting and operating labor belong in the RustDesk total, while SaaS infrastructure is generally bundled into the LogMeIn quote.
+
+Model at least three years and include migration, parallel running, training, and exit costs. That produces a defensible total cost; comparing headline prices does not.
+
+## Migration acceptance criteria
+
+Before removing the incumbent agent, verify external direct and relay connections, unattended recovery after reboot, elevation, file transfer, multi-monitor, macOS permissions, Linux display-server behavior, mobile workflows, access restrictions, audit evidence, backups, and server recovery. Keep a rollback path until representative users and endpoints pass.
+
+## The honest caveat
+
+Self-hosting is a real trade-off. It means someone on your side provisions a server, opens the right ports, sets up TLS, and keeps it patched — LogMeIn's cloud model hands all of that to the vendor. If you want a zero-maintenance managed service with nothing to run yourself, that ongoing ops work is worth weighing before you switch. For teams who already run a VPS or a spare server, it's usually a small lift; for teams with no one to own infrastructure, it's the one real cost of moving off LogMeIn's cloud.
+
+## Try it without a sales call
+
+- **Self-host the free community server today** — open source, no cost, no expiry.
+- **Want to try the Pro features?** Email [sales@rustdesk.com](mailto:sales@rustdesk.com) to ask about current evaluation terms, or check [rustdesk.com/pricing](https://rustdesk.com/pricing) for standard plan rates.
+- **Prefer to see it first?** Watch a full [video demo](/blog/see-rustdesk-in-action) on the [RustDesk YouTube channel](https://www.youtube.com/@rustdesk) — no booking required.
+
+Licensing is per login-user + per managed-device, and you can [upgrade any time](/blog/upgrade-rustdesk-license-mid-subscription). Start at [rustdesk.com/pricing](https://rustdesk.com/pricing).
@@ -0,0 +1,98 @@
+---
+publishDate: 2026-07-07T00:00:00Z
+lang: en
+translationKey: rustdesk-vs-rdp
+draft: false
+title: 'RustDesk vs RDP: Cross-Platform vs Windows-Native'
+excerpt: 'RustDesk vs Microsoft RDP: an honest comparison of cross-platform reach, internet access without a VPN, LAN speed, and security trade-offs.'
+image: ~/assets/images/blog/rustdesk-vs-rdp-og.png
+category: Comparisons
+tags:
+  - RustDesk
+  - RDP
+  - comparison
+author: RustDesk Team
+faq:
+  - question: 'Is RustDesk better than RDP?'
+    answer: 'It depends on the job. RDP is faster and free on a LAN between Windows Pro machines and integrates with Active Directory. RustDesk is cross-platform, brokers connections across NAT and firewalls without a VPN or port-forwarding, and is open source and self-hostable. Many teams use RDP internally and RustDesk for remote and mixed-OS access.'
+  - question: 'Do I need to open port 3389 to use RustDesk?'
+    answer: 'No. RustDesk connects out to an ID/rendezvous server and negotiates a peer-to-peer or relayed session, so you do not expose an inbound RDP port. Exposing port 3389 directly to the internet is a well-documented ransomware entry point, which is why RustDesk avoids it entirely.'
+  - question: 'Does RDP work on Windows Home?'
+    answer: 'No. Per Microsoft, Windows Home editions cannot act as a Remote Desktop host; only Professional, Enterprise, Education, and Windows Server editions can accept incoming RDP connections. RustDesk can host remote sessions on Windows Home, macOS, Linux, and Android; iOS acts as a controller only.'
+  - question: 'Can RustDesk connect to a Mac or Linux machine?'
+    answer: 'Yes. RustDesk can control macOS and Linux hosts from its supported desktop and mobile controller apps. RDP is primarily a Windows host protocol, so reaching macOS or Linux hosts usually means adding third-party servers or clients. RustDesk for iOS can control other devices but cannot expose an iPhone or iPad as a remote-control host.'
+metadata:
+  description: 'RustDesk vs Microsoft RDP compared honestly: cross-platform reach, internet access without a VPN, LAN performance, AD integration, and security trade-offs.'
+  keywords: 'RustDesk vs RDP, RustDesk vs Microsoft Remote Desktop, RDP over internet without VPN, cross-platform RDP alternative'
+---
+
+Microsoft's Remote Desktop Protocol (RDP) is the default answer for a lot of Windows shops: it is built in, it is fast, and it already speaks Active Directory. RustDesk approaches the same problem from a different direction — cross-platform, internet-first, and open source. Neither is strictly "better." They are built for different shapes of network.
+
+This comparison sticks to durable, verifiable differences: which platforms each supports, how each crosses the public internet, where the performance edges are, and the security trade-offs that come with each model.
+
+## The core architectural difference
+
+RDP is a **protocol built into Windows**. When you enable Remote Desktop, Windows opens a listening port (TCP 3389) and waits for an inbound connection. That is elegant on a LAN and painful across the internet, because _something_ has to route an outside connection to that port — a VPN, an RD Gateway, or port-forwarding on your router.
+
+RustDesk inverts that model. The client makes an **outbound** connection to an ID/rendezvous server, which brokers a peer-to-peer session between two devices and falls back to a relay when a direct path is not possible. Per the [RustDesk documentation](https://rustdesk.com/docs/en/), sessions are end-to-end encrypted (built on NaCl), and you can point every client at the public infrastructure, your own self-hosted server, or a rendezvous/relay you write yourself. Because endpoint clients initiate outbound connections, RustDesk traverses NAT and firewalls without a VPN or per-endpoint port-forwarding. This no-inbound-port benefit applies to the endpoints: a self-hosted server still accepts inbound connections on the documented ID, rendezvous, relay, and optional WebSocket service ports.
+
+## Platform reach
+
+RDP hosting is a Windows feature, and not on every edition. Microsoft is explicit: "Windows Home editions can't serve as Remote Desktop hosts," and only "Windows Professional, Enterprise, Education editions, and Windows Server editions ... can act as hosts for incoming Remote Desktop connections" ([Microsoft Learn](https://learn.microsoft.com/en-us/windows-server/remote/remote-desktop-services/remotepc/remote-desktop-allow-access)). Reaching a Mac or Linux box usually means bolting on third-party RDP servers or switching tools.
+
+RustDesk can control and be controlled on **Windows (including Home), macOS, Linux, and Android**, subject to each operating system's permissions. The iOS app acts as a controller only; Apple does not allow an iPhone or iPad to operate as a RustDesk remote-control host.
+
+## Crossing the internet: the security fork in the road
+
+This is where the two philosophies diverge most sharply. Microsoft's own guidance for reaching a PC from outside its network is to "use port forwarding or set up a VPN" ([Microsoft Learn](https://learn.microsoft.com/en-us/windows-server/remote/remote-desktop-services/remotepc/remote-desktop-allow-access)). Port-forwarding raw RDP to the internet is the option you should not take.
+
+Exposed RDP is one of the most abused entry points in cybercrime. The FBI's Internet Crime Complaint Center warned years ago that "cyber actors ... increasingly exploit the Remote Desktop Protocol to conduct malicious activity" ([IC3 PSA](https://www.ic3.gov/PSA/2018/PSA180927)), and the pattern has only hardened since — RDP compromise remains one of the most common initial-access vectors in ransomware incidents ([RH-ISAC](https://rhisac.org/ransomware/remote-desktop-protocol-use-in-ransomware-attacks/)). Internet-wide scanners find a freshly exposed 3389 within minutes and start credential-stuffing it.
+
+The safer way to publish RDP is through a properly configured VPN or RD Gateway with Network Level Authentication, but that is infrastructure you have to maintain. RustDesk uses outbound registration, NAT traversal, and relay fallback rather than exposing RDP directly on each endpoint. It still requires current clients, strong access controls, and review of public vulnerability records.
+
+## RustDesk vs RDP at a glance
+
+|                              | RustDesk                                                             | Microsoft RDP                                                                                                                                                              |
+| ---------------------------- | -------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| Cost                         | Open-source client; free self-hosted community server                | Free, built into Windows Pro/Enterprise/Education/Server                                                                                                                   |
+| Source code                  | Open source (AGPL), auditable                                        | Proprietary                                                                                                                                                                |
+| Host platforms               | Windows, macOS, Linux, Android                                       | Windows Pro/Enterprise/Education/Server ([not Home](https://learn.microsoft.com/en-us/windows-server/remote/remote-desktop-services/remotepc/remote-desktop-allow-access)) |
+| Controller platforms         | Windows, macOS, Linux, Android, iOS                                  | Windows, macOS, iOS, Android, and other Microsoft clients                                                                                                                  |
+| Internet access              | NAT traversal via rendezvous + relay, no VPN or port-forwarding      | Needs VPN, RD Gateway, or port-forwarding                                                                                                                                  |
+| Inbound port exposed         | None on endpoints; service ports on a self-hosted server             | TCP 3389 unless tunneled ([ransomware vector](https://www.ic3.gov/PSA/2018/PSA180927))                                                                                     |
+| Encryption                   | End-to-end (NaCl) by default ([docs](https://rustdesk.com/docs/en/)) | TLS/NLA; strong when configured correctly                                                                                                                                  |
+| LAN performance              | Very good; codec-based                                               | Excellent; native and low-latency                                                                                                                                          |
+| Directory/policy integration | LDAP/AD + OIDC SSO on Server Pro (Basic and up)                      | Deep Active Directory / Group Policy integration                                                                                                                           |
+| Self-hosting                 | Yes — your own ID/relay server                                       | N/A (native OS feature)                                                                                                                                                    |
+
+Confirm current RustDesk plan details at [rustdesk.com/pricing](https://rustdesk.com/pricing).
+
+## Where RDP still wins — honestly
+
+RDP earns its default status, and pretending otherwise would be dishonest:
+
+- **It is free and native on Windows.** If your endpoints are already Windows Pro or better, RDP is built in — nothing to install, deploy, or license.
+- **LAN performance is excellent.** As a native protocol tuned into the OS, RDP is hard to beat for latency and responsiveness on a fast local network, especially for RemoteApp and full-session desktop work.
+- **Active Directory and Group Policy integration is deep.** For domain-joined fleets, RDP's tie-in to AD authentication, GPO controls, and RD Gateway/RemoteApp infrastructure is more mature than any third-party tool's.
+- **It is a known quantity.** Windows admins already understand RDP's tooling, licensing, and behavior.
+
+If your world is a single Windows domain on a controlled network — or behind a VPN you already run — RDP may simply be the right tool, and adding RustDesk buys you little there.
+
+## Where RustDesk pulls ahead
+
+RustDesk's advantages show up the moment you leave that tidy single-domain LAN:
+
+- **Mixed operating systems.** One AGPL app controls Windows, macOS, Linux, and Android hosts; iOS can be used as a controller but not as a host.
+- **Internet access without exposure.** No 3389 on the internet, no per-endpoint VPN, no RD Gateway to run.
+- **Open source and self-hostable.** You can read the code, build it yourself, and keep the ID/relay servers — and your device list — on infrastructure you control. That auditability and data-residency story is the crux of the [case for self-hosting](/blog/why-self-host-remote-desktop-software).
+- **Consumer Windows and BYOD.** RustDesk works on Windows Home and unmanaged devices that RDP can't host.
+
+The honest caveat cuts the other way too: self-hosting means **someone on your side runs the server** — you provision a host, restrict ports, set up TLS, and patch it over time. That is the trade for control. If you want a native feature with nothing new to operate on a Windows-only LAN, RDP is hard to argue with.
+
+## So which should you use?
+
+For many teams the answer is _both_: RDP for fast, native, in-domain sessions on the LAN, and RustDesk for cross-platform, cross-internet, and BYOD access without punching a hole in the firewall. If you only need one, let the network shape decide — homogeneous Windows LAN leans RDP; mixed platforms, remote users, and self-hosting requirements lean RustDesk.
+
+## Try it
+
+Self-host the free community server today, or email [sales@rustdesk.com](mailto:sales@rustdesk.com) about evaluation terms. Standard plan rates are at [rustdesk.com/pricing](https://rustdesk.com/pricing), and there's a full walkthrough on the [RustDesk YouTube channel](https://www.youtube.com/@rustdesk).
--- a/Show More
+++ b/Show More