diff --git a/v3/netlify.toml b/v3/netlify.toml
index cbc12dbf..f8420f02 100644
--- a/v3/netlify.toml
+++ b/v3/netlify.toml
@@ -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
diff --git a/v3/src/assets/images/blog/anydesk-alternative-self-hosted-og.png b/v3/src/assets/images/blog/anydesk-alternative-self-hosted-og.png
new file mode 100644
index 00000000..63cce884
Binary files /dev/null and b/v3/src/assets/images/blog/anydesk-alternative-self-hosted-og.png differ
diff --git a/v3/src/assets/images/blog/anydesk-commercial-use-detected-og.png b/v3/src/assets/images/blog/anydesk-commercial-use-detected-og.png
new file mode 100644
index 00000000..ec0ee4e6
Binary files /dev/null and b/v3/src/assets/images/blog/anydesk-commercial-use-detected-og.png differ
diff --git a/v3/src/assets/images/blog/anydesk-price-increase-alternatives-og.png b/v3/src/assets/images/blog/anydesk-price-increase-alternatives-og.png
new file mode 100644
index 00000000..3a1f0a68
Binary files /dev/null and b/v3/src/assets/images/blog/anydesk-price-increase-alternatives-og.png differ
diff --git a/v3/src/assets/images/blog/avoid-remote-desktop-scams-og.png b/v3/src/assets/images/blog/avoid-remote-desktop-scams-og.png
new file mode 100644
index 00000000..6f11e7cf
Binary files /dev/null and b/v3/src/assets/images/blog/avoid-remote-desktop-scams-og.png differ
diff --git a/v3/src/assets/images/blog/best-free-remote-desktop-software-og.png b/v3/src/assets/images/blog/best-free-remote-desktop-software-og.png
new file mode 100644
index 00000000..c1304026
Binary files /dev/null and b/v3/src/assets/images/blog/best-free-remote-desktop-software-og.png differ
diff --git a/v3/src/assets/images/blog/best-screenconnect-alternative-msps-og.png b/v3/src/assets/images/blog/best-screenconnect-alternative-msps-og.png
new file mode 100644
index 00000000..655c8ede
Binary files /dev/null and b/v3/src/assets/images/blog/best-screenconnect-alternative-msps-og.png differ
diff --git a/v3/src/assets/images/blog/case-for-open-source-remote-access-og.png b/v3/src/assets/images/blog/case-for-open-source-remote-access-og.png
new file mode 100644
index 00000000..ee25511f
Binary files /dev/null and b/v3/src/assets/images/blog/case-for-open-source-remote-access-og.png differ
diff --git a/v3/src/assets/images/blog/chrome-remote-desktop-alternative-og.png b/v3/src/assets/images/blog/chrome-remote-desktop-alternative-og.png
new file mode 100644
index 00000000..f9f670e1
Binary files /dev/null and b/v3/src/assets/images/blog/chrome-remote-desktop-alternative-og.png differ
diff --git a/v3/src/assets/images/blog/gotomypc-alternative-self-hosted-og.png b/v3/src/assets/images/blog/gotomypc-alternative-self-hosted-og.png
new file mode 100644
index 00000000..c9fc4bfb
Binary files /dev/null and b/v3/src/assets/images/blog/gotomypc-alternative-self-hosted-og.png differ
diff --git a/v3/src/assets/images/blog/how-to-make-flutter-3.24-run-on-windows-7-og.png b/v3/src/assets/images/blog/how-to-make-flutter-3.24-run-on-windows-7-og.png
new file mode 100644
index 00000000..a2018054
Binary files /dev/null and b/v3/src/assets/images/blog/how-to-make-flutter-3.24-run-on-windows-7-og.png differ
diff --git a/v3/src/assets/images/blog/is-anydesk-safe-og.png b/v3/src/assets/images/blog/is-anydesk-safe-og.png
new file mode 100644
index 00000000..1eae0d5f
Binary files /dev/null and b/v3/src/assets/images/blog/is-anydesk-safe-og.png differ
diff --git a/v3/src/assets/images/blog/is-chrome-remote-desktop-safe-og.png b/v3/src/assets/images/blog/is-chrome-remote-desktop-safe-og.png
new file mode 100644
index 00000000..e36ff159
Binary files /dev/null and b/v3/src/assets/images/blog/is-chrome-remote-desktop-safe-og.png differ
diff --git a/v3/src/assets/images/blog/open-source-remote-desktop-software-og.png b/v3/src/assets/images/blog/open-source-remote-desktop-software-og.png
new file mode 100644
index 00000000..9bcfb1fc
Binary files /dev/null and b/v3/src/assets/images/blog/open-source-remote-desktop-software-og.png differ
diff --git a/v3/src/assets/images/blog/remote-desktop-alternatives-dameware-bomgar-supremo-parsec-remotepc-og.png b/v3/src/assets/images/blog/remote-desktop-alternatives-dameware-bomgar-supremo-parsec-remotepc-og.png
new file mode 100644
index 00000000..999b58bd
Binary files /dev/null and b/v3/src/assets/images/blog/remote-desktop-alternatives-dameware-bomgar-supremo-parsec-remotepc-og.png differ
diff --git a/v3/src/assets/images/blog/remote-desktop-data-sovereignty-gdpr-og.png b/v3/src/assets/images/blog/remote-desktop-data-sovereignty-gdpr-og.png
new file mode 100644
index 00000000..ca067ad9
Binary files /dev/null and b/v3/src/assets/images/blog/remote-desktop-data-sovereignty-gdpr-og.png differ
diff --git a/v3/src/assets/images/blog/rustdesk-active-directory-ldap-sso-og.png b/v3/src/assets/images/blog/rustdesk-active-directory-ldap-sso-og.png
new file mode 100644
index 00000000..21f015fa
Binary files /dev/null and b/v3/src/assets/images/blog/rustdesk-active-directory-ldap-sso-og.png differ
diff --git a/v3/src/assets/images/blog/rustdesk-and-remote-access-scams-og.png b/v3/src/assets/images/blog/rustdesk-and-remote-access-scams-og.png
new file mode 100644
index 00000000..52714a35
Binary files /dev/null and b/v3/src/assets/images/blog/rustdesk-and-remote-access-scams-og.png differ
diff --git a/v3/src/assets/images/blog/rustdesk-concurrent-connections-limit-og.png b/v3/src/assets/images/blog/rustdesk-concurrent-connections-limit-og.png
new file mode 100644
index 00000000..0d8e3217
Binary files /dev/null and b/v3/src/assets/images/blog/rustdesk-concurrent-connections-limit-og.png differ
diff --git a/v3/src/assets/images/blog/rustdesk-connected-waiting-for-image-og.png b/v3/src/assets/images/blog/rustdesk-connected-waiting-for-image-og.png
new file mode 100644
index 00000000..f9688467
Binary files /dev/null and b/v3/src/assets/images/blog/rustdesk-connected-waiting-for-image-og.png differ
diff --git a/v3/src/assets/images/blog/rustdesk-custom-quote-minimum-users-invoice-fees-og.png b/v3/src/assets/images/blog/rustdesk-custom-quote-minimum-users-invoice-fees-og.png
new file mode 100644
index 00000000..4b70d5c3
Binary files /dev/null and b/v3/src/assets/images/blog/rustdesk-custom-quote-minimum-users-invoice-fees-og.png differ
diff --git a/v3/src/assets/images/blog/rustdesk-for-enterprise-og.png b/v3/src/assets/images/blog/rustdesk-for-enterprise-og.png
new file mode 100644
index 00000000..bb2cc041
Binary files /dev/null and b/v3/src/assets/images/blog/rustdesk-for-enterprise-og.png differ
diff --git a/v3/src/assets/images/blog/rustdesk-for-linux-og.png b/v3/src/assets/images/blog/rustdesk-for-linux-og.png
new file mode 100644
index 00000000..5ac6bd09
Binary files /dev/null and b/v3/src/assets/images/blog/rustdesk-for-linux-og.png differ
diff --git a/v3/src/assets/images/blog/rustdesk-for-mac-og.png b/v3/src/assets/images/blog/rustdesk-for-mac-og.png
new file mode 100644
index 00000000..1238dcc9
Binary files /dev/null and b/v3/src/assets/images/blog/rustdesk-for-mac-og.png differ
diff --git a/v3/src/assets/images/blog/rustdesk-for-msps-og.png b/v3/src/assets/images/blog/rustdesk-for-msps-og.png
new file mode 100644
index 00000000..36323380
Binary files /dev/null and b/v3/src/assets/images/blog/rustdesk-for-msps-og.png differ
diff --git a/v3/src/assets/images/blog/rustdesk-lifetime-perpetual-license-og.png b/v3/src/assets/images/blog/rustdesk-lifetime-perpetual-license-og.png
new file mode 100644
index 00000000..e53a1daf
Binary files /dev/null and b/v3/src/assets/images/blog/rustdesk-lifetime-perpetual-license-og.png differ
diff --git a/v3/src/assets/images/blog/rustdesk-not-connecting-troubleshooting-og.png b/v3/src/assets/images/blog/rustdesk-not-connecting-troubleshooting-og.png
new file mode 100644
index 00000000..3cdfc771
Binary files /dev/null and b/v3/src/assets/images/blog/rustdesk-not-connecting-troubleshooting-og.png differ
diff --git a/v3/src/assets/images/blog/rustdesk-per-user-access-control-device-groups-shared-address-book-og.png b/v3/src/assets/images/blog/rustdesk-per-user-access-control-device-groups-shared-address-book-og.png
new file mode 100644
index 00000000..45f353e2
Binary files /dev/null and b/v3/src/assets/images/blog/rustdesk-per-user-access-control-device-groups-shared-address-book-og.png differ
diff --git a/v3/src/assets/images/blog/rustdesk-pro-license-cost-how-to-pay-og.png b/v3/src/assets/images/blog/rustdesk-pro-license-cost-how-to-pay-og.png
new file mode 100644
index 00000000..d3d5c103
Binary files /dev/null and b/v3/src/assets/images/blog/rustdesk-pro-license-cost-how-to-pay-og.png differ
diff --git a/v3/src/assets/images/blog/rustdesk-remote-control-android-ios-og.png b/v3/src/assets/images/blog/rustdesk-remote-control-android-ios-og.png
new file mode 100644
index 00000000..8fc41eb9
Binary files /dev/null and b/v3/src/assets/images/blog/rustdesk-remote-control-android-ios-og.png differ
diff --git a/v3/src/assets/images/blog/rustdesk-reseller-partner-program-og.png b/v3/src/assets/images/blog/rustdesk-reseller-partner-program-og.png
new file mode 100644
index 00000000..e048ce19
Binary files /dev/null and b/v3/src/assets/images/blog/rustdesk-reseller-partner-program-og.png differ
diff --git a/v3/src/assets/images/blog/rustdesk-scale-50000-200000-devices-og.png b/v3/src/assets/images/blog/rustdesk-scale-50000-200000-devices-og.png
new file mode 100644
index 00000000..82837d4c
Binary files /dev/null and b/v3/src/assets/images/blog/rustdesk-scale-50000-200000-devices-og.png differ
diff --git a/v3/src/assets/images/blog/rustdesk-self-hosted-vs-cloud-saas-option-og.png b/v3/src/assets/images/blog/rustdesk-self-hosted-vs-cloud-saas-option-og.png
new file mode 100644
index 00000000..5b228120
Binary files /dev/null and b/v3/src/assets/images/blog/rustdesk-self-hosted-vs-cloud-saas-option-og.png differ
diff --git a/v3/src/assets/images/blog/rustdesk-server-pro-free-trial-og.png b/v3/src/assets/images/blog/rustdesk-server-pro-free-trial-og.png
new file mode 100644
index 00000000..332334dd
Binary files /dev/null and b/v3/src/assets/images/blog/rustdesk-server-pro-free-trial-og.png differ
diff --git a/v3/src/assets/images/blog/rustdesk-server-pro-offline-air-gapped-og.png b/v3/src/assets/images/blog/rustdesk-server-pro-offline-air-gapped-og.png
new file mode 100644
index 00000000..12191c0b
Binary files /dev/null and b/v3/src/assets/images/blog/rustdesk-server-pro-offline-air-gapped-og.png differ
diff --git a/v3/src/assets/images/blog/rustdesk-server-pro-without-docker-og.png b/v3/src/assets/images/blog/rustdesk-server-pro-without-docker-og.png
new file mode 100644
index 00000000..3a378524
Binary files /dev/null and b/v3/src/assets/images/blog/rustdesk-server-pro-without-docker-og.png differ
diff --git a/v3/src/assets/images/blog/rustdesk-unattended-access-setup-og.png b/v3/src/assets/images/blog/rustdesk-unattended-access-setup-og.png
new file mode 100644
index 00000000..d733ed88
Binary files /dev/null and b/v3/src/assets/images/blog/rustdesk-unattended-access-setup-og.png differ
diff --git a/v3/src/assets/images/blog/rustdesk-unknown-devices-antivirus-scanning-og.png b/v3/src/assets/images/blog/rustdesk-unknown-devices-antivirus-scanning-og.png
new file mode 100644
index 00000000..23f2d626
Binary files /dev/null and b/v3/src/assets/images/blog/rustdesk-unknown-devices-antivirus-scanning-og.png differ
diff --git a/v3/src/assets/images/blog/rustdesk-vs-anydesk-og.png b/v3/src/assets/images/blog/rustdesk-vs-anydesk-og.png
new file mode 100644
index 00000000..e0a9211f
Binary files /dev/null and b/v3/src/assets/images/blog/rustdesk-vs-anydesk-og.png differ
diff --git a/v3/src/assets/images/blog/rustdesk-vs-logmein-og.png b/v3/src/assets/images/blog/rustdesk-vs-logmein-og.png
new file mode 100644
index 00000000..94263a9d
Binary files /dev/null and b/v3/src/assets/images/blog/rustdesk-vs-logmein-og.png differ
diff --git a/v3/src/assets/images/blog/rustdesk-vs-rdp-og.png b/v3/src/assets/images/blog/rustdesk-vs-rdp-og.png
new file mode 100644
index 00000000..a3870abf
Binary files /dev/null and b/v3/src/assets/images/blog/rustdesk-vs-rdp-og.png differ
diff --git a/v3/src/assets/images/blog/rustdesk-vs-screenconnect-og.png b/v3/src/assets/images/blog/rustdesk-vs-screenconnect-og.png
new file mode 100644
index 00000000..222a02a6
Binary files /dev/null and b/v3/src/assets/images/blog/rustdesk-vs-screenconnect-og.png differ
diff --git a/v3/src/assets/images/blog/rustdesk-vs-splashtop-og.png b/v3/src/assets/images/blog/rustdesk-vs-splashtop-og.png
new file mode 100644
index 00000000..dd4ac078
Binary files /dev/null and b/v3/src/assets/images/blog/rustdesk-vs-splashtop-og.png differ
diff --git a/v3/src/assets/images/blog/rustdesk-vs-teamviewer-og.png b/v3/src/assets/images/blog/rustdesk-vs-teamviewer-og.png
new file mode 100644
index 00000000..8948b6c8
Binary files /dev/null and b/v3/src/assets/images/blog/rustdesk-vs-teamviewer-og.png differ
diff --git a/v3/src/assets/images/blog/rustdesk-vs-vnc-og.png b/v3/src/assets/images/blog/rustdesk-vs-vnc-og.png
new file mode 100644
index 00000000..0d0e7ea7
Binary files /dev/null and b/v3/src/assets/images/blog/rustdesk-vs-vnc-og.png differ
diff --git a/v3/src/assets/images/blog/rustdesk-web-console-custom-client-generator-port-21114-og.png b/v3/src/assets/images/blog/rustdesk-web-console-custom-client-generator-port-21114-og.png
new file mode 100644
index 00000000..9a66f5f7
Binary files /dev/null and b/v3/src/assets/images/blog/rustdesk-web-console-custom-client-generator-port-21114-og.png differ
diff --git a/v3/src/assets/images/blog/see-rustdesk-in-action-og.png b/v3/src/assets/images/blog/see-rustdesk-in-action-og.png
new file mode 100644
index 00000000..45c9bd77
Binary files /dev/null and b/v3/src/assets/images/blog/see-rustdesk-in-action-og.png differ
diff --git a/v3/src/assets/images/blog/self-host-rustdesk-server-hardware-at-scale-og.png b/v3/src/assets/images/blog/self-host-rustdesk-server-hardware-at-scale-og.png
new file mode 100644
index 00000000..739ff79c
Binary files /dev/null and b/v3/src/assets/images/blog/self-host-rustdesk-server-hardware-at-scale-og.png differ
diff --git a/v3/src/assets/images/blog/self-hosted-teamviewer-alternative-og.png b/v3/src/assets/images/blog/self-hosted-teamviewer-alternative-og.png
new file mode 100644
index 00000000..2f16f129
Binary files /dev/null and b/v3/src/assets/images/blog/self-hosted-teamviewer-alternative-og.png differ
diff --git a/v3/src/assets/images/blog/teamviewer-commercial-use-detected-og.png b/v3/src/assets/images/blog/teamviewer-commercial-use-detected-og.png
new file mode 100644
index 00000000..e743da6b
Binary files /dev/null and b/v3/src/assets/images/blog/teamviewer-commercial-use-detected-og.png differ
diff --git a/v3/src/assets/images/blog/teamviewer-too-expensive-alternatives-og.png b/v3/src/assets/images/blog/teamviewer-too-expensive-alternatives-og.png
new file mode 100644
index 00000000..f81ff156
Binary files /dev/null and b/v3/src/assets/images/blog/teamviewer-too-expensive-alternatives-og.png differ
diff --git a/v3/src/assets/images/blog/teamviewer-vs-anydesk-for-msps-og.png b/v3/src/assets/images/blog/teamviewer-vs-anydesk-for-msps-og.png
new file mode 100644
index 00000000..5eacc6f1
Binary files /dev/null and b/v3/src/assets/images/blog/teamviewer-vs-anydesk-for-msps-og.png differ
diff --git a/v3/src/assets/images/blog/teamviewer-vs-splashtop-og.png b/v3/src/assets/images/blog/teamviewer-vs-splashtop-og.png
new file mode 100644
index 00000000..573f564f
Binary files /dev/null and b/v3/src/assets/images/blog/teamviewer-vs-splashtop-og.png differ
diff --git a/v3/src/assets/images/blog/upgrade-rustdesk-license-mid-subscription-og.png b/v3/src/assets/images/blog/upgrade-rustdesk-license-mid-subscription-og.png
new file mode 100644
index 00000000..7dde097b
Binary files /dev/null and b/v3/src/assets/images/blog/upgrade-rustdesk-license-mid-subscription-og.png differ
diff --git a/v3/src/assets/images/blog/what-counts-as-a-managed-device-og.png b/v3/src/assets/images/blog/what-counts-as-a-managed-device-og.png
new file mode 100644
index 00000000..e2e3b465
Binary files /dev/null and b/v3/src/assets/images/blog/what-counts-as-a-managed-device-og.png differ
diff --git a/v3/src/assets/images/blog/why-self-host-remote-desktop-software-og.png b/v3/src/assets/images/blog/why-self-host-remote-desktop-software-og.png
new file mode 100644
index 00000000..05344191
Binary files /dev/null and b/v3/src/assets/images/blog/why-self-host-remote-desktop-software-og.png differ
diff --git a/v3/src/assets/images/blog/zoho-assist-alternative-self-hosted-og.png b/v3/src/assets/images/blog/zoho-assist-alternative-self-hosted-og.png
new file mode 100644
index 00000000..3cd8dd1d
Binary files /dev/null and b/v3/src/assets/images/blog/zoho-assist-alternative-self-hosted-og.png differ
diff --git a/v3/src/components/blog/BlogFaq.astro b/v3/src/components/blog/BlogFaq.astro
new file mode 100644
index 00000000..e7cdda05
--- /dev/null
+++ b/v3/src/components/blog/BlogFaq.astro
@@ -0,0 +1,23 @@
+---
+export interface Props {
+ items?: Array<{ question: string; answer: string }>;
+}
+
+const { items = [] } = Astro.props;
+---
+
+{
+ items.length > 0 && (
+
+
Frequently asked questions
+
+ {items.map((item) => (
+
+ {item.question}
+
{item.answer}
+
+ ))}
+
+
+ )
+}
diff --git a/v3/src/components/common/StructuredData.astro b/v3/src/components/common/StructuredData.astro
index 634c8ca7..ba46c8f2 100644
--- a/v3/src/components/common/StructuredData.astro
+++ b/v3/src/components/common/StructuredData.astro
@@ -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
? {
diff --git a/v3/src/config.yaml b/v3/src/config.yaml
index ddcf6ca7..4a22729d 100644
--- a/v3/src/config.yaml
+++ b/v3/src/config.yaml
@@ -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
diff --git a/v3/src/content/config.ts b/v3/src/content/config.ts
index b9ef50a4..982b7da6 100644
--- a/v3/src/content/config.ts
+++ b/v3/src/content/config.ts
@@ -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(),
}),
diff --git a/v3/src/content/post/en/anydesk-alternative-self-hosted.md b/v3/src/content/post/en/anydesk-alternative-self-hosted.md
new file mode 100644
index 00000000..7c3846b5
--- /dev/null
+++ b/v3/src/content/post/en/anydesk-alternative-self-hosted.md
@@ -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).
diff --git a/v3/src/content/post/en/anydesk-commercial-use-detected.md b/v3/src/content/post/en/anydesk-commercial-use-detected.md
new file mode 100644
index 00000000..e8d19bdd
--- /dev/null
+++ b/v3/src/content/post/en/anydesk-commercial-use-detected.md
@@ -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.
diff --git a/v3/src/content/post/en/anydesk-price-increase-alternatives.md b/v3/src/content/post/en/anydesk-price-increase-alternatives.md
new file mode 100644
index 00000000..35ffd509
--- /dev/null
+++ b/v3/src/content/post/en/anydesk-price-increase-alternatives.md
@@ -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.
diff --git a/v3/src/content/post/en/avoid-remote-desktop-scams.md b/v3/src/content/post/en/avoid-remote-desktop-scams.md
new file mode 100644
index 00000000..f6a21da4
--- /dev/null
+++ b/v3/src/content/post/en/avoid-remote-desktop-scams.md
@@ -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).
diff --git a/v3/src/content/post/en/best-free-remote-desktop-software.md b/v3/src/content/post/en/best-free-remote-desktop-software.md
new file mode 100644
index 00000000..ea8f22e9
--- /dev/null
+++ b/v3/src/content/post/en/best-free-remote-desktop-software.md
@@ -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.
diff --git a/v3/src/content/post/en/best-screenconnect-alternative-msps.md b/v3/src/content/post/en/best-screenconnect-alternative-msps.md
new file mode 100644
index 00000000..652ce3ef
--- /dev/null
+++ b/v3/src/content/post/en/best-screenconnect-alternative-msps.md
@@ -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).
diff --git a/v3/src/content/post/en/case-for-open-source-remote-access.md b/v3/src/content/post/en/case-for-open-source-remote-access.md
new file mode 100644
index 00000000..5ba66f23
--- /dev/null
+++ b/v3/src/content/post/en/case-for-open-source-remote-access.md
@@ -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).
diff --git a/v3/src/content/post/en/chrome-remote-desktop-alternative.md b/v3/src/content/post/en/chrome-remote-desktop-alternative.md
new file mode 100644
index 00000000..51e06dd5
--- /dev/null
+++ b/v3/src/content/post/en/chrome-remote-desktop-alternative.md
@@ -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.
diff --git a/v3/src/content/post/en/gotomypc-alternative-self-hosted.md b/v3/src/content/post/en/gotomypc-alternative-self-hosted.md
new file mode 100644
index 00000000..0330c70a
--- /dev/null
+++ b/v3/src/content/post/en/gotomypc-alternative-self-hosted.md
@@ -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.
diff --git a/v3/src/content/post/en/is-anydesk-safe.md b/v3/src/content/post/en/is-anydesk-safe.md
new file mode 100644
index 00000000..999279bd
--- /dev/null
+++ b/v3/src/content/post/en/is-anydesk-safe.md
@@ -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.
diff --git a/v3/src/content/post/en/is-chrome-remote-desktop-safe.md b/v3/src/content/post/en/is-chrome-remote-desktop-safe.md
new file mode 100644
index 00000000..b4d3c517
--- /dev/null
+++ b/v3/src/content/post/en/is-chrome-remote-desktop-safe.md
@@ -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.
diff --git a/v3/src/content/post/en/open-source-remote-desktop-software.md b/v3/src/content/post/en/open-source-remote-desktop-software.md
new file mode 100644
index 00000000..58e49330
--- /dev/null
+++ b/v3/src/content/post/en/open-source-remote-desktop-software.md
@@ -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)
diff --git a/v3/src/content/post/en/remote-desktop-alternatives-dameware-bomgar-supremo-parsec-remotepc.md b/v3/src/content/post/en/remote-desktop-alternatives-dameware-bomgar-supremo-parsec-remotepc.md
new file mode 100644
index 00000000..bbb721f3
--- /dev/null
+++ b/v3/src/content/post/en/remote-desktop-alternatives-dameware-bomgar-supremo-parsec-remotepc.md
@@ -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.
diff --git a/v3/src/content/post/en/remote-desktop-data-sovereignty-gdpr.md b/v3/src/content/post/en/remote-desktop-data-sovereignty-gdpr.md
new file mode 100644
index 00000000..456ea383
--- /dev/null
+++ b/v3/src/content/post/en/remote-desktop-data-sovereignty-gdpr.md
@@ -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).
diff --git a/v3/src/content/post/en/rustdesk-active-directory-ldap-sso.md b/v3/src/content/post/en/rustdesk-active-directory-ldap-sso.md
new file mode 100644
index 00000000..cf28904c
--- /dev/null
+++ b/v3/src/content/post/en/rustdesk-active-directory-ldap-sso.md
@@ -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.
diff --git a/v3/src/content/post/en/rustdesk-and-remote-access-scams.md b/v3/src/content/post/en/rustdesk-and-remote-access-scams.md
new file mode 100644
index 00000000..53360387
--- /dev/null
+++ b/v3/src/content/post/en/rustdesk-and-remote-access-scams.md
@@ -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.
diff --git a/v3/src/content/post/en/rustdesk-concurrent-connections-limit.md b/v3/src/content/post/en/rustdesk-concurrent-connections-limit.md
new file mode 100644
index 00000000..e22298c2
--- /dev/null
+++ b/v3/src/content/post/en/rustdesk-concurrent-connections-limit.md
@@ -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.
diff --git a/v3/src/content/post/en/rustdesk-connected-waiting-for-image.md b/v3/src/content/post/en/rustdesk-connected-waiting-for-image.md
new file mode 100644
index 00000000..442ae76a
--- /dev/null
+++ b/v3/src/content/post/en/rustdesk-connected-waiting-for-image.md
@@ -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.
diff --git a/v3/src/content/post/en/rustdesk-custom-quote-minimum-users-invoice-fees.md b/v3/src/content/post/en/rustdesk-custom-quote-minimum-users-invoice-fees.md
new file mode 100644
index 00000000..78348d67
--- /dev/null
+++ b/v3/src/content/post/en/rustdesk-custom-quote-minimum-users-invoice-fees.md
@@ -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)
diff --git a/v3/src/content/post/en/rustdesk-for-enterprise.md b/v3/src/content/post/en/rustdesk-for-enterprise.md
new file mode 100644
index 00000000..3e4172d1
--- /dev/null
+++ b/v3/src/content/post/en/rustdesk-for-enterprise.md
@@ -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.
diff --git a/v3/src/content/post/en/rustdesk-for-linux.md b/v3/src/content/post/en/rustdesk-for-linux.md
new file mode 100644
index 00000000..91d38198
--- /dev/null
+++ b/v3/src/content/post/en/rustdesk-for-linux.md
@@ -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 `.
+
+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).
diff --git a/v3/src/content/post/en/rustdesk-for-mac.md b/v3/src/content/post/en/rustdesk-for-mac.md
new file mode 100644
index 00000000..96b5c70e
--- /dev/null
+++ b/v3/src/content/post/en/rustdesk-for-mac.md
@@ -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](), 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).
diff --git a/v3/src/content/post/en/rustdesk-for-msps.md b/v3/src/content/post/en/rustdesk-for-msps.md
new file mode 100644
index 00000000..22d24b21
--- /dev/null
+++ b/v3/src/content/post/en/rustdesk-for-msps.md
@@ -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.
diff --git a/v3/src/content/post/en/rustdesk-lifetime-perpetual-license.md b/v3/src/content/post/en/rustdesk-lifetime-perpetual-license.md
new file mode 100644
index 00000000..30126e5e
--- /dev/null
+++ b/v3/src/content/post/en/rustdesk-lifetime-perpetual-license.md
@@ -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.
diff --git a/v3/src/content/post/en/rustdesk-not-connecting-troubleshooting.md b/v3/src/content/post/en/rustdesk-not-connecting-troubleshooting.md
new file mode 100644
index 00000000..2c09ad77
--- /dev/null
+++ b/v3/src/content/post/en/rustdesk-not-connecting-troubleshooting.md
@@ -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.
diff --git a/v3/src/content/post/en/rustdesk-per-user-access-control-device-groups-shared-address-book.md b/v3/src/content/post/en/rustdesk-per-user-access-control-device-groups-shared-address-book.md
new file mode 100644
index 00000000..0d2343cd
--- /dev/null
+++ b/v3/src/content/post/en/rustdesk-per-user-access-control-device-groups-shared-address-book.md
@@ -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.
diff --git a/v3/src/content/post/en/rustdesk-pro-license-cost-how-to-pay.md b/v3/src/content/post/en/rustdesk-pro-license-cost-how-to-pay.md
new file mode 100644
index 00000000..990f3a9e
--- /dev/null
+++ b/v3/src/content/post/en/rustdesk-pro-license-cost-how-to-pay.md
@@ -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.
diff --git a/v3/src/content/post/en/rustdesk-remote-control-android-ios.md b/v3/src/content/post/en/rustdesk-remote-control-android-ios.md
new file mode 100644
index 00000000..1cb871f7
--- /dev/null
+++ b/v3/src/content/post/en/rustdesk-remote-control-android-ios.md
@@ -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).
diff --git a/v3/src/content/post/en/rustdesk-reseller-partner-program.md b/v3/src/content/post/en/rustdesk-reseller-partner-program.md
new file mode 100644
index 00000000..a3903f0f
--- /dev/null
+++ b/v3/src/content/post/en/rustdesk-reseller-partner-program.md
@@ -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).
diff --git a/v3/src/content/post/en/rustdesk-scale-50000-200000-devices.md b/v3/src/content/post/en/rustdesk-scale-50000-200000-devices.md
new file mode 100644
index 00000000..40016517
--- /dev/null
+++ b/v3/src/content/post/en/rustdesk-scale-50000-200000-devices.md
@@ -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.
diff --git a/v3/src/content/post/en/rustdesk-self-hosted-vs-cloud-saas-option.md b/v3/src/content/post/en/rustdesk-self-hosted-vs-cloud-saas-option.md
new file mode 100644
index 00000000..8cadbb6a
--- /dev/null
+++ b/v3/src/content/post/en/rustdesk-self-hosted-vs-cloud-saas-option.md
@@ -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.
diff --git a/v3/src/content/post/en/rustdesk-server-pro-free-trial.md b/v3/src/content/post/en/rustdesk-server-pro-free-trial.md
new file mode 100644
index 00000000..982a6cae
--- /dev/null
+++ b/v3/src/content/post/en/rustdesk-server-pro-free-trial.md
@@ -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.
diff --git a/v3/src/content/post/en/rustdesk-server-pro-offline-air-gapped.md b/v3/src/content/post/en/rustdesk-server-pro-offline-air-gapped.md
new file mode 100644
index 00000000..587d3bc0
--- /dev/null
+++ b/v3/src/content/post/en/rustdesk-server-pro-offline-air-gapped.md
@@ -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.
diff --git a/v3/src/content/post/en/rustdesk-server-pro-without-docker.md b/v3/src/content/post/en/rustdesk-server-pro-without-docker.md
new file mode 100644
index 00000000..92868395
--- /dev/null
+++ b/v3/src/content/post/en/rustdesk-server-pro-without-docker.md
@@ -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.
diff --git a/v3/src/content/post/en/rustdesk-unattended-access-setup.md b/v3/src/content/post/en/rustdesk-unattended-access-setup.md
new file mode 100644
index 00000000..73211b45
--- /dev/null
+++ b/v3/src/content/post/en/rustdesk-unattended-access-setup.md
@@ -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).
diff --git a/v3/src/content/post/en/rustdesk-unknown-devices-antivirus-scanning.md b/v3/src/content/post/en/rustdesk-unknown-devices-antivirus-scanning.md
new file mode 100644
index 00000000..0a44fa29
--- /dev/null
+++ b/v3/src/content/post/en/rustdesk-unknown-devices-antivirus-scanning.md
@@ -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
+```
+
+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.
diff --git a/v3/src/content/post/en/rustdesk-vs-anydesk.md b/v3/src/content/post/en/rustdesk-vs-anydesk.md
new file mode 100644
index 00000000..80964e56
--- /dev/null
+++ b/v3/src/content/post/en/rustdesk-vs-anydesk.md
@@ -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.
diff --git a/v3/src/content/post/en/rustdesk-vs-logmein.md b/v3/src/content/post/en/rustdesk-vs-logmein.md
new file mode 100644
index 00000000..77808ce9
--- /dev/null
+++ b/v3/src/content/post/en/rustdesk-vs-logmein.md
@@ -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).
diff --git a/v3/src/content/post/en/rustdesk-vs-rdp.md b/v3/src/content/post/en/rustdesk-vs-rdp.md
new file mode 100644
index 00000000..e8be64b0
--- /dev/null
+++ b/v3/src/content/post/en/rustdesk-vs-rdp.md
@@ -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).
diff --git a/v3/src/content/post/en/rustdesk-vs-screenconnect.md b/v3/src/content/post/en/rustdesk-vs-screenconnect.md
new file mode 100644
index 00000000..4bc95753
--- /dev/null
+++ b/v3/src/content/post/en/rustdesk-vs-screenconnect.md
@@ -0,0 +1,198 @@
+---
+publishDate: 2026-07-06T00:00:00Z
+lang: en
+translationKey: rustdesk-vs-screenconnect
+draft: false
+title: 'RustDesk vs ScreenConnect: The Self-Hosted Alternative'
+excerpt: 'A full comparison of RustDesk vs ScreenConnect: features, OS support, security (including CVE-2024-1709), pricing models, and the honest self-hosting trade-off.'
+image: ~/assets/images/blog/rustdesk-vs-screenconnect-og.png
+category: Comparisons
+tags:
+ - RustDesk
+ - ScreenConnect
+ - comparison
+author: RustDesk Team
+metadata:
+ description: 'RustDesk vs ScreenConnect compared in depth: features, OS support, security (incl. CVE-2024-1709), pricing models, and honest pros/cons for MSPs.'
+ keywords: 'RustDesk vs ScreenConnect, RustDesk vs ConnectWise Control, ScreenConnect self-hosted alternative, ScreenConnect comparison'
+---
+
+ScreenConnect comparisons often start with security, compliance, cost, or self-hosting requirements. This article relies on public incident disclosures and product documentation rather than reproducing private customer emails, contract dates, or deployment details.
+
+So this article tries to earn that "fair try." ScreenConnect (formerly ConnectWise Control) is a mature, capable remote-access platform with a large installed base in the MSP market. RustDesk is an open-source, self-hostable alternative. They are built on different philosophies — one a polished commercial SaaS with an ecosystem around it, the other software you run and own yourself — and the right answer genuinely depends on what you value. Below is a section-by-section comparison, kept neutral through the middle, with the honest trade-offs of self-hosting laid out plainly before we make any case for RustDesk.
+
+## Contents
+
+- [Overview: RustDesk and ScreenConnect at a glance](#overview-rustdesk-and-screenconnect-at-a-glance)
+- [Feature comparison](#feature-comparison)
+- [OS and platform support](#os-and-platform-support)
+- [Security and identity](#security-and-identity)
+- [Licensing and pricing models](#licensing-and-pricing-models)
+- [Where ScreenConnect still wins](#where-screenconnect-still-wins)
+- [Pros and cons](#pros-and-cons)
+- [Why MSPs switch to RustDesk anyway](#why-msps-switch-to-rustdesk-anyway)
+- [The honest caveat](#the-honest-caveat)
+- [Try RustDesk yourself](#try-rustdesk-yourself)
+- [Related reading](#related-reading)
+- [Sources](#sources)
+
+## Overview: RustDesk and ScreenConnect at a glance
+
+**ScreenConnect** is ConnectWise's remote-access and remote-support product, sold today under the ScreenConnect name (it spent several years branded as ConnectWise Control). It is aimed heavily at managed service providers and internal IT teams. You can run it as a managed cloud service on ConnectWise's infrastructure, or license an on-premise edition you host yourself. Its strongest selling point is depth and ecosystem: session recording, "Backstage" background administration, remote command line, remote printing, VoIP audio, and tight integration with the wider ConnectWise suite (PSA ticketing, Automate/RMM). If you already live in the ConnectWise world, ScreenConnect is designed to slot in.
+
+**RustDesk** is an open-source remote-desktop tool whose core client is released under the AGPL. Server Pro is self-hosted, so you operate the ID/rendezvous and relay services. Standard plans include unlimited concurrent connections; Customized V2 limits them. Custom client generation requires Basic or higher. The trade-off is that your team runs, patches, and secures the server.
+
+In one line: ScreenConnect is a mature commercial platform with an MSP ecosystem around it; RustDesk is open-source, self-hosted software you own outright.
+
+## Feature comparison
+
+The table below covers the everyday remote-support feature set. A note on method: for the **ScreenConnect** column, entries come from ConnectWise's own feature and pricing pages as of our research in July 2026 (sources listed at the end). For the **RustDesk** column, we deliberately list _only_ capabilities we can state as verified facts about the product; where a row is marked "†", the feature is simply outside the set of facts we're confirming in this article — not a claim that it's absent. Check the current RustDesk documentation to confirm specifics for your build.
+
+| Feature | RustDesk (self-hosted Server Pro) | ScreenConnect (ConnectWise Control) |
+| ------------------------------------ | --------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------- |
+| Remote view and control | Yes — hosts on Windows, macOS, Linux, and Android; iOS is controller-only | Yes — multi-monitor remote support across all tiers |
+| Unattended access to managed devices | Yes — managed devices via your self-hosted server, organized with device groups and a shared address book | Yes — unattended agents (10 on the entry tier; unlimited on higher tiers) |
+| Mobile access | Android can control or be controlled; iOS is controller-only | Yes — iOS and Android technician apps; mobile guest client support on Standard and above |
+| Session recording | † (confirm in current docs) | Yes — included from the Standard tier up |
+| File transfer | † (confirm in current docs) | Yes — included across tiers |
+| In-session chat | † (confirm in current docs) | Yes — in-session chat |
+| Remote printing | † (confirm in current docs) | Yes — print from the remote machine to a local printer |
+| Concurrent-connection limit | Unlimited on standard plans; limited on Customized V2 | Licensed per concurrent technician; see current tiers |
+
+Concurrency drives both cost models. ScreenConnect licenses simultaneous technician capacity, while RustDesk standard plans are unlimited and Customized V2 licenses a defined concurrency allowance. See the [RustDesk concurrency FAQ](/blog/rustdesk-concurrent-connections-limit).
+
+## OS and platform support
+
+Both tools are cross-platform, with one structural difference worth understanding: ScreenConnect distinguishes between the **host** side (the technician) and the **guest** side (the machine being supported), and platform support differs slightly between the two.
+
+| Platform | RustDesk | ScreenConnect |
+| ------------------ | ------------------- | -------------------------------------------------------- |
+| Windows | Yes (client) | Yes — host and guest (Windows 10/11, Server 2016–2025) |
+| macOS | Yes (client) | Yes — host and guest (current and previous two versions) |
+| Linux | Yes (client) | Yes — host and guest (x86_64, glibc 2.17+) |
+| Android | Host and controller | Guest support; Android technician app |
+| iOS | Controller only | Guest support; iOS technician app |
+| Browser-based host | Not verified here † | Yes — host via Chrome, Firefox, Safari, Edge |
+
+A couple of clarifications so nobody is misled. ConnectWise's own compatibility page, as of our research, lists Windows/macOS/Linux for host and guest plus iOS and Android mobile apps; some third-party write-ups also mention ChromeOS and Raspberry Pi clients, but we could not verify those on ConnectWise's official page, so we've left them out. Separately, when teams talk about Raspberry Pi in a RustDesk evaluation, they usually mean self-hosting the _RustDesk server_ on small hardware — that's a server-side deployment story, not a client platform claim.
+
+## Security and identity
+
+This section covers the security and compliance questions that usually drive the evaluation.
+
+**ScreenConnect's security model.** ConnectWise's current pricing page lists AES-256 encryption, two-factor authentication, brute-force prevention, granular access management, and integrations with LDAP, SAML, OAuth, and other SSO providers. Its on-premise product page lists multi-factor authentication and role-based access controls and describes configurations intended to support SOC 2, PCI, CJIS, and HIPAA requirements. These are vendor claims rather than a conclusion that any deployment is automatically compliant; the first-party pages are linked in [Sources](#sources).
+
+**The 2024 incident.** One reason teams evaluating alternatives point to ScreenConnect's 2024 history is a specific, well-documented event. In February 2024, a critical authentication-bypass vulnerability in ScreenConnect, **CVE-2024-1709**, was disclosed. It carried a CVSS score of 10.0 — the maximum — and worked by appending a trailing slash to the `SetupWizard.aspx` URL to bypass a request filter, letting an unauthenticated attacker create a new administrator account and take full control of the server. It was paired with a path-traversal flaw, CVE-2024-1708. Affected versions were 23.9.7 and earlier; the fix shipped in 23.9.8. The bug was trivially exploitable, proof-of-concept exploits appeared almost immediately, and it was quickly tied to active exploitation, including ransomware activity.
+
+[A widely reported ScreenConnect vulnerability](https://www.cisa.gov/news-events/alerts/2024/02/22/cisa-adds-one-known-exploited-connectwise-vulnerability-cve-2024-1709-catalog) triggered emergency patching and public scrutiny across the MSP market. CISA added CVE-2024-1709 to its Known Exploited Vulnerabilities catalog on February 22, 2024 — the formal signal that a flaw is being exploited in the wild and must be remediated on a deadline.
+
+One nuance matters for how you read this, and it cuts in ScreenConnect's favor as much as against it: ConnectWise's **cloud-hosted** customers (on screenconnect.com and hostedrmm.com) were patched automatically, with no end-user action required. It was **self-hosted / on-premise** operators who had to scramble to update their own servers. That is the double edge of self-hosting anything, RustDesk very much included — which is exactly why we devote a whole section to [the honest caveat](#the-honest-caveat) below.
+
+**RustDesk's security model.** RustDesk's approach is structurally different. The core client is open source under the AGPL, which means it can be independently audited and built from source rather than taken on trust — a property no closed-source competitor can offer. Server Pro is self-hosted, so the rendezvous/relay servers run on your own machine or VPS and session brokering stays within infrastructure you control; for teams whose driving concern is data residency and GDPR, that on-premise posture is the whole point. On identity, RustDesk supports LDAP and SSO via OIDC — and here's a point worth stating plainly: **LDAP/SSO is available from the Basic plan and up, not on every paid plan below it.** Administration runs through a self-hosted web console, and access control is handled with device groups and a shared address book so you can scope which users reach which machines. Setup specifics are in our [RustDesk LDAP and Active Directory guide](/blog/rustdesk-active-directory-ldap-sso).
+
+Being open source does not make software invulnerable. Review RustDesk's [latest releases](https://github.com/rustdesk/rustdesk/releases) and public vulnerability records. ScreenConnect cloud mode provides a vendor-operated service; RustDesk provides auditable code and self-hosted server-side services, along with operating responsibility. For the routing and residency boundaries, see [Remote Desktop and Data Sovereignty](/blog/remote-desktop-data-sovereignty-gdpr).
+
+## Licensing and pricing models
+
+Pricing changes often, so rather than treat any number as permanent fact, we'll compare the two _models_ and time-stamp the figures.
+
+**ScreenConnect** packages technician/session capacity, unattended agents, and features by product and tier. Those details change, and on-premises terms require direct confirmation. Use ConnectWise's current pricing page and a written quote for the same technicians, simultaneous sessions, unattended endpoints, security controls, and support requirements; this article does not preserve a price snapshot that will become stale.
+
+**RustDesk** prices login users and managed devices. Standard plans include unlimited concurrent connections; Customized V2 adds a defined concurrency allowance. A straight sticker comparison is misleading, so size both products against actual user, device, concurrency, feature, and support requirements. Current RustDesk pricing lives at [rustdesk.com/pricing](https://rustdesk.com/pricing).
+
+## Where ScreenConnect still wins
+
+A fair comparison has to say where the incumbent is genuinely the better pick, and for a meaningful set of buyers ScreenConnect is.
+
+- **Deep ConnectWise ecosystem integration.** This is the big one. If you already run ConnectWise PSA for ticketing and ConnectWise Automate/RMM for monitoring and patching, ScreenConnect is built to plug straight in. Through ScreenConnect Privileged Access, elevation and admin-logon requests can be approved or denied inside PSA tickets, creating an audit trail in your system of record; ScreenConnect View lets technicians launch visual support directly from a ticket. For an MSP standardized on the ConnectWise stack, that end-to-end workflow is hard for a standalone tool to match.
+- **Fully managed cloud option.** ScreenConnect's cloud tiers mean there's no server for you to run, harden, or patch — and, as the 2024 incident showed, cloud customers were remediated automatically. If you specifically want to _not_ be responsible for server maintenance, that's a real advantage.
+- **Feature maturity and polish.** Backstage background administration, VoIP audio, video auditing, a remote diagnostics toolkit, and years of MSP-driven refinement add up. ScreenConnect is a well-worn tool with the rough edges sanded down.
+- **Market presence and hiring.** It's widely deployed, so documentation, community knowledge, and technicians who already know it are easy to find.
+- **Session-sharing economics for small teams.** Because licenses are per concurrent session rather than per named user, a small team that rarely runs many sessions at once can share a couple of licenses efficiently.
+
+If you're an MSP whose whole delivery model is built on ConnectWise PSA + RMM, that integration gravity is a legitimate reason to stay — and you should weigh it honestly.
+
+## Pros and cons
+
+**RustDesk**
+
+_Pros_
+
+- Open-source (AGPL) core client — auditable and buildable from source
+- Self-hosted Server Pro keeps brokering/relay on infrastructure you own (data sovereignty, GDPR)
+- Unlimited concurrent connections on standard plans; limited on Customized V2
+- Custom-branded client generator
+- Free community server runs indefinitely at no cost
+- Scales to large fleets (more on this below)
+
+_Cons_
+
+- You run, patch, and secure the server yourself — it is not a managed SaaS
+- No fully free trial of Server Pro (email sales@rustdesk.com for a test license)
+- Some conveniences (LDAP/SSO) start at the Basic plan, not the entry tier
+- Smaller commercial ecosystem than ConnectWise's
+
+**ScreenConnect**
+
+_Pros_
+
+- Deep integration with the ConnectWise PSA/RMM ecosystem
+- Managed cloud option with automatic patching
+- Mature, polished feature set (session recording, Backstage, VoIP, diagnostics)
+- Broad, established MSP install base and support community
+- Enterprise identity controls (2FA, SSO/SAML/OAuth, LDAP, and role-based access controls)
+
+_Cons_
+
+- Proprietary and closed-source — you can't audit the code
+- Concurrent-technician licensing meters your capacity
+- Was the subject of the critical CVE-2024-1709 authentication-bypass incident; self-hosted operators bore the patching burden
+- Advanced features gated behind higher tiers; some functions are separate paid product lines
+
+## Why MSPs switch to RustDesk anyway
+
+Everything above is the neutral comparison. Here's the part where we're openly making RustDesk's case — because the requirements above are the ones that typically push MSPs to evaluate a self-hosted alternative in the first place.
+
+**Data sovereignty and self-hosting.** Server Pro lets you choose where ID, relay, console, and device data run. Direct endpoint traffic still crosses the networks between those endpoints, and compliance requires more than server placement. See [Self-Hosted vs Cloud](/blog/rustdesk-self-hosted-vs-cloud-saas-option) and [Remote Desktop and Data Sovereignty](/blog/remote-desktop-data-sovereignty-gdpr).
+
+**Open source you can actually verify.** The AGPL client can be audited and built from source. After a maximum-severity CVE in a closed competitor sends hospitals scrambling to block the software, "we can read the code ourselves" stops sounding academic.
+
+**Plan-dependent concurrency.** Standard plans are unlimited; Customized V2 licenses a defined number of concurrent connections. Details are in the [concurrency FAQ](/blog/rustdesk-concurrent-connections-limit).
+
+**A client with your name on it.** RustDesk's custom-branded client generator lets you ship a tool that carries your brand to end users rather than a vendor's — meaningful for MSPs whose clients should see _their_ provider, not a third party.
+
+**It scales beyond a proof-of-concept box.** Many teams start by self-hosting on modest hardware to prove the concept, then validate capacity against their real concurrency and relay profile. See [Can RustDesk Scale to 50,000+ Devices?](/blog/rustdesk-scale-50000-200000-devices) and [Self-Host Hardware for Large Fleets](/blog/self-host-rustdesk-server-hardware-at-scale).
+
+If you're evaluating specifically as an MSP, our [Best ScreenConnect Alternative for MSPs](/blog/best-screenconnect-alternative-msps) and [RustDesk for MSPs](/blog/rustdesk-for-msps) pieces are written for exactly your situation; enterprise buyers should start with [RustDesk for Enterprise](/blog/rustdesk-for-enterprise).
+
+## The honest caveat
+
+We'd rather you switch with clear eyes than switch and regret it, so the most important trade-off gets stated plainly: **self-hosting means you run, patch, and secure the server yourself.** RustDesk Server Pro is not a zero-maintenance managed SaaS. Nobody is auto-patching it for you at 2 a.m.
+
+That's not a footnote — it's the flip side of the 2024 ScreenConnect story. When CVE-2024-1709 hit, ConnectWise's cloud customers were remediated automatically while self-hosted operators had to move fast on their own. Any self-hosted tool, RustDesk included, puts that responsibility on you. Self-hosting buys you control and data sovereignty; it also buys you the duty to keep the thing updated. If your team doesn't want to own server maintenance at all, a managed cloud product may genuinely fit you better, and that's a legitimate reason to choose one. Go in knowing which trade-off you're making.
+
+## Try RustDesk yourself
+
+The no-pressure way to evaluate RustDesk is a representative proof of concept:
+
+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.
+
+You can also just [See RustDesk in Action](/blog/see-rustdesk-in-action) first if you'd like a guided tour before you deploy anything.
+
+## Related reading
+
+- [Best ScreenConnect Alternative for MSPs](/blog/best-screenconnect-alternative-msps)
+- [RustDesk for MSPs](/blog/rustdesk-for-msps)
+- [RustDesk vs AnyDesk](/blog/rustdesk-vs-anydesk)
+- [Self-Hosted vs Cloud Remote Desktop](/blog/rustdesk-self-hosted-vs-cloud-saas-option)
+
+## Sources
+
+ScreenConnect product details were checked against these first-party ConnectWise pages on July 7, 2026. Features, platform support, packaging, and prices can change; verify the current pages and a written quote before purchasing.
+
+- [ScreenConnect pricing plans](https://www.screenconnect.com/pricing) — current tiers, simultaneous-session limits, unattended agents, remote-support features, security controls, identity integrations, and ConnectWise integrations.
+- [ScreenConnect on-premise](https://www.screenconnect.com/on-premise) — self-hosting, Backstage, session recording, compatibility, security, and vendor-stated compliance capabilities.
+- [ScreenConnect host client requirements](https://docs.connectwise.com/ScreenConnect_Documentation/Get_started/Host_client/Host_client_requirements) — technician-side operating-system requirements.
+- [ScreenConnect guest client requirements](https://docs.connectwise.com/ScreenConnect_Documentation/Get_started/Guest_client/Guest_client_requirements) — supported-device operating-system requirements.
+- [ScreenConnect iOS app requirements](https://docs.connectwise.com/ScreenConnect_Documentation/Mobile_apps/iOS/iOS_app_requirements) — current iOS application requirements and manufacturer restrictions.
+- [ConnectWise ScreenConnect 23.9.8 security bulletin](https://www.connectwise.com/company/trust/security-bulletins/connectwise-screenconnect-23.9.8) — affected versions, cloud remediation, and on-premise patch guidance for CVE-2024-1708 and CVE-2024-1709.
diff --git a/v3/src/content/post/en/rustdesk-vs-splashtop.md b/v3/src/content/post/en/rustdesk-vs-splashtop.md
new file mode 100644
index 00000000..ba57aa5e
--- /dev/null
+++ b/v3/src/content/post/en/rustdesk-vs-splashtop.md
@@ -0,0 +1,192 @@
+---
+publishDate: 2026-07-06T00:00:00Z
+lang: en
+translationKey: rustdesk-vs-splashtop
+draft: false
+title: 'Self-Hosted Splashtop Alternative: What IT Teams Should Evaluate Before Switching'
+excerpt: 'A self-hosted Splashtop alternative evaluation guide covering licensing, infrastructure, reliability evidence, workflow testing, and migration risk.'
+image: ~/assets/images/blog/rustdesk-vs-splashtop-og.png
+category: Comparisons
+tags:
+ - RustDesk
+ - Splashtop
+ - comparison
+author: RustDesk Team
+faq:
+ - question: 'Can both RustDesk and Splashtop be self-hosted?'
+ answer: 'Yes, but through different product models. RustDesk provides a free open-source server and commercial Server Pro plans built around self-hosting. Splashtop offers a separately licensed proprietary On-Prem product in addition to its mainstream SaaS plans.'
+ - question: 'What infrastructure does Splashtop On-Prem require?'
+ answer: 'Splashtop On-Prem uses a customer-operated Splashtop Gateway. The organization must plan server capacity, networking, TLS, monitoring, backup, upgrades, and availability according to its deployment requirements.'
+ - question: 'When is Splashtop SaaS a better fit than RustDesk?'
+ answer: 'Splashtop SaaS may be a better fit when a team wants the vendor to operate the service and does not require an open-source client or customer-controlled server-side services. Test required workflows and compare current written terms before migrating.'
+ - question: 'How should an IT team test a Splashtop replacement?'
+ answer: 'Run a parallel pilot with representative users, endpoints, networks, and support workflows. Define acceptance criteria for connection reliability, remote audio, monitor mapping, mobile access, administration, and security controls, and keep a documented rollback path until the replacement passes them.'
+metadata:
+ description: 'Evaluate a self-hosted Splashtop alternative across licensing, infrastructure, workflow compatibility, security controls, pilot design, and migration risk.'
+ keywords: 'self-hosted Splashtop alternative, Splashtop replacement, migrate from Splashtop, RustDesk vs Splashtop, Splashtop alternative for IT teams'
+---
+
+A self-hosted Splashtop alternative is worth evaluating when your IT team needs control over server-side services, an open-source core client, or a licensing model that better matches its users, devices, and simultaneous sessions. It is not automatically the right move: switching also transfers infrastructure work to your team and can expose workflow gaps that a feature matrix misses.
+
+Splashtop sells managed SaaS plans and a **separately licensed On-Prem** product. RustDesk makes self-hosting the core deployment model through its free community server and Server Pro. The useful comparison is therefore between three operating models, not simply "cloud versus self-hosted."
+
+## The short answer
+
+| Decision factor | RustDesk | Splashtop SaaS | Splashtop On-Prem |
+| ------------------- | --------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------- |
+| Server operation | Customer-operated community server or Server Pro | Vendor-operated | Customer-operated Splashtop On-Prem Gateway |
+| Source model | Core client and community server are open source under AGPL | Proprietary | Proprietary |
+| Licensing | Standard Server Pro plans use login users plus managed devices; Customized V2 also meters concurrency | Varies by Remote Access, Remote Support, or Enterprise plan | Separately licensed and sales-led; confirm the written quote |
+| Concurrent sessions | Unlimited on standard plans; a defined allowance on Customized V2 | Plan-dependent | License-dependent |
+| Governance | Server Pro features are plan-dependent; compare SSO, 2FA, audit, access control, address books, and device management | Enterprise controls are plan-dependent | User/group permissions, Active Directory integration, IP restrictions, and other features are edition-dependent |
+| Infrastructure work | Your team owns deployment, TLS, network exposure, monitoring, backup, upgrades, and availability | Vendor owns the service infrastructure | Your team owns Gateway sizing, network placement, TLS, monitoring, backup, upgrades, and availability |
+| Best starting point | Free community server for basic evaluation; Server Pro trial for management features | SaaS trial for teams that want a managed service | Direct sales and a scoped infrastructure evaluation |
+
+Choose the operating model before comparing individual features. If your team wants a vendor to run the service, compare RustDesk's operational burden with Splashtop SaaS. If infrastructure control is mandatory, compare RustDesk Server Pro with Splashtop On-Prem.
+
+## Why IT teams evaluate alternatives to Splashtop
+
+The reasons usually fall into four decision areas. These are evaluation prompts, not claims that every Splashtop customer has the same experience.
+
+### Licensing fit
+
+Remote-support workloads can be measured by technicians, named users, managed endpoints, attended sessions, or concurrent connections. A plan that works for a small fixed team may become awkward for an MSP, a seasonal workforce, or an organization near a device threshold. Compare the current written terms against your actual workload rather than assuming any vendor is always cheaper.
+
+### Infrastructure control
+
+Some organizations need session-brokering services and management data on infrastructure they operate. Others want a managed service precisely because they do not want to maintain servers. RustDesk, Splashtop SaaS, and Splashtop On-Prem answer those requirements differently.
+
+### Reliability and performance
+
+Public discussions include reports of crashes, failed connections, lag, and services that need restarting. They also include administrators who report years of stable use. Some complaints involve Splashtop delivered through an RMM integration rather than the standalone service. These reports can identify scenarios to test, but they **do not establish how common** a problem is across the installed base.
+
+### Workflow and governance requirements
+
+The migration decision often turns on details such as remote audio, multi-monitor behavior, browser access, SSO, audit logs, device inventory, user/group permissions, custom clients, and RMM integration. A replacement that passes a basic remote-control test can still fail the daily support workflow.
+
+## Deployment: compare the correct Splashtop product
+
+Splashtop's standard Remote Access and Remote Support plans are vendor-operated. Its [official pricing page](https://www.splashtop.com/pricing) lists an On-Prem option under enterprise offerings, and the separate [On-Prem product page](https://www.splashtop.com/products/on-prem) describes installing a **Splashtop On-Prem Gateway** in a DMZ or behind the corporate firewall.
+
+Splashtop On-Prem is therefore real, but it is not the default deployment behind every Splashtop subscription. It is a separate proprietary product with direct sales engagement and customer-side infrastructure. Splashtop's [system requirements](https://support-splashtoponprem.splashtop.com/hc/en-us/articles/360035393074-Splashtop-On-Prem-System-Requirements) specify Gateway operating systems, hardware sizing, networking, and port requirements.
+
+RustDesk starts from the opposite direction. The community server and Server Pro are self-hosted. With Server Pro, the ID/rendezvous server, relay, console, and stored deployment data run on infrastructure you control; direct sessions can still flow between endpoints. This provides architectural control, but it does not remove the need to secure and operate the server.
+
+Do not describe Splashtop as cloud-only, and do not treat a standard Splashtop SaaS trial as an evaluation of Splashtop On-Prem. They have different deployment and procurement paths.
+
+## Source code and trust model
+
+RustDesk's core client and community server are available under the AGPL. A security or engineering team can inspect the code, build the client, and run the free server without first purchasing a commercial license. Server Pro adds proprietary management capabilities on top of that model.
+
+Splashtop SaaS and Splashtop On-Prem are proprietary. On-Prem changes where the server components run; it does not make the product open source. Buyers should evaluate those as separate questions:
+
+1. Do server-side services need to run on infrastructure we control?
+2. Do we need source visibility and the ability to build the core client ourselves?
+
+Splashtop On-Prem can answer the first requirement. RustDesk is designed to answer both.
+
+## Licensing and cost: model the required system
+
+RustDesk standard Server Pro plans are sized by login users and managed devices and include unlimited concurrent connections. Customized V2 instead includes a defined concurrency allowance and prices additional connections. For current figures, use [RustDesk pricing](https://rustdesk.com/pricing) and a dated quote for customized terms.
+
+Splashtop pricing depends on whether the requirement is Remote Access, Remote Support, Enterprise SaaS, or On-Prem. Its public pricing page provides figures for several SaaS plans, while Enterprise and On-Prem require sales engagement. Compare the same quantities on both sides:
+
+- technicians or login users;
+- managed endpoints;
+- simultaneous sessions;
+- required identity, audit, access-control, and recording features;
+- server infrastructure and operations;
+- support, contract, and renewal terms.
+
+A lower starting price, another customer's historical quote, or a first-year promotion does not establish the cost of the required deployment. Ask both vendors for dated written terms and model renewal as well as initial purchase.
+
+## Reliability reports: useful signals, not prevalence data
+
+A 2025 thread in the [Splashtop official community](https://www.reddit.com/r/Splashtop_Official/comments/1ltgest/constant_crashing_on_local_win10_computer/) documents Windows client crashes and follow-up troubleshooting. A separate 2026 [Atera community discussion](https://www.reddit.com/r/atera/comments/1qucbx3/is_splashtop_just_terrible_for_you_guys/) contains both negative reports and administrators describing stable deployments. It also shows why an **integration-specific** problem should not automatically be attributed to the standalone Splashtop product.
+
+Use reports like these to build a test matrix, not to publish an unbounded claim that Splashtop is unreliable. Record results on your own endpoint mix, network paths, RMM packaging, security software, and operating-system versions.
+
+## Operations: self-hosting is a responsibility
+
+RustDesk and Splashtop On-Prem both place operational work on the customer. The implementation details differ, but either evaluation should cover:
+
+- server sizing and capacity headroom;
+- public and private network paths;
+- TLS certificates and key handling;
+- monitoring, logs, backup, and recovery;
+- upgrade cadence and rollback procedures;
+- high availability and disaster recovery;
+- administrator access and change control.
+
+If the organization does not want to own those tasks, Splashtop SaaS may be a better fit than either self-hosted option. Infrastructure control is valuable only when the team is prepared to operate it.
+
+## Governance and workflow fit
+
+The free RustDesk community server does not include every Server Pro governance feature. If you need SSO, controlled-device 2FA, audit logs, synchronized address books, or scoped access through user assignments and device groups, compare the current Server Pro plan matrix and [LDAP/SSO documentation](/blog/rustdesk-active-directory-ldap-sso).
+
+Do not infer Splashtop On-Prem capabilities from a Splashtop SaaS trial, and do not infer Server Pro capabilities from the free RustDesk server. Confirm the exact edition and license for identity integration, permissions, high availability, recording, IP restrictions, and other required controls.
+
+## Migration checklist: test the workflow, not the logo
+
+Build acceptance criteria before installing the replacement. At minimum, validate these areas.
+
+### 1. Connectivity and performance
+
+- Connect through office, home, mobile, high-latency, and restricted networks.
+- Test direct connections and relay fallback.
+- Measure connection time, interaction latency, image quality, reconnect behavior, and simultaneous sessions.
+- Repeat tests on the operating-system versions and RMM deployment methods you use in production.
+
+### 2. Technician and end-user workflow
+
+- Test attended support, unattended access, privilege elevation, clipboard, file transfer, remote printing, and session recording.
+- Verify **remote audio**, microphone passthrough, and the behavior of audio devices after reconnecting.
+- Test multi-monitor layouts, full-screen transitions, and whether the client preserves the expected **monitor mapping** between sessions.
+- Confirm that custom clients, address books, device groups, and technician identity work as expected.
+
+### 3. Mobile and browser behavior
+
+- Test the exact controller and controlled-device combinations you deploy.
+- Confirm which mobile platforms support control and which operate only as controllers.
+- Validate browser access, WebSocket routing, authentication, and session features separately from native clients.
+
+### 4. Governance and security
+
+- Verify SSO or directory integration, controlled-device 2FA, audit logs, user assignments, device groups, and cross-group access rules.
+- Confirm IP allowlists, recording policy, administrator roles, log retention, and offboarding behavior.
+- Test that knowing a device ID does not bypass the authorization model you intend to enforce.
+
+### 5. Server operations
+
+- Document ports, TLS certificates, DNS, firewall rules, backup, recovery, monitoring, upgrades, and rollback.
+- Load-test realistic online-device and simultaneous-session counts.
+- Decide who owns incidents outside business hours and how technicians connect if the primary server is unavailable.
+
+## Run a parallel pilot and keep a rollback path
+
+Do not replace the incumbent across the whole fleet after one successful session. Start with a **parallel pilot** that represents different technicians, endpoint types, locations, network conditions, and support workflows.
+
+1. Inventory current Splashtop users, endpoints, policies, integrations, and required features.
+2. Define measurable acceptance criteria and assign an owner to each test.
+3. Run both systems during the pilot so technicians can compare behavior and keep supporting users.
+4. Move a staged cohort only after the replacement passes its required workflows.
+5. Keep the previous agent and configuration available until the new deployment has passed the agreed observation period.
+6. Document the **rollback** trigger, responsible person, and recovery procedure before expanding rollout.
+
+This approach costs more during the overlap, but it reduces the risk of discovering a missing workflow after the original tool has been removed.
+
+## When staying with Splashtop makes sense
+
+Splashtop SaaS may be the better choice when the team wants a vendor-operated service and its required workflows fit the selected plan. Splashtop On-Prem may remain the better choice for an existing customer that needs local server components and values continuity with Splashtop clients, administration, or support.
+
+Migration is not automatically cheaper or lower risk. Account for rollout effort, retraining, policy recreation, parallel operation, and rollback. Splashtop may also retain an advantage for a particular workflow or under an existing contract. A feature checklist cannot reveal those differences; only a representative pilot can.
+
+## When RustDesk is the stronger candidate
+
+RustDesk deserves evaluation when the organization wants self-hosting as the normal deployment model, an open-source core client, a free community-server path, or Server Pro licensing based on login users and managed devices. It is also relevant when teams want to build and audit the client rather than use a proprietary endpoint application.
+
+Those advantages do not remove the operational caveat: your team still needs to provision, secure, monitor, back up, and update the RustDesk server.
+
+## Evaluate RustDesk without committing the fleet
+
+Start with the free RustDesk community server for basic connectivity, then evaluate Server Pro if you need centralized governance. Use the same endpoints, networks, technician workflows, and acceptance criteria you use for Splashtop. Email [sales@rustdesk.com](mailto:sales@rustdesk.com) for current Server Pro evaluation terms, or review [RustDesk pricing](https://rustdesk.com/pricing).
diff --git a/v3/src/content/post/en/rustdesk-vs-teamviewer.md b/v3/src/content/post/en/rustdesk-vs-teamviewer.md
new file mode 100644
index 00000000..d653f798
--- /dev/null
+++ b/v3/src/content/post/en/rustdesk-vs-teamviewer.md
@@ -0,0 +1,183 @@
+---
+publishDate: 2026-07-06T00:00:00Z
+lang: en
+translationKey: rustdesk-vs-teamviewer
+draft: false
+title: 'RustDesk vs TeamViewer: The Self-Hosted Alternative'
+excerpt: 'RustDesk vs TeamViewer compared: features, OS support, security, licensing models, and honest trade-offs — self-hosting, open source, no per-channel pricing.'
+image: ~/assets/images/blog/rustdesk-vs-teamviewer-og.png
+category: Comparisons
+tags:
+ - RustDesk
+ - TeamViewer
+ - comparison
+author: RustDesk Team
+metadata:
+ description: 'RustDesk vs TeamViewer compared: features, OS support, security, licensing models, and honest pros/cons — self-hosting, open source, no per-channel pricing.'
+ keywords: 'RustDesk vs TeamViewer, TeamViewer comparison, TeamViewer vs RustDesk, RustDesk TeamViewer alternative comparison'
+---
+
+Teams comparing RustDesk and TeamViewer commonly focus on renewal cost, concurrency, hosting control, and operational maturity. Use current public terms or written quotes rather than private customer correspondence.
+
+That said, "cheaper and self-hosted" is not automatically "better." TeamViewer is a mature, deeply integrated commercial platform, and for some teams it is genuinely the right tool. This is a long, deliberately even-handed comparison: what each product is, how their features and platform support line up, how their security and licensing models differ, where TeamViewer still has the edge, and where — and why — teams move to RustDesk instead. Where we make a claim about TeamViewer, we cite it, and everything is dated because remote-access pricing and packaging change often.
+
+## Table of contents
+
+- [RustDesk and TeamViewer at a glance](#rustdesk-and-teamviewer-at-a-glance)
+- [Feature comparison](#feature-comparison)
+- [Operating system and platform support](#operating-system-and-platform-support)
+- [Security and identity](#security-and-identity)
+- [Licensing and pricing models](#licensing-and-pricing-models)
+- [Where TeamViewer still wins](#where-teamviewer-still-wins)
+- [Pros and cons](#pros-and-cons)
+- [Why teams switch to RustDesk anyway](#why-teams-switch-to-rustdesk-anyway)
+- [An honest caveat about self-hosting](#an-honest-caveat-about-self-hosting)
+- [Try RustDesk yourself](#try-rustdesk-yourself)
+- [Related reading](#related-reading)
+
+## RustDesk and TeamViewer at a glance
+
+**TeamViewer** is a commercial remote-access and remote-support platform from TeamViewer SE, in the market since 2005 and one of the most widely deployed tools of its kind. It is delivered as a managed, cloud-brokered SaaS: TeamViewer runs the connection infrastructure, you install a client, and sessions are brokered through TeamViewer's own routing network. It is closed-source, sold on annual subscriptions, and its higher tiers (branded **TeamViewer Tensor**) add enterprise features such as single sign-on, conditional access, mass deployment, and a broad catalog of integrations with tools like ServiceNow, Jira, and Microsoft Intune. ([TeamViewer Tensor / integrations](https://www.teamviewer.com/en/integrations/))
+
+**RustDesk** is an open-source remote desktop tool built around a different premise: you can run the whole thing yourself. The core client is open source under the AGPL, so it can be audited, built from source, and used with a free community server that runs indefinitely. The commercial offering, **RustDesk Server Pro**, is self-hosted — the ID/rendezvous server and the relay server run on your own machine or VPS, which means session metadata and connection brokering stay on infrastructure you control. RustDesk is licensed by login-user and by managed-device rather than by concurrent session, and it is designed to scale from a single technician up to large fleets. If your objection to TeamViewer is fundamentally about _control_ — over data, over cost, over the software itself — that is the axis on which these two products differ most.
+
+The rest of this article breaks the comparison down feature by feature.
+
+## Feature comparison
+
+The table below compares the day-to-day capabilities most teams ask about. A note on method: on the RustDesk side we deliberately mark only what we can confirm from first-party facts, and we leave a cell blank rather than assert a feature we have not verified for this article. A blank means "not claimed here," not "confirmed absent" — check the current RustDesk documentation for anything you depend on. On the TeamViewer side, every "Yes" is cited.
+
+| Capability | RustDesk | TeamViewer |
+| ----------------------------- | -------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| Remote control (core session) | Yes — this is the core client | Yes ([features](https://www.teamviewer.com/en-us/products/remote/features/)) |
+| Unattended access | Yes — devices are licensed as managed, always-controllable endpoints | Yes ([features](https://www.teamviewer.com/en-us/products/remote/features/)) |
+| Mobile access | Yes — Android and iOS clients | Yes, via mobile apps ([features](https://www.teamviewer.com/en-us/products/remote/features/)) |
+| File transfer | Not verified for this article | Yes ([features](https://www.teamviewer.com/en-us/products/remote/features/)) |
+| In-session chat | Not verified for this article | Yes, real-time chat; VoIP/video/chat are disabled for free users ([support](https://www.teamviewer.com/en-us/global/support/knowledge-base/teamviewer-remote/remote-control/remote-session-toolbar/)) |
+| Session recording | Not verified for this article | Yes ([features](https://www.teamviewer.com/en-us/products/remote/features/)) |
+| Remote printing | Not verified for this article | Yes ([features](https://www.teamviewer.com/en-us/products/remote/features/)) |
+| Multi-monitor support | Not verified for this article | Yes — 4K multi-monitor ([features](https://www.teamviewer.com/en-us/products/remote/features/)) |
+| Concurrent-session cap | Unlimited on standard plans; limited on Customized V2 | Capped by plan tier (see [licensing](#licensing-and-pricing-models)) |
+
+Two rows deserve extra attention because they are where the products diverge most in practice.
+
+First, **concurrent connections.** TeamViewer's commercial model meters simultaneous sessions by plan. RustDesk standard plans include unlimited concurrent connections, while Customized V2 limits and prices them separately.
+
+If concurrency limits are the specific pain that sent you looking, we go deeper on the mechanics in [Does RustDesk Limit Concurrent Connections?](/blog/rustdesk-concurrent-connections-limit).
+
+Second, the **feature-parity question.** TeamViewer's breadth here is real and is a legitimate reason some teams stay: session recording for compliance, remote printing, 4K multi-monitor, and a polished mobile experience are all mature. We are not going to overstate RustDesk's feature list to match it — the honest position is that RustDesk covers the core remote-control and unattended-access workflows that most support and admin teams live in every day, and you should trial it against your actual tasks rather than take any table's word for it. That is why we point evaluators to sales@rustdesk.com for a test license rather than a signed contract: see [See RustDesk in Action](/blog/see-rustdesk-in-action).
+
+## Operating system and platform support
+
+Both tools cover the major desktop and mobile platforms; the details differ at the edges, especially on Linux and embedded devices.
+
+| Platform | RustDesk | TeamViewer |
+| --------------- | ----------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| Windows | Yes | Yes, incl. Windows Server 2016/2019/2022 ([supported OS](https://www.teamviewer.com/en-us/global/support/knowledge-base/teamviewer-remote/download-and-installation/supported-operating-systems-for-teamviewer-remote/)) |
+| macOS | Yes | Yes, macOS 13 (Ventura) and later ([supported OS](https://www.teamviewer.com/en-us/global/support/knowledge-base/teamviewer-remote/download-and-installation/supported-operating-systems-for-teamviewer-remote/)) |
+| Linux | Yes | Yes, but via TeamViewer Classic with more limited functionality ([supported OS](https://www.teamviewer.com/en-us/global/support/knowledge-base/teamviewer-remote/download-and-installation/supported-operating-systems-for-teamviewer-remote/)) |
+| Android | Yes | Yes, Android 8+ ([supported OS](https://www.teamviewer.com/en-us/global/support/knowledge-base/teamviewer-remote/download-and-installation/supported-operating-systems-for-teamviewer-remote/)) |
+| iOS / iPadOS | Yes | Yes, iOS/iPadOS 15+ ([supported OS](https://www.teamviewer.com/en-us/global/support/knowledge-base/teamviewer-remote/download-and-installation/supported-operating-systems-for-teamviewer-remote/)) |
+| ChromeOS | Not verified for this article | Yes, but screen sharing only — full remote control not officially supported ([supported OS](https://www.teamviewer.com/en-us/global/support/knowledge-base/teamviewer-remote/download-and-installation/supported-operating-systems-for-teamviewer-remote/)) |
+| Raspberry Pi OS | Not verified for this article | Yes, via TeamViewer Classic ([supported OS](https://www.teamviewer.com/en-us/global/support/knowledge-base/teamviewer-remote/download-and-installation/supported-operating-systems-for-teamviewer-remote/)) |
+
+The headline is that both products run on Windows, macOS, Linux, Android, and iOS, so for the overwhelming majority of mixed-fleet support work either tool will reach the endpoints you need. TeamViewer casts a slightly wider net on the fringes (ChromeOS screen sharing, Raspberry Pi via its Classic build), with the caveat that some of that support is limited-functionality or restricted to the older Classic client. If exotic endpoints matter to you, verify the specific device against each vendor's current list before committing.
+
+## Security and identity
+
+This is where the two products embody genuinely different philosophies, so it is worth separating "security features" from "security model."
+
+**TeamViewer's security features** are strong and well-documented. Session traffic uses RSA 4096-bit public/private key exchange with AES 256-bit session encryption, the same category of cryptography used for HTTPS/TLS. It offers end-to-end encryption, so — per TeamViewer — neither its routing servers nor intermediary systems can decrypt end-to-end-encrypted session traffic. Account access can be protected with TOTP-based two-factor authentication, and the platform carries compliance certifications including SOC 2, ISO/IEC 27001, ISO 9001:2015, and HIPAA/HITECH, and states GDPR compliance. ([End-to-end encryption](https://www.teamviewer.com/en/solutions/use-cases/end-to-end-encryption-e2ee/), [security statement](https://www.teamviewer.com/en/global/support/knowledge-base/teamviewer-remote/security/security-statement/))
+
+It is only fair to note the counter-example on the incident side. In June 2024, TeamViewer disclosed that its **corporate IT network** was breached; the intrusion was attributed to APT29 (also tracked as Midnight Blizzard), the group linked to Russia's foreign intelligence service, using compromised employee credentials. TeamViewer stated the incident was contained to its internal corporate environment, that employee directory data and encrypted passwords were exposed, and that there was no evidence the attacker reached the product environment or customer data. ([BleepingComputer](https://www.bleepingcomputer.com/news/security/teamviewers-corporate-network-was-breached-in-alleged-apt-hack/), [TeamViewer bulletin TV-2024-1005](https://www.teamviewer.com/en-us/resources/trust-center/security-bulletins/tv-2024-1005/)) No vendor is immune to this class of attack; we mention it because "the vendor's own network is a target" is precisely the risk profile that a self-hosted model changes.
+
+**RustDesk's security model** starts from a different place. The core client is open source under the AGPL, so the code can be independently audited and built from source. RustDesk Server Pro is self-hosted: you operate the ID/rendezvous, relay, console, and stored deployment data. Direct sessions still flow between endpoints. Open source also makes defects public, so review the [latest releases](https://github.com/rustdesk/rustdesk/releases) and current vulnerability records rather than assuming self-hosting eliminates software risk.
+
+On **identity**, one clarification that matters for planning. RustDesk supports LDAP/Active Directory and SSO via OIDC, and this is available **from the Basic plan and up** — it is not gated to only the top tiers, and it is not present on every paid arrangement below Basic either, so map it to the specific plan you intend to buy. Full setup details are in [RustDesk LDAP & Active Directory: Setup Guide](/blog/rustdesk-active-directory-ldap-sso). For per-user access control, RustDesk provides a self-hosted web console, device groups, and a shared address book, plus a custom-branded client generator so the app your users install carries your name rather than the vendor's.
+
+If keeping session data on infrastructure you control is the whole point of the exercise, the dedicated discussion is in [Remote Desktop & Data Sovereignty](/blog/remote-desktop-data-sovereignty-gdpr) and [Why Self-Host Your Remote Desktop Software](/blog/why-self-host-remote-desktop-software).
+
+## Licensing and pricing models
+
+Pricing is the single most volatile part of any remote-access comparison, so we will describe **models** in detail and treat **numbers** as dated snapshots, not permanent facts. We also, as a matter of policy, never quote a hard RustDesk price in prose — the current figure lives at [rustdesk.com/pricing](https://rustdesk.com/pricing) so it is always accurate.
+
+**TeamViewer's model** is subscription-based and organized around named tiers plus concurrent-session limits. Packaging and prices vary by region and term, so use TeamViewer's current pricing page and your written quote rather than historical third-party figures or private customer invoices.
+
+**RustDesk's model** is different in two ways. First, commercial plans count **login users plus managed devices**. Standard plans include unlimited concurrent connections; Customized V2 has a defined concurrency allowance. Upgrades can be prorated, so confirm the current mid-term terms on the pricing page. Second, the community server has no license fee, while Server Pro is the commercial option for centralized features. RustDesk does not publish a fixed self-serve Server Pro trial; ask for current evaluation terms before planning a proof of concept. Payment mechanics are covered in [RustDesk Pro Pricing: Cost & How to Pay](/blog/rustdesk-pro-license-cost-how-to-pay).
+
+If your starting point is TeamViewer's cost, see [TeamViewer Too Expensive? Your Real Options in 2026](/blog/teamviewer-too-expensive-alternatives) and compare current quotes.
+
+There is also a free-tier wrinkle. TeamViewer's free tier is for personal, non-commercial use, and suspected commercial use can restrict sessions. TeamViewer does not publish a threshold formula users can rely on. A genuine false positive should go through the official reset process; actual business use requires commercial terms. ([TeamViewer: commercial use suspected](https://www.teamviewer.com/en-us/global/support/knowledge-base/teamviewer-classic/licensing/personal-use/commercial-use-suspected/)) See [TeamViewer Commercial Use Detected](/blog/teamviewer-commercial-use-detected) for the focused workflow.
+
+## Where TeamViewer still wins
+
+An honest comparison has to include the cases where the incumbent is the better choice. TeamViewer is not the default for millions of installs by accident.
+
+- **Maturity and polish.** Two decades of development show up in the small things — connection reliability across bad networks, 4K multi-monitor handling, mobile apps, and a UI that non-technical end users navigate without hand-holding.
+- **A deep integration ecosystem.** If your service desk lives in ServiceNow, Jira, or Microsoft Intune — or you want RMM, SSO, and SIEM hooks wired together out of the box — TeamViewer (especially Tensor) has a large catalog of native integrations that would otherwise be build-it-yourself work. ([TeamViewer integrations](https://www.teamviewer.com/en/integrations/))
+- **Zero server maintenance.** Because TeamViewer runs the brokering infrastructure, there is no server for you to provision, patch, secure, monitor, or scale. For a small team without dedicated ops capacity, "someone else runs it" is a real, ongoing benefit, not just a convenience.
+- **Compliance paperwork ready to go.** SOC 2, ISO/IEC 27001, HIPAA/HITECH and similar certifications are already in place, which can shorten a procurement or audit conversation.
+- **Managed reliability.** A commercial SaaS with an SLA and 24/7 support tiers is a different operational proposition from software you host yourself and are on the hook for at 2 a.m.
+
+If those points describe your situation more than the cost-and-control complaints at the top of this article, TeamViewer may well be the right answer, and there is no shame in that conclusion.
+
+## Pros and cons
+
+**RustDesk**
+
+_Pros_
+
+- Open-source (AGPL) core client — auditable, buildable from source, free community server that runs indefinitely
+- Self-hosted Server Pro: ID/rendezvous and relay servers run on your own machine or VPS, keeping session brokering inside your perimeter
+- Unlimited concurrent connections on standard plans; limited on Customized V2
+- Licensed by login-user + managed-device, with prorated upgrades any time
+- Large-fleet planning guidance is available for teams evaluating bigger deployments
+- Self-hosted web console, device groups, shared address book, and a custom-branded client generator
+- LDAP/Active Directory and OIDC SSO from the Basic plan and up
+
+_Cons_
+
+- Self-hosting means **you** run, patch, secure, and scale the server (see the caveat below)
+- Smaller third-party integration catalog than TeamViewer's enterprise ecosystem
+- Some conveniences a mature commercial suite bundles may need verification against your specific workflow before you rely on them
+
+**TeamViewer**
+
+_Pros_
+
+- Mature, polished, and widely trusted, with strong cross-platform reach
+- Robust security features: AES-256 session encryption, RSA-4096 key exchange, optional end-to-end encryption, TOTP 2FA, and broad compliance certifications
+- Large native integration ecosystem (ServiceNow, Jira, Intune, RMM, SSO/SIEM via Tensor)
+- Fully managed SaaS — no server for you to maintain
+
+_Cons_
+
+- Closed-source; you trust the vendor's infrastructure and their handling of your session metadata
+- Concurrent sessions are metered by plan tier
+- Recurring annual subscription cost that teams repeatedly tell us feels disproportionate to simple needs
+- Free tier is personal-use only and can flag legitimate users for "commercial use," interrupting sessions
+- Its corporate network was breached by APT29 in June 2024 (contained to internal IT, per TeamViewer) — a reminder that a centralized vendor is itself a high-value target
+
+## Why teams switch to RustDesk anyway
+
+Everything above is the neutral part. The following section explains which buyer requirements align with RustDesk's model.
+
+**They want a different concurrency model.** RustDesk standard plans include unlimited concurrent connections, while Customized V2 licenses a defined allowance. All plans also require sufficient login-user and managed-device capacity. See the [concurrency FAQ](/blog/rustdesk-concurrent-connections-limit).
+
+**They want control over the server-side data path.** Running the ID/rendezvous and relay services lets a team choose where those services and stored metadata reside. Direct session traffic still flows between endpoints, and self-hosting alone does not establish GDPR compliance. See [Why Self-Host](/blog/why-self-host-remote-desktop-software), [Self-Hosted vs Cloud](/blog/rustdesk-self-hosted-vs-cloud-saas-option), and [Remote Desktop & Data Sovereignty](/blog/remote-desktop-data-sovereignty-gdpr).
+
+**They want to read the code.** Open source under the AGPL means the client can be audited and built from source rather than trusted blindly. For security-conscious buyers, "we can inspect it" is a different assurance level from "the vendor says it's fine."
+
+**They need a different scaling model.** RustDesk sizes commercial plans by login users and managed devices, with plan-specific concurrency terms, and publishes [large-fleet planning guidance](/blog/rustdesk-scale-50000-200000-devices). Rates and allowances can change, so model growth against the current pricing matrix.
+
+**They are MSPs or enterprises who want one brandable, self-hosted tool.** For managed service providers, the custom-branded client generator, device groups, and shared address book turn RustDesk into a white-label support platform — see [RustDesk for MSPs](/blog/rustdesk-for-msps). For larger organizations that need AD/LDAP and room to grow, see [RustDesk for Enterprise](/blog/rustdesk-for-enterprise).
+
+If infrastructure control is not a priority, TeamViewer may remain the better fit. See [RustDesk vs AnyDesk](/blog/rustdesk-vs-anydesk), [RustDesk vs ScreenConnect](/blog/rustdesk-vs-screenconnect), and [The Best Self-Hosted TeamViewer Alternative](/blog/self-hosted-teamviewer-alternative).
+
+## An honest caveat about self-hosting
+
+We would rather you hear this from us than discover it later. Self-hosting RustDesk means you own the server. You provision it, you patch it, you secure it, you monitor it, and you scale it. That is the trade you make in exchange for control and the absence of a concurrency meter — it is real work, and it is emphatically **not** the zero-maintenance, someone-else-runs-it experience that a managed SaaS like TeamViewer provides. If your team has no appetite or capacity to run a small piece of infrastructure, that fact should weigh heavily in your decision, and one of TeamViewer's genuine advantages is that it removes this burden entirely. Choose with eyes open.
+
+## Try RustDesk yourself
+
+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.
diff --git a/v3/src/content/post/en/rustdesk-vs-vnc.md b/v3/src/content/post/en/rustdesk-vs-vnc.md
new file mode 100644
index 00000000..843a362f
--- /dev/null
+++ b/v3/src/content/post/en/rustdesk-vs-vnc.md
@@ -0,0 +1,100 @@
+---
+publishDate: 2026-07-07T00:00:00Z
+lang: en
+translationKey: rustdesk-vs-vnc
+draft: false
+title: 'RustDesk vs VNC: NAT Traversal, Codecs, Encryption'
+excerpt: "RustDesk vs VNC compared honestly: NAT traversal without port-forwarding, modern codecs, built-in encryption, and where VNC's simplicity still wins."
+image: ~/assets/images/blog/rustdesk-vs-vnc-og.png
+category: Comparisons
+tags:
+ - RustDesk
+ - VNC
+ - comparison
+ - open-source
+author: RustDesk Team
+faq:
+ - question: 'Is RustDesk based on VNC?'
+ answer: 'No. VNC uses the RFB (Remote Framebuffer) protocol to send pixel updates. RustDesk is a separate, open-source (AGPL) application with its own rendezvous/relay architecture, modern video codecs, and end-to-end encryption. It is not a VNC client or server.'
+ - question: 'Does VNC work over the internet without port-forwarding?'
+ answer: "Not by itself. The base VNC/RFB protocol has no NAT traversal, so internet use typically requires port-forwarding TCP 5900, a VPN, or an SSH tunnel — unless you use a vendor's cloud brokering service. RustDesk brokers the connection through an ID server and relay, so it crosses NAT without any of that."
+ - question: 'Is VNC encrypted?'
+ answer: 'It varies by implementation. RealVNC offers AES encryption in its commercial product, while TightVNC transmits picture data without encryption and is meant to be tunneled through SSH. RustDesk applies end-to-end encryption (NaCl) by default across all connections.'
+ - question: 'Is RustDesk or VNC better for a home lab on a LAN?'
+ answer: 'On a trusted LAN, VNC is dead-simple, standardized, and widely available on almost every OS and even Raspberry Pi. RustDesk adds NAT traversal, modern codecs, and default encryption that matter more once you leave the LAN or need mixed-OS remote access.'
+metadata:
+ description: "RustDesk vs VNC compared honestly: NAT traversal, modern codecs, built-in encryption, self-hosting, and where VNC's simplicity and ubiquity still win."
+ keywords: 'RustDesk vs VNC, RustDesk vs RealVNC, VNC NAT traversal, VNC encryption comparison'
+---
+
+VNC is one of the oldest and most widely deployed ways to control another computer. It is a genuine open standard, it runs almost everywhere, and for a LAN it is hard to beat on simplicity. RustDesk targets the same core task but was designed for a world of NAT, firewalls, and mixed operating systems. The differences come down to how each moves across a network — and how much you have to bolt on to make it safe.
+
+This comparison sticks to durable, verifiable facts rather than benchmarks that depend on your hardware and link.
+
+## What VNC actually is
+
+"VNC" is not one program but a family of implementations — RealVNC, TightVNC, TigerVNC, UltraVNC and others — that speak the **RFB (Remote Framebuffer) protocol** ([Wikipedia]()). RFB is fundamentally **pixel-based**: the server ships framebuffer updates to the viewer. That design is beautifully simple and portable, and it is why VNC exists on everything from enterprise servers to a Raspberry Pi.
+
+The licensing is mixed. TigerVNC is distributed under the GNU GPL and TightVNC is a community-driven open fork, while RealVNC's viewer is a proprietary, commercially maintained product. So "VNC is open source" is true of _some_ implementations, not all of them.
+
+## What RustDesk is
+
+RustDesk is a **single open-source application (AGPL)** with its own architecture. Clients connect outward to an ID/rendezvous server, which brokers a peer-to-peer or relayed session. Per the [RustDesk documentation](https://rustdesk.com/docs/en/), traffic is end-to-end encrypted (built on NaCl), and video uses modern codecs — VP8, VP9, and AV1 in software, with H.264/H.265 hardware paths — rather than raw pixel rectangles. You can run every client against the public infrastructure, your own self-hosted server, or a rendezvous/relay you write yourself.
+
+## The internet problem: NAT traversal
+
+This is the sharpest divide. The base VNC protocol has **no NAT traversal**. As the [VNC documentation notes](https://en.wikipedia.org/wiki/Virtual_Network_Computing), to reach a machine over the internet "a user must open this port in the local firewall and configure port forwarding to forward TCP Port 5900 ... if behind a network address translation (NAT) router." The common workaround is to "tunnel VNC through Secure Shell (SSH)," which also adds the encryption that plain VNC lacks. Some commercial VNC products (like RealVNC's cloud service) add their own brokering to avoid this, but that is a vendor feature layered on top, not part of the protocol.
+
+RustDesk was built the other way around. Because endpoint clients connect **outbound** to a rendezvous server and fall back to a relay when a direct path fails, RustDesk **crosses NAT and firewalls without per-endpoint port-forwarding, a VPN, or an SSH tunnel**. The endpoints do not need inbound listening ports, but a self-hosted ID/rendezvous and relay server must accept inbound traffic on its documented service ports. That is the same NAT-traversal story that makes it a practical [Chrome Remote Desktop or free-tool alternative](/blog/best-free-remote-desktop-software) for remote and mixed-OS access.
+
+## Encryption: default vs it-depends
+
+With VNC, encryption is an implementation detail. RealVNC offers AES encryption in its commercial package; by contrast, per the [VNC documentation](https://en.wikipedia.org/wiki/Virtual_Network_Computing), "TightVNC is not secure as picture data is transmitted without encryption" and "should be tunneled through an SSH connection." So the security of a VNC session depends entirely on which server you chose and how you configured it.
+
+RustDesk applies **end-to-end encryption by default** on every connection, self-hosted or not, with no SSH tunnel to remember to set up.
+
+## RustDesk vs VNC at a glance
+
+| | RustDesk | VNC (RFB) |
+| --------------------- | -------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------- |
+| What it is | One AGPL app + rendezvous/relay | RFB protocol, many implementations |
+| Source code | Open source (AGPL) | Mixed: GPL/open (TigerVNC, TightVNC), proprietary (RealVNC) |
+| Cross-platform | Windows, macOS, Linux, Android, iOS | Very broad, including Raspberry Pi |
+| NAT traversal | Built in (rendezvous + relay) | None in base protocol — [needs port-forwarding/VPN/SSH](https://en.wikipedia.org/wiki/Virtual_Network_Computing) |
+| Encryption | End-to-end (NaCl) by default ([docs](https://rustdesk.com/docs/en/)) | Varies: AES (RealVNC) to none (TightVNC) |
+| Video transport | Modern codecs (VP8/VP9/AV1, H.264/H.265) | Pixel-based RFB encodings |
+| Self-hosting | Yes — your own ID/relay server | Yes for open implementations (no built-in broker) |
+| Setup on LAN | Simple | Very simple |
+| Standardized protocol | RustDesk-specific | Open, long-standing RFB standard |
+
+Confirm current RustDesk plan details at [rustdesk.com/pricing](https://rustdesk.com/pricing).
+
+## Where VNC still wins — honestly
+
+VNC has survived for decades for good reasons, and they deserve to be stated plainly:
+
+- **Dead-simple on a LAN.** Install a server, point a viewer at an IP, done. For a trusted local network there is very little ceremony.
+- **Ubiquity and a real standard.** RFB is an open, published protocol with interoperable clients and servers across nearly every platform, including embedded devices and the Raspberry Pi. Any RFB viewer talks to any RFB server.
+- **Fully-FOSS options exist.** If you want a completely open-source server today, TigerVNC (GPL) and TightVNC are already there, with no relay infrastructure to run.
+- **No dependency on a broker.** A LAN-only VNC setup has no rendezvous server in the path at all — appealing for air-gapped or tightly segmented networks.
+
+If your use case is "control the Linux box on the next rack" or "reach a Pi on my home network," VNC may be all you ever need, and RustDesk's extra machinery buys you little.
+
+## Where RustDesk pulls ahead
+
+RustDesk's design advantages appear the moment you leave the LAN or need consistency across teams and platforms:
+
+- **Internet reach without plumbing.** NAT traversal and relay fallback mean no port-forwarding, VPN, or SSH tunnel per endpoint.
+- **Encryption you don't have to configure.** End-to-end by default, not an implementation you have to vet.
+- **Modern codecs.** VP8/VP9/AV1 and hardware H.264/H.265 tend to hold up better over constrained or high-latency links than raw pixel encodings.
+- **One auditable app and one self-hosted server.** The AGPL client plus a self-hosted ID/relay keeps both the code and your session data on infrastructure you control — the heart of the [open-source remote desktop](/blog/open-source-remote-desktop-software) argument.
+
+The honest caveat: self-hosting RustDesk means **someone runs the server** — provisioning, TLS, ports, and patching over time. A LAN-only VNC setup skips that entirely. That is the real trade.
+
+## So which should you use?
+
+For a trusted LAN, an air-gapped segment, or a Raspberry Pi, VNC's simplicity and standardization are genuinely hard to beat. Once you need to cross the internet safely, want encryption on by default, or have to support a mix of Windows, macOS, Linux, Android, and iOS from one tool, RustDesk's architecture does more of the work for you. And if you are already weighing native Windows tooling, our [RustDesk vs RDP](/blog/rustdesk-vs-rdp) comparison covers that fork too.
+
+## 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).
diff --git a/v3/src/content/post/en/rustdesk-web-console-custom-client-generator-port-21114.md b/v3/src/content/post/en/rustdesk-web-console-custom-client-generator-port-21114.md
new file mode 100644
index 00000000..991c82ce
--- /dev/null
+++ b/v3/src/content/post/en/rustdesk-web-console-custom-client-generator-port-21114.md
@@ -0,0 +1,59 @@
+---
+publishDate: 2026-07-06T00:00:00Z
+lang: en
+translationKey: rustdesk-web-console-custom-client-generator-port-21114
+draft: false
+title: 'RustDesk Web Console Access: Port 21114 and HTTPS Basics'
+excerpt: "Can't reach the RustDesk Pro web console or Custom Client Generator on port 21114? Here are the URLs, TLS notes, and first-login checks."
+image: ~/assets/images/blog/rustdesk-web-console-custom-client-generator-port-21114-og.png
+category: Deployment
+tags:
+ - RustDesk
+ - deployment
+author: RustDesk Team
+faq:
+ - question: 'How do I reach the RustDesk Server Pro Web Console?'
+ answer: 'RustDesk Server Pro serves plain HTTP on port 21114, but you must not send credentials over that connection on a public or untrusted network. Configure HTTPS first. If TLS is not yet available, complete the first login only through localhost, an SSH tunnel, or a trusted private network, then rotate the initial credentials. The Custom Client Generator requires Basic or a higher plan.'
+ - question: 'How do I put the RustDesk Web Console behind HTTPS with a valid certificate?'
+ answer: 'Port 21114 serves plain HTTP and does not provision a certificate for a bare domain. For production HTTPS, put the console behind a supported reverse proxy such as Nginx or IIS, install a valid certificate, expose port 443, and update the client API address to the HTTPS endpoint.'
+ - question: "Why can't I reach the console on port 21114?"
+ answer: 'If none of the URLs respond, the container is usually running but the port is closed. Confirm the Pro container is up and that TCP 21114 is open end to end — in the host firewall and in any cloud security group or NAT/forwarding rule in front of the server. A blocked or unforwarded 21114 is the typical cause.'
+ - question: 'Which ports does RustDesk Server Pro need open besides 21114?'
+ answer: 'Besides the Web Console on 21114 (or 443 behind a reverse proxy), Server Pro also needs its standard ID/rendezvous and relay ports open for clients to connect. Exact port numbers change between releases, so check the current RustDesk docs for the full list before locking down your firewall.'
+ - question: 'I changed the admin password and locked myself out — how do I reset it?'
+ answer: 'Admin password recovery depends on how your Server Pro instance is deployed and stored, and the procedure can change between releases. Rather than following an outdated screenshot, check the current RustDesk Server Pro docs for the supported reset path, or contact RustDesk support with non-sensitive deployment details.'
+
+metadata:
+ description: "Can't reach the RustDesk Pro web console or Custom Client Generator on port 21114? Here are the URLs, TLS notes, and first-login checks."
+ keywords: 'RustDesk web console port 21114, RustDesk Custom Client Generator, RustDesk Pro web console login, RustDesk self-hosted admin console, access RustDesk console port 21114, RustDesk reverse proxy'
+---
+
+If you have a RustDesk Server Pro license but cannot reach the Web Console, first check the URL, scheme, firewall, and proxy configuration. The console is available on all Pro plans, while the Custom Client Generator requires **Basic or a higher plan**.
+
+## The short answer
+
+Port 21114 serves plain HTTP and can be used to confirm that the console is reachable, but **do not enter credentials over plain HTTP on a public or untrusted network.** Configure `https://[your_domain]` with a certificate and reverse proxy, normally on port 443, before signing in. If HTTPS is not ready, complete the first login only through localhost, an SSH tunnel, or a trusted private network. On Basic and higher plans, the Custom Client Generator appears inside the console.
+
+## In detail
+
+Port 21114 serves HTTP by default; it does not automatically provision a certificate for a bare domain. For production HTTPS, put the console behind a supported reverse proxy such as Nginx or IIS, install a valid certificate, expose port 443, and configure the client API address accordingly.
+
+If none of the three addresses respond, the container is reachable but the port likely isn't. Confirm the Pro container is running, and make sure TCP 21114 is open end to end - both in the host firewall and in any cloud security group or NAT rule in front of the server. A blocked or unforwarded 21114 is the typical culprit behind "port not available."
+
+Initial admin credentials should be treated as temporary, but changing them after an exposed HTTP login does not undo credential or session interception. First establish HTTPS or one of the protected bootstrap paths above; then sign in, change the password immediately, and move on to generating clients.
+
+On Basic and higher plans, the Custom Client Generator lets you produce branded, pre-configured client builds so end users do not need to enter server settings manually. Individual includes the Web Console but not the generator.
+
+## Who asks this
+
+This comes up most often with IT admins and [MSPs](/blog/rustdesk-for-msps) standing up a self-hosted RustDesk Server Pro for the first time. Two separate checks are required: confirm that the console is reachable, then confirm that the selected plan includes the generator.
+
+## Related questions
+
+- [How do I open or forward port 21114 on a cloud-hosted RustDesk server?](https://rustdesk.com/docs)
+- [How do I put the RustDesk Web Console behind HTTPS with a valid certificate?](https://rustdesk.com/docs)
+- [How does the Custom Client Generator brand and pre-configure a client build?](/blog/rustdesk-for-msps)
+- [I changed the admin password and locked myself out — how do I reset it?](https://rustdesk.com/docs)
+- [Which ports does RustDesk Server Pro need open besides 21114?](https://rustdesk.com/docs)
+
+Still stuck? Confirm the server process is running and that either TCP 21114 is reachable through a protected bootstrap path or your configured TCP 443 reverse proxy is reachable over HTTPS. Never submit credentials to port 21114 across the public internet; rotate the initial admin credentials after the protected first login.
diff --git a/v3/src/content/post/en/see-rustdesk-in-action.md b/v3/src/content/post/en/see-rustdesk-in-action.md
new file mode 100644
index 00000000..1b444d02
--- /dev/null
+++ b/v3/src/content/post/en/see-rustdesk-in-action.md
@@ -0,0 +1,38 @@
+---
+publishDate: 2026-07-06T00:00:00Z
+lang: en
+translationKey: see-rustdesk-in-action
+draft: false
+title: 'See RustDesk in Action: Demo, Free Server & Evaluation'
+excerpt: 'Want to see RustDesk before you commit? Watch the demo video, self-host the free open-source server, or confirm the current Server Pro evaluation path.'
+image: ~/assets/images/blog/see-rustdesk-in-action-og.png
+category: Guides
+tags:
+ - RustDesk
+author: RustDesk Team
+metadata:
+ description: 'Three ways to see RustDesk in action: watch the demo video, self-host the free open-source server, and confirm the current Server Pro evaluation path.'
+ keywords: 'RustDesk demo, see RustDesk in action, evaluate RustDesk, RustDesk Pro demo, try RustDesk, RustDesk evaluation'
+---
+
+Want to see RustDesk before you commit? You can evaluate it on your own terms: start with the demo, stand up the free server, or confirm the current Server Pro evaluation path when you need paid features.
+
+Here are the three ways to see it in action.
+
+## 1. Watch the demo video
+
+If you just want a quick feel for how RustDesk looks and works, start with the video. The [RustDesk YouTube channel](https://www.youtube.com/@rustdesk) has videos covering the product and the Pro feature set — the [web console](/blog/rustdesk-web-console-custom-client-generator-port-21114), custom client generator, address book, and access control — so you can see it running before you install anything.
+
+## 2. Self-host the free, open-source server
+
+Ready to get hands-on? RustDesk's core is open source, so you can stand up the free community server today and connect your own machines — no license, no time limit, no cost. It's the most honest kind of demo there is: the real software, on your own infrastructure, doing exactly what you'll rely on in production. Audit the code while you're at it.
+
+## 3. Evaluate the Pro features
+
+When you're ready to evaluate the paid features — the self-hosted web console, branded custom clients, user management, and [LDAP/Active Directory](/blog/rustdesk-active-directory-ldap-sso) — check the current evaluation terms on [rustdesk.com/pricing](https://rustdesk.com/pricing) or email [sales@rustdesk.com](mailto:sales@rustdesk.com). Spin up the server, point a few devices at it, and decide for yourself.
+
+## Have questions? Talk to the team directly
+
+If you still have questions about pricing, licensing, deployment, or feature fit, use the current pricing page, docs, and contact channels to confirm the details that matter to your evaluation.
+
+So the evaluation path is simple: **watch the video for the tour, self-host the free server to test hands-on, and confirm the current Pro evaluation path when you need the full feature set.**
diff --git a/v3/src/content/post/en/self-host-rustdesk-server-hardware-at-scale.md b/v3/src/content/post/en/self-host-rustdesk-server-hardware-at-scale.md
new file mode 100644
index 00000000..49c117f3
--- /dev/null
+++ b/v3/src/content/post/en/self-host-rustdesk-server-hardware-at-scale.md
@@ -0,0 +1,56 @@
+---
+publishDate: 2026-07-06T00:00:00Z
+lang: en
+translationKey: self-host-rustdesk-server-hardware-at-scale
+draft: false
+title: 'RustDesk Self-Host Hardware for Large Fleets'
+excerpt: 'Planning to self-host RustDesk for thousands of devices? Size for concurrent sessions, relay traffic, storage, and OS limits rather than inventory alone.'
+image: ~/assets/images/blog/self-host-rustdesk-server-hardware-at-scale-og.png
+category: Deployment
+tags:
+ - RustDesk
+ - deployment
+ - self-hosting
+author: RustDesk Team
+faq:
+ - question: 'How much hardware do I need to self-host RustDesk for a large fleet?'
+ answer: 'RustDesk Server Pro requirements depend more on concurrent sessions, relay traffic, storage, and operating-system limits than on raw device inventory. Many deployments can start with an SSD-backed host and validate whether they actually need more RAM, CPU, bandwidth, or an external database.'
+ - question: 'Does RustDesk Server Pro need PostgreSQL or MySQL, or is SQLite enough?'
+ answer: 'SQLite is enough to start for many deployments, including fleets in the thousands, and keeps the setup simple. Move to an external database such as PostgreSQL or MySQL only when your workload, operating model, or observability needs justify it. SSD storage keeps the database and its logging responsive under load.'
+ - question: 'What OS socket and file-descriptor limits should I set for a large deployment?'
+ answer: 'Concurrent TCP/WebSocket connections and relayed streams stress operating-system socket and file-descriptor limits more than device count does. Raise your ulimit and file-descriptor ceilings and give the host adequate network throughput rather than piling on RAM you will not use.'
+ - question: 'How much RAM and CPU does a self-hosted RustDesk server use per session?'
+ answer: 'Load is driven by concurrent active sessions and relay traffic, not by the number of registered devices. Size CPU and bandwidth for your peak simultaneous sessions and any heavy relay reliance; RAM is rarely the bottleneck.'
+
+metadata:
+ description: 'Planning to self-host RustDesk for thousands of devices? Size for concurrent sessions, relay traffic, storage, and OS limits rather than inventory alone.'
+ keywords: 'self-host RustDesk server hardware, RustDesk Server Pro requirements, RustDesk hardware requirements at scale, RustDesk SQLite vs database, RustDesk self-hosted performance, RustDesk server sizing'
+---
+
+Self-hosting RustDesk at scale is often less hardware-hungry than IT teams expect. The important thing is sizing for the traffic and operating pattern you actually have, not guessing from inventory alone.
+
+## The short answer
+
+RustDesk Server Pro requirements vary by workload. What actually stresses the server is active TCP/WebSocket connections, relay traffic, storage performance, and operating-system socket and file-descriptor limits — not the size of your device inventory by itself.
+
+## In detail
+
+The key insight for capacity planning is that the number of _registered_ devices is not the same thing as the number of active, relayed, or simultaneously managed sessions. A large inventory does not, by itself, force you into a big box.
+
+The real load comes from concurrent activity. Each active remote session opens TCP/WebSocket connections, and any session that can't connect peer-to-peer falls back to the relay, which passes traffic through your server. The more simultaneous sessions and relayed streams you run, the more the CPU, network, and — critically — the OS socket and file-descriptor limits matter. When you tune your server, raise those `ulimit`/file-descriptor ceilings and give the box adequate network throughput rather than piling on RAM you won't use.
+
+On the database question, teams often assume a fleet in the thousands automatically demands PostgreSQL or MySQL. Many deployments do not start there. SQLite can keep the deployment simple at first; move to an external database only when your workload, operating model, or observability needs justify it. SSD storage matters because it keeps the database and its logging responsive under load.
+
+The practical takeaway: size for concurrency and network, not headcount. If you expect an unusually high ratio of simultaneous active sessions, or heavy reliance on relay because peer-to-peer is blocked in your network, plan for more CPU and bandwidth and confirm your OS limits are raised. For larger fleets or unusual edge cases, validate your sizing assumptions with RustDesk at [rustdesk.com](https://rustdesk.com).
+
+## Who asks this
+
+This comes from IT admins, [MSPs](/blog/rustdesk-for-msps), and enterprises standing up self-hosted RustDesk Server Pro for large fleets — frequently teams migrating off TeamViewer or AnyDesk who have just become Pro customers and are sizing infrastructure before rollout. It's a recurring question from organizations managing thousands to tens of thousands of endpoints who need to right-size a server without guesswork.
+
+## Related questions
+
+- [Can one RustDesk server handle 10,000+ devices, or do I need to cluster?](/blog/rustdesk-scale-50000-200000-devices)
+- [Can I deploy RustDesk Server Pro without Docker?](/blog/rustdesk-server-pro-without-docker)
+- [Is there a managed cloud option, or is Server Pro self-hosted only?](/blog/rustdesk-self-hosted-vs-cloud-saas-option)
+
+Planning a large self-hosted rollout? Size for concurrent sessions and relay traffic first, then scale RAM, storage, bandwidth, and database complexity only where your real usage demands it.
diff --git a/v3/src/content/post/en/self-hosted-teamviewer-alternative.md b/v3/src/content/post/en/self-hosted-teamviewer-alternative.md
new file mode 100644
index 00000000..7aaa3635
--- /dev/null
+++ b/v3/src/content/post/en/self-hosted-teamviewer-alternative.md
@@ -0,0 +1,99 @@
+---
+publishDate: 2026-07-06T00:00:00Z
+lang: en
+translationKey: self-hosted-teamviewer-alternative
+draft: false
+title: 'The Best Self-Hosted TeamViewer Alternative'
+excerpt: 'Why teams are leaving TeamViewer for a self-hosted, open-source alternative they actually control — and how RustDesk fits.'
+image: ~/assets/images/blog/self-hosted-teamviewer-alternative-og.png
+category: Alternatives
+tags:
+ - RustDesk
+ - TeamViewer
+ - alternative
+ - self-hosting
+author: RustDesk Team
+metadata:
+ description: 'Looking for a self-hosted TeamViewer alternative? RustDesk is open-source, runs on your servers, and has no per-channel cloud subscription. See how it compares.'
+ keywords: 'self-hosted TeamViewer alternative, TeamViewer replacement, open source TeamViewer alternative'
+---
+
+The search for a **self-hosted TeamViewer alternative** usually starts the same way: a renewal quote no longer matches the workflows you use, and the product still routes your sessions through infrastructure you do not control. Cost and control are the two reasons teams start looking in the first place.
+
+If you're one of them, this page is for you. Below is an honest look at why teams leave TeamViewer, how a self-hosted, open-source model changes the equation, and where RustDesk fits (including where it doesn't).
+
+## Why teams leave TeamViewer
+
+Two decision factors show up repeatedly.
+
+**Cost.** Compare the current renewal quote with alternatives using the same user, device, concurrency, feature, and support requirements.
+
+**Control.** With a cloud-only tool, your session traffic and your device list live on a vendor's infrastructure. For a growing number of teams — especially in healthcare, the public sector, and anywhere [GDPR](/blog/remote-desktop-data-sovereignty-gdpr) applies — choosing where the server-side data and relay layer run is a hard requirement, not a preference.
+
+A **self-hosted TeamViewer alternative** answers both: you own the infrastructure, and your licensing stops being a moving cloud subscription.
+
+## The core difference: you host it, you own it
+
+RustDesk Server Pro is [self-hosted by design](/blog/why-self-host-remote-desktop-software). 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.
+
+Underneath, 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 the client does on your machines, build it yourself, and run the free community server indefinitely. That's a different trust model than a closed cloud product: you don't have to take our word for what the software does, because you can look.
+
+It's also the reason security incidents in this category — such as [AnyDesk's 2024 security incident](https://www.infosecurity-magazine.com/news/anydesk-hit-cyberattack-customer/), or 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) — land differently when the software is auditable and the servers are yours. (See the caveat section: self-hosting shifts responsibility to you, too.)
+
+## RustDesk vs TeamViewer at a glance
+
+| | TeamViewer (cloud) | RustDesk (self-hosted) |
+| --------------------------------------------------------------------- | --------------------------- | --------------------------------------------------------------------------------- |
+| Where sessions run | Vendor cloud | Your server (on-prem or your VPS) |
+| Source code | Closed | Open source (AGPL) core |
+| Licensing model | Per-seat cloud subscription | [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-side data location | Vendor-controlled | Chosen and operated by you; endpoint routes still matter |
+| Try before you buy | Sales-led | Free server today, or Pro trial on request |
+
+_Competitor details vary by plan — confirm current TeamViewer terms with the vendor. [See RustDesk pricing](https://rustdesk.com/pricing)._
+
+## Predictable licensing, no per-channel tax
+
+RustDesk licenses per login-user plus per managed-device. **Standard plans include unlimited concurrent connections; Customized V2 has a defined allowance.** Mid-term upgrades may be prorated under current terms. Model all three counts against the current pricing page.
+
+That maps cleanly onto login-users and managed-devices whether you are a small support team or a larger IT operation. It also scales well beyond a starter deployment: [large-fleet planning](/blog/rustdesk-scale-50000-200000-devices) starts around 50,000 managed devices today, with larger estates requiring validation around caching, database tuning, and rollout design.
+
+## Your data stays where you put it
+
+Because you host the servers, you control the rendezvous, relay, console, and stored device data. Direct connections still flow between endpoints, so self-hosting alone does not guarantee in-country traffic or GDPR compliance.
+
+## Built for MSPs and IT teams
+
+For teams supporting many clients, RustDesk includes a [self-hosted web console](/blog/rustdesk-web-console-custom-client-generator-port-21114), a custom-branded client generator, and device groups with 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. That's how the "one console, many technicians, many [managed devices](/blog/what-counts-as-a-managed-device)" workflow that TeamViewer users expect gets rebuilt on infrastructure you own. For exact feature availability by plan, [see rustdesk.com/pricing](https://rustdesk.com/pricing).
+
+## The honest caveat: someone has to run the server
+
+Self-hosting is the whole point — and it's also the trade-off. Someone on your side runs the server: you provision a host, open ports, set up TLS, and keep it patched. That's straightforward for most IT teams and [MSPs](/blog/rustdesk-for-msps), but it's 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, be clear-eyed: RustDesk Server Pro is self-hosted by design and is not that. The upside of owning your infrastructure comes with the responsibility of operating it. We'd rather you know that going in than be surprised later.
+
+## TeamViewer migration plan
+
+Inventory the TeamViewer capabilities your organization actually uses before selecting a replacement tier. Include unattended endpoints, licensed users, concurrent sessions, policies, groups, SSO, audit requirements, mobile support, remote printing, integrations, and any Tensor-specific controls.
+
+Then migrate in stages:
+
+1. Stand up RustDesk in a non-production environment and test both direct and relay paths.
+2. Map users, groups, and address-book ownership to least-privilege RustDesk access rules.
+3. Pilot representative Windows, macOS, Linux, and mobile devices, including elevation and unattended access.
+4. Validate update, key backup, certificate renewal, logging, monitoring, and disaster recovery.
+5. Run TeamViewer and RustDesk in parallel for a defined cohort, with a documented rollback path.
+6. Remove the old agent only after the new service passes acceptance criteria and support staff are trained.
+
+This sequence prevents a licensing decision from turning into an untested infrastructure cutover.
+
+## Evaluate the switch on your own infrastructure
+
+You don't need to talk to anyone to evaluate RustDesk:
+
+- **Self-host the free, open-source community server today** and see how it runs on your own hardware.
+- **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.
+
+If cost and control are why you're leaving TeamViewer, a self-hosted, open-source alternative is worth an afternoon of your time.
diff --git a/v3/src/content/post/en/teamviewer-commercial-use-detected.md b/v3/src/content/post/en/teamviewer-commercial-use-detected.md
new file mode 100644
index 00000000..dc5b485c
--- /dev/null
+++ b/v3/src/content/post/en/teamviewer-commercial-use-detected.md
@@ -0,0 +1,80 @@
+---
+publishDate: 2026-07-06T00:00:00Z
+lang: en
+translationKey: teamviewer-commercial-use-detected
+draft: false
+title: 'TeamViewer Commercial Use Detected: How to Fix It'
+excerpt: "Flagged for commercial use on TeamViewer? Here's the official appeal process, what actually counts as commercial use, and the self-hosted way to avoid it."
+image: ~/assets/images/blog/teamviewer-commercial-use-detected-og.png
+category: Troubleshooting
+tags:
+ - TeamViewer
+ - troubleshooting
+ - licensing
+author: RustDesk Team
+metadata:
+ description: "Flagged for 'commercial use detected' on TeamViewer? Here's the official reset process, what counts as commercial use, and how self-hosted RustDesk avoids it."
+ keywords: 'TeamViewer commercial use detected, TeamViewer reset commercial use, TeamViewer commercial use appeal, TeamViewer personal use flagged'
+---
+
+You sat down to help a client, a colleague, or your own second machine, and TeamViewer greeted you with a banner: [**commercial use detected**](https://www.teamviewer.com/en-us/global/support/knowledge-base/teamviewer-classic/licensing/personal-use/commercial-use-suspected/). Then the sessions started dropping after a few seconds, or the connection was blocked outright until you either stopped using it or bought a license. If that's why you're here, you're not imagining it, and you're not alone.
+
+This guide first walks through **how to actually get the flag reviewed and lifted** on your existing TeamViewer account, then explains why it keeps happening and how teams who are done with the cycle move to a self-hosted setup with no commercial-use detection built in at all.
+
+## How to fix "commercial use detected" on your TeamViewer account
+
+TeamViewer publishes an official [reset/appeal process](https://www.teamviewer.com/en-us/global/support/knowledge-base/teamviewer-classic/licensing/personal-use/commercial-use-suspected/) for exactly this situation. Here's what it involves:
+
+1. **Go to [teamviewer.com/reset](https://teamviewer.com/reset)** and click the start button.
+2. **Enter your name and the email address on your TeamViewer account.**
+3. **Briefly describe your actual usage pattern** — e.g. "I only use this to help my elderly parent with their PC," or whatever genuinely describes what you're doing.
+4. **List every TeamViewer ID involved**, both the device you connect _from_ and any you connect _to_ (the form currently accepts up to 10 IDs per submission).
+5. **Accept the privacy policy and submit.**
+
+TeamViewer states they aim to review requests within **seven business days** at the time of writing, though it can take longer during high-volume periods — check your spam folder if you don't hear back within a week. One of two things happens next: either they reset your ID because personal use is confirmed, or they decline the reset and offer you a "declaration of private use" to sign instead. If your actual usage is commercial, neither outcome changes that — the appeal only helps when the flag was a false positive.
+
+### What actually counts as "commercial use" here
+
+Per TeamViewer's own definitions, **personal use** means helping family and friends, or connecting to your own non-server devices outside a commercial environment. **Commercial use** — the kind that won't be reset regardless of how the appeal goes — includes:
+
+- Providing support to clients or customers
+- Working from home, including simply checking work email
+- Any inbound or outbound connection happening in a commercial setting
+- Server administration or monitoring
+- Salaried work at a non-profit organization
+
+If you're doing any of that, the appeal process will correctly identify you as commercial, 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 TeamViewer flags "commercial use" in the first place
+
+TeamViewer's free tier is licensed for personal use only, and the product can classify use as commercial. A classification can be wrong, which is why TeamViewer provides the reset process above. TeamViewer does not publish a formula that users can rely on, so do not treat connection counts, session length, or device totals from third-party posts as official thresholds.
+
+For anyone doing commercial support work, this is not a bug to work around; it is the product enforcing its licensing terms. Compare current paid plans or alternatives rather than relying on private renewal anecdotes.
+
+So if the appeal doesn't 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?
+
+## If the flag is correct, compare licensed options
+
+When the usage is genuinely commercial, there is no legitimate reset workaround. Compare three paths:
+
+| Path | Best fit | Trade-off |
+| --------------------------- | --------------------------------------------------------------- | ------------------------------------------------------------------------ |
+| Buy TeamViewer | You want to preserve the current workflow and managed service | Ongoing vendor plan, terms, and feature packaging |
+| Choose another managed SaaS | You want no server operations but a different commercial offer | Sessions and administration remain vendor-operated |
+| Pilot a self-hosted tool | You want to operate the ID, relay, console, and deployment data | Your team owns hosting, patching, certificates, monitoring, and recovery |
+
+RustDesk belongs in the third row. Its community server can be self-hosted without a commercial-use classifier, while Server Pro is licensed by login users and managed devices. Standard plans include unlimited concurrent connections; Customized V2 has a defined allowance. Direct sessions still flow between endpoints, and Server Pro's commercial license terms still apply.
+
+## A safe migration path
+
+Do not uninstall TeamViewer as the first step. Stand up a test RustDesk server and validate the workflows behind your commercial usage: attended and unattended access, elevation, file transfer, multi-monitor, client deployment, access restrictions, and relay performance. Then compare the operating cost with the current TeamViewer quote.
+
+The [self-hosted TeamViewer alternative guide](/blog/self-hosted-teamviewer-alternative) covers the full migration and feature comparison. If you only need personal access and TeamViewer approves the reset, keeping the free tier may be simpler than running a server.
+
+## What to do next
+
+- Submit the official reset request if the classification is genuinely wrong.
+- If the use is commercial, compare current written quotes and license terms.
+- If self-hosting is a requirement, test the free community server before evaluating Server Pro features and plans at [rustdesk.com/pricing](https://rustdesk.com/pricing).
+
+Do not use unofficial ID-reset scripts or delete configuration files to evade the classification; they do not change the license terms and can create additional security or support problems.
diff --git a/v3/src/content/post/en/teamviewer-too-expensive-alternatives.md b/v3/src/content/post/en/teamviewer-too-expensive-alternatives.md
new file mode 100644
index 00000000..ce46fd8e
--- /dev/null
+++ b/v3/src/content/post/en/teamviewer-too-expensive-alternatives.md
@@ -0,0 +1,121 @@
+---
+publishDate: 2026-07-06T00:00:00Z
+lang: en
+translationKey: teamviewer-too-expensive-alternatives
+draft: false
+title: 'TeamViewer Too Expensive? Your Real Options in 2026'
+excerpt: 'If TeamViewer feels too expensive at renewal, compare three-year TCO across renewal, migration, hosting, operations, users, devices, and concurrency.'
+image: ~/assets/images/blog/teamviewer-too-expensive-alternatives-og.png
+category: Guides
+tags:
+ - RustDesk
+ - TeamViewer
+ - pricing
+ - alternative
+author: RustDesk Team
+metadata:
+ description: 'TeamViewer too expensive at renewal? Build a comparable three-year TCO across licensing, migration, hosting, operations, users, devices, and concurrency.'
+ keywords: 'TeamViewer too expensive, TeamViewer renewal cost, TeamViewer three-year TCO, TeamViewer cost alternatives'
+---
+
+## "TeamViewer Too Expensive?" You're Not Alone
+
+If the renewal invoice triggered your search, compare current written quotes using the same users, devices, concurrency, features, and support requirements.
+
+The real problem is paying for functions you do not use. If **TeamViewer feels too expensive**, it usually isn't because you're using more. It's because the pricing model keeps climbing whether you grow or not. This guide explains _why_ that happens, and lays out the real options for teams shopping to leave, including where RustDesk fits and where it honestly doesn't.
+
+## Why the bill keeps going up
+
+Cloud-subscription remote-desktop tools are priced around tiers, seats, and add-on modules. A renewal may change when your requirements, plan packaging, discounts, or vendor rates change. You're renting access to a vendor's cloud, so compare the dated renewal quote with current alternatives rather than assuming a universal increase.
+
+Renewal changes can motivate a comparison, but the correct plan depends on your current workload. Model the decision from official pricing and feature matrices.
+
+The frustration isn't the software. It's the model. So the real question isn't "what's a cheaper cloud tool" — it's "what pricing model stops surprising me."
+
+## The core fix: own the infrastructure, pay per user + per device
+
+RustDesk changes the cost equation in two structural ways.
+
+First, **it's self-hosted.** RustDesk Server Pro runs the ID/rendezvous server, relay, console, and stored deployment data on infrastructure you operate. Direct sessions still flow between endpoints; relayed sessions use your configured relay. Hosting moves into your cost model rather than being bundled into SaaS pricing.
+
+Second, licensing is [per login-user plus per managed-device](/blog/rustdesk-pro-license-cost-how-to-pay). Standard plans include unlimited [concurrent connections](/blog/rustdesk-concurrent-connections-limit); Customized V2 limits and prices them separately.
+
+You can also [upgrade any time](/blog/upgrade-rustdesk-license-mid-subscription), prorated — for exact numbers, [see rustdesk.com/pricing](https://rustdesk.com/pricing).
+
+## How the models compare
+
+| | Typical cloud tool | RustDesk Server Pro |
+| ----------------------------- | ------------------------------ | -------------------------------------------------------------------------- |
+| Where it runs | Vendor's cloud | Your server (on-prem or your VPS) |
+| Priced by | Seats / tiers / add-on modules | Per login-user + per managed-device |
+| Concurrent sessions | Often capped by plan | Unlimited on standard plans; limited on Customized V2 |
+| Server-side services and data | Vendor-operated | Operated on infrastructure you control |
+| Source code | Closed | [Open source (AGPL)](/blog/case-for-open-source-remote-access) — auditable |
+| Try before you buy | Often needs a sales call | Free community server, or Pro trial on request |
+
+For exact competitor pricing and current plan details, check each vendor's own page — we don't quote numbers we can't stand behind.
+
+## What to extract from the renewal quote
+
+Normalize the quote before comparing it. Cloud remote-support costs can change in several directions:
+
+- **Tier jumps.** Plans are structured so the one capability you eventually need — more concurrent sessions, more managed devices, an extra admin seat — sits one tier above where you are. Crossing that line re-prices the whole base plan, not just the thing you added.
+- **Add-on modules.** Mobile device support, endpoint management, extra concurrency, conditional access, and similar extras are frequently sold as separate line items on top of the base subscription. A quote that looked lean at signup grows an add-on at a time.
+- **Renewal terms.** Introductory discounts, contract length, currency, support, taxes, and changed packaging can all affect the new total. Record each difference instead of attributing the entire change to one cause.
+
+Some increases reflect added usage; others do not. Use the vendor's current pricing page and your written quote as the source of truth—we do not infer current prices from another customer's contract.
+
+## 3-year TCO: cloud subscription vs self-host
+
+Sticker price is a poor way to compare these two models, because they put the money in different places. A conceptual three-year total-cost-of-ownership breakdown makes the trade visible:
+
+**Cloud subscription (recurring):**
+
+- Year 1 base subscription, plus any add-on modules
+- Year 2 and Year 3 renewals under documented assumptions
+- Cost scales with seats and tiers as you grow, and stops entirely the moment you stop paying — you own nothing at the end
+
+**Self-hosted RustDesk (mixed):**
+
+- A [RustDesk Server Pro license](/blog/rustdesk-pro-license-cost-how-to-pay), sized to login-users + managed-devices (current figures at [rustdesk.com/pricing](https://rustdesk.com/pricing))
+- A VPS or on-prem host to run the ID/rendezvous and relay servers — a modest, predictable line item you already understand
+- Ops hours: the honest cost of self-hosting — initial setup (host, ports, TLS) plus ongoing patching and monitoring
+- Concurrency is not a cost lever on standard plans, so growth in simultaneous sessions doesn't re-price the deal
+
+The point isn't that self-hosting is free — it plainly isn't, and the ops-hours line is the one teams underestimate. The point is _where_ the money goes: into infrastructure and time you control, rather than a recurring rate someone else resets each year.
+
+## What you stop paying for
+
+Moving to a self-hosted model removes several recurring line items outright:
+
+- **Per-channel / per-concurrent-session fees** — standard plans don't meter simultaneous sessions.
+- **The vendor-cloud premium** — you pay for a VPS at cost, not a margin on someone else's routing infrastructure.
+- **Feature-tier tolls** — capabilities often gated behind higher cloud tiers ([device groups and a shared address book](/blog/rustdesk-per-user-access-control-device-groups-shared-address-book), [LDAP/SSO](/blog/rustdesk-active-directory-ldap-sso) from the Basic plan and up) come with the plan you host.
+- **Some usage-based add-ons** — standard RustDesk plans do not meter concurrency, while Customized V2 does. RustDesk licenses still renew annually and current rates can change, so budget from the current terms rather than assuming a permanent price.
+
+What you take on instead is the server itself — covered honestly in the caveat below.
+
+## You can prove the savings before you pay
+
+One reason renewal sticker-shock stings is that switching feels risky. RustDesk removes the leap of faith: you can **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. 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).
+
+Use a trial or proof of concept to validate the cost model and operational fit on your own hardware before purchasing an annual license.
+
+## It scales, and it consolidates
+
+Cost includes overlapping tools, migration, infrastructure, and operations. Consolidation may help, but validate access-control and SSO requirements against the current plan matrix.
+
+For large deployments, validate current capacity guidance against your workload. Pro provides a web console, while custom client generation and identity features depend on plan. Self-hosting controls server-side components but does not by itself guarantee in-country traffic or GDPR compliance.
+
+## The honest caveat
+
+Self-hosting changes the cost structure—and adds operating work. **Someone on your side has to run the server:** provision a host, open ports, set up TLS, monitor it, and keep it patched. If what you want is a [managed SaaS](/blog/rustdesk-self-hosted-vs-cloud-saas-option) with no server to run, RustDesk Server Pro is not that. The upside is control of server-side services and unlimited concurrency on standard plans; Customized V2 and all user/device allowances still have to be sized from current terms.
+
+For a lot of teams fed up with the renewal climb, that's a trade worth making. For a few, it isn't. Both answers are fine; we'd rather you know which one you are before you switch.
+
+## Try it
+
+- Stand up the **free, open-source community server** and connect your first devices — no cost, no sales call.
+- **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.
+
+Prove the cost model on your own infrastructure, then decide.
diff --git a/v3/src/content/post/en/teamviewer-vs-anydesk-for-msps.md b/v3/src/content/post/en/teamviewer-vs-anydesk-for-msps.md
new file mode 100644
index 00000000..557ef9c4
--- /dev/null
+++ b/v3/src/content/post/en/teamviewer-vs-anydesk-for-msps.md
@@ -0,0 +1,75 @@
+---
+publishDate: 2026-07-06T00:00:00Z
+lang: en
+translationKey: teamviewer-vs-anydesk-for-msps
+draft: false
+title: 'TeamViewer vs AnyDesk for MSPs: A Self-Hosted Third Option'
+excerpt: 'How TeamViewer and AnyDesk compare for MSPs — current licensing, integrations, hosting, and why some look past both to a self-hosted option.'
+image: ~/assets/images/blog/teamviewer-vs-anydesk-for-msps-og.png
+category: Comparisons
+tags:
+ - TeamViewer
+ - AnyDesk
+ - MSP
+ - comparison
+author: RustDesk Team
+faq:
+ - question: 'Is TeamViewer or AnyDesk better for a small MSP?'
+ answer: 'It depends on what you optimize for. AnyDesk can suit smaller technician teams that prioritize a compact client and simple branding, while TeamViewer targets service desks that need policy controls, structured reporting, and integrations. Compare both products on your own endpoints and use current written quotes rather than relying on historical positioning.'
+ - question: 'How does AnyDesk charge today?'
+ answer: "AnyDesk's official pricing page, checked July 7, 2026, lists annual plans with plan-specific licensed users, managed devices, and concurrent connections. Standard starts with one connection and Advanced with two; add-on limits vary. Verify https://anydesk.com/en/pricing and a dated written quote before budgeting."
+ - question: 'Can an MSP self-host instead of using the TeamViewer or AnyDesk cloud?'
+ answer: "Yes. RustDesk Server Pro lets you run the ID/rendezvous and relay servers on infrastructure you control, on-premises or on your own VPS, so session brokering is not sitting inside a vendor's cloud. The trade-off is that your team provisions, patches, and secures that server rather than a vendor operations team doing it for you."
+ - question: 'How is RustDesk licensing different from per-seat or per-channel models?'
+ answer: 'RustDesk licenses by login-user plus managed-device rather than by seat or by concurrent channel, and standard plans include unlimited concurrent connections while Customized V2 meters them separately. For the current plan matrix and rates, see rustdesk.com/pricing.'
+metadata:
+ description: 'TeamViewer vs AnyDesk for MSPs: current licensing models, integrations, hosting choices, and a self-hosted alternative to both.'
+ keywords: 'teamviewer vs anydesk, teamviewer vs anydesk for msp, teamviewer vs anydesk self-hosted alternative, best remote access tool for msps, anydesk pricing change'
+---
+
+MSPs sometimes inherit a mix of TeamViewer, AnyDesk, and RDP across clients. This page compares those managed options with a self-hosted third model using verifiable product differences.
+
+## TeamViewer vs AnyDesk: the short version
+
+| | TeamViewer | AnyDesk |
+| --------------------------- | ----------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------- |
+| Licensing dimensions | Plan-specific users and concurrent-session capacity | Plan-specific licensed users, managed devices, and concurrent connections |
+| Current published packaging | Verify the current plan page and a dated written quote before budgeting | [Official pricing page](https://anydesk.com/en/pricing), checked July 7, 2026: Standard starts with one connection; Advanced with two |
+| Best fit | Service desks needing policy controls, reporting, and integrations | Teams prioritizing a compact client, connection performance, and branding |
+| Hosting | Managed cloud plans | Managed cloud on standard tiers; Ultimate advertises cloud or on-premises deployment |
+
+Treat the pricing rows as dated, since both vendors reprice often.
+
+## Licensing: the real difference is what you're metered on
+
+TeamViewer packages named users and concurrent-session capacity into tiers. Buyers should compare the complete written quote, including add-ons, with their actual workload.
+
+AnyDesk plan packaging and renewal terms can change. Its [official pricing page](https://anydesk.com/en/pricing), checked July 7, 2026, lists Solo with one user and one connection, Standard with up to 20 users and one included connection, and Advanced with up to 100 users and two included connections; managed-device and connection add-on limits vary by plan. Compare that page and a dated written quote against the exact users, concurrent sessions, managed endpoints, and features your MSP requires. Do not base a purchase on another customer's legacy contract. Security review should be separate from price review; the [2024 incident](https://anydesk.com/en/public-statement) belongs in the vendor-risk assessment, not as proof that one licensing model is better.
+
+## Where each one actually fits
+
+TeamViewer tends to win for MSPs that have outgrown ad hoc support: policy controls, structured reporting, mass deployment, and — as of the Business plan and up — built-in AI-assisted support tooling. If your service desk already lives in ServiceNow, Jira, or Microsoft Intune, TeamViewer Tensor's native integrations are hard for a smaller competitor to match. That structure has a cost, and it shows up as complexity and add-on pricing rather than a single clean number.
+
+AnyDesk is often shortlisted by smaller shops that prioritize connection performance, a compact client, and branding. Whether its current packaging is economical depends on the quote and workload; model technician and concurrency growth rather than assuming it remains the cheapest option.
+
+Neither vendor is going to solve the thing a lot of MSPs actually want, though: getting off a metered-connection or metered-seat model entirely, and owning where session data lives.
+
+## Why some MSPs look past both
+
+This is the part where RustDesk makes its case, so read it as vendor-authored commentary.
+
+**A different unit of pricing.** RustDesk licenses by **login-user plus managed-device**. Standard plans include unlimited concurrent connections; Customized V2 limits and prices them separately.
+
+**Self-hosted server-side services.** RustDesk Server Pro runs the ID/rendezvous, relay, console, and stored deployment data on infrastructure you control. Direct sessions still flow between endpoints. For regulated clients, this supplies architectural control, but it does not by itself satisfy data-residency or compliance requirements.
+
+**Open source you can audit.** The client is AGPL-licensed — inspect it, build it yourself, run the free community server indefinitely. That's a structurally different trust model than a closed-source client whose licensing terms you don't control.
+
+**Built for the MSP workflow.** A self-hosted web console, a custom-branded client generator, device groups, and a shared address book cover the "one console, many technicians, many client devices" requirement. Feature availability varies by RustDesk plan, and Customized V2 has a concurrency allowance, so verify the current matrix. See [RustDesk for MSPs](/blog/rustdesk-for-msps) for the full picture, and our deeper head-to-heads: [RustDesk vs TeamViewer](/blog/rustdesk-vs-teamviewer) and [RustDesk vs AnyDesk](/blog/rustdesk-vs-anydesk). If TeamViewer is the incumbent you're actually trying to replace, [the self-hosted TeamViewer alternative](/blog/self-hosted-teamviewer-alternative) covers that migration specifically.
+
+## The honest caveat
+
+Self-hosting isn't free of cost, it's free of a specific kind of cost. Running RustDesk Server Pro means **you** provision the server, patch it, and keep it secured — there's no vendor NOC doing that for you the way there is with TeamViewer's or AnyDesk's managed cloud. For an MSP that already runs infrastructure for clients, that's routine. For one with no appetite to run a server at all, a managed product may genuinely be the better fit, and that's a legitimate call to make.
+
+## Try it
+
+Self-host the free community server today. 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).
diff --git a/v3/src/content/post/en/teamviewer-vs-splashtop.md b/v3/src/content/post/en/teamviewer-vs-splashtop.md
new file mode 100644
index 00000000..03f0886e
--- /dev/null
+++ b/v3/src/content/post/en/teamviewer-vs-splashtop.md
@@ -0,0 +1,110 @@
+---
+publishDate: 2026-07-06T00:00:00Z
+lang: en
+translationKey: teamviewer-vs-splashtop
+draft: false
+title: 'TeamViewer vs Splashtop: Pricing, Performance & Self-Hosting'
+excerpt: 'TeamViewer vs Splashtop compared on price, performance, and security — plus how a self-hosted third option changes the decision.'
+image: ~/assets/images/blog/teamviewer-vs-splashtop-og.png
+category: Comparisons
+tags:
+ - TeamViewer
+ - Splashtop
+ - comparison
+author: RustDesk Team
+faq:
+ - question: 'Does Splashtop offer an on-premises version?'
+ answer: 'Yes. Splashtop sells a separately licensed On-Prem product for enterprise deployments. It uses a customer-operated Splashtop Gateway and is distinct from the standard vendor-hosted Splashtop subscriptions.'
+ - question: 'Is Splashtop cheaper than TeamViewer?'
+ answer: "Splashtop publishes lower entry prices for some remote-access plans, but a valid comparison must include the required users, managed endpoints, concurrent sessions, governance features, add-ons, region, and renewal terms. Compare each vendor's current plan page and a dated written quote."
+ - question: 'What should teams test before choosing TeamViewer or Splashtop?'
+ answer: 'Test both products on representative endpoints and networks. Include attended and unattended access, multi-monitor behavior, audio, file transfer, mobile support, identity integration, audit requirements, deployment, and the number of simultaneous technician sessions.'
+metadata:
+ description: 'TeamViewer vs Splashtop: pricing models, performance, and security compared, plus how a self-hosted alternative changes the decision.'
+ keywords: 'TeamViewer vs Splashtop, Splashtop or TeamViewer, TeamViewer Splashtop pricing, TeamViewer Splashtop comparison'
+---
+
+TeamViewer and Splashtop both cover remote access and support, but the right comparison is not simply "premium versus budget." Buyers need to compare licensing units, administration, deployment model, and performance on their own endpoints. This article uses current public product information and dated vendor disclosures rather than private customer anecdotes.
+
+## TeamViewer vs Splashtop: the short version
+
+| | TeamViewer | Splashtop |
+| ---------------- | -------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| Published plans | Business, Premium, Corporate, and enterprise offerings; features and session capacity vary by plan | Remote Access Solo, Pro, Performance, and Enterprise; Remote Support uses separate packaging |
+| Deployment model | Vendor-operated service | Vendor-operated SaaS plans; a separately licensed On-Prem product is available for enterprise deployments |
+| Administration | Policy controls, reporting, mass deployment, and enterprise integrations vary by edition | Roles, access management, and session recording on relevant plans; SSO, granular controls, SIEM, and other controls are concentrated in Enterprise |
+| Performance | Test relay routing, responsiveness, audio, and multi-monitor workflows on representative networks | Performance advertises 4:4:4 color, high-fidelity audio, and up to 240 FPS; validate those workflows on the endpoints and networks you will actually use |
+| Buying fit | Teams that value a mature managed service, structured administration, and broad integrations | Individuals and teams comparing lower published entry tiers, multimedia features, or a separately quoted On-Prem deployment |
+| Source model | Proprietary | Proprietary |
+
+Treat pricing rows as dated — both vendors reprice often.
+
+## Pricing: compare the complete workload
+
+Splashtop's [official pricing page](https://www.splashtop.com/pricing), checked July 8, 2026, publishes entry prices for Remote Access Solo, Pro, and Performance, while Enterprise and On-Prem require sales engagement. TeamViewer publishes regional pricing and packages features and capacity by edition on its [pricing overview](https://www.teamviewer.com/en/pricing/overview/). A visible starting price does not establish the total cost for an IT team.
+
+Build the comparison from your real workload:
+
+- licensed users or technicians;
+- unattended endpoints and attended-support requirements;
+- simultaneous remote sessions;
+- SSO, audit, access-control, integration, and recording requirements;
+- add-ons, regional taxes, contract length, and renewal terms.
+
+Request dated written quotes using the same workload. Historical prices or another customer's contract are not reliable budgeting inputs.
+
+## Deployment: SaaS and On-Prem are separate products
+
+Splashtop's mainstream Remote Access and Remote Support subscriptions are vendor-operated services. Splashtop also sells a **separately licensed On-Prem** product. Its [official product page](https://www.splashtop.com/products/on-prem) describes a self-hosted deployment using a **Splashtop On-Prem Gateway** in the customer's DMZ or behind its firewall.
+
+That distinction matters. Buying a standard Splashtop subscription does not mean deploying On-Prem, and evaluating Splashtop On-Prem is not the same as trialing a standard SaaS plan. The On-Prem path adds customer-side infrastructure, network design, TLS, upgrades, backup, monitoring, and capacity planning. Splashtop's [system requirements](https://support-splashtoponprem.splashtop.com/hc/en-us/articles/360035393074-Splashtop-On-Prem-System-Requirements) document a dedicated Gateway and server sizing requirements.
+
+TeamViewer's standard comparison path is its managed service. Buyers with a hard requirement for customer-operated brokering infrastructure should compare Splashtop On-Prem with other self-hosted products rather than treating the SaaS editions as equivalent deployments.
+
+## Performance: test the workflow, not the headline
+
+Splashtop Performance advertises 4:4:4 color, high-fidelity audio, USB passthrough, and capability up to 240 FPS. Those features can matter for media, CAD, and other visually sensitive work. TeamViewer emphasizes broad endpoint support, managed administration, and service-desk workflows.
+
+Neither positioning statement predicts performance in your environment. Pilot both products with the same:
+
+- office, home, mobile, and high-latency network paths;
+- Windows, macOS, Linux, and mobile combinations you support;
+- attended and unattended sessions;
+- multi-monitor, audio, file-transfer, printing, and privilege-elevation tasks;
+- expected number of simultaneous technician sessions.
+
+Record connection time, interaction latency, image quality, failure rate, and technician effort. A short controlled test is more useful than an isolated online complaint or vendor benchmark.
+
+## Security: both are more serious than "cheap vs expensive" suggests
+
+Security claims need dates and boundaries. Splashtop's [September 18, 2025 announcement](https://www.splashtop.com/press/splashtop-achieves-iso-iec-27001-2022-certification) reports ISO/IEC 27001:2022 certification, while its current [security page](https://www.splashtop.com/security) lists SOC 2, TLS 1.2, and 256-bit AES session protection. Certification does not prove an absence of incidents: on June 30, 2026, Splashtop [disclosed a third-party Klue incident](https://www.splashtop.com/blog/security-update-third-party-klue-incident) that it says did not affect Splashtop products or services.
+
+TeamViewer's current [Trust Center](https://www.teamviewer.com/en/resources/trust-center/) lists SOC 2/SOC 3 and ISO/IEC 27001, and its [technical security overview](https://teamviewer.scene7.com/is/content/teamviewergmbh/teamviewer/central-image-hub/pdf/en/teamviewer-security-technical-overview-en.pdf) documents current architecture and encryption. TeamViewer's [TV-2024-1005 incident bulletin](https://www.teamviewer.com/en/resources/trust-center/security-bulletins/tv-2024-1005/) says the June 2024 attack was contained to its internal corporate IT environment and did not affect the product environment, connectivity platform, or customer data. These are dated vendor disclosures, not an unbounded claim that either company has never had a breach.
+
+## Where each product fits
+
+TeamViewer may fit organizations that want a managed service with mature policy controls, reporting, mass deployment, and enterprise integrations. Confirm which edition supplies each required control rather than assuming the full feature set exists in every plan.
+
+Splashtop SaaS may fit teams that prioritize straightforward deployment, published entry pricing, and its performance-oriented feature set. Splashtop Enterprise and On-Prem address different requirements and should be quoted separately.
+
+The decision changes when infrastructure control, source visibility, or a different licensing model becomes a requirement. That is where a self-hosted alternative belongs in the evaluation.
+
+## Why some teams also evaluate RustDesk
+
+This is where we make RustDesk's case plainly, so read it as that.
+
+**A published licensing model.** RustDesk Server Pro standard plans license **login users plus managed devices** and include unlimited concurrent connections. Customized V2 has a defined concurrency allowance, so confirm the current [pricing matrix](https://rustdesk.com/pricing) for the plan you are evaluating.
+
+**Self-hosted server-side services.** RustDesk Server Pro runs the ID/rendezvous, relay, console, and stored deployment data on infrastructure you control. When customer-operated infrastructure is mandatory, compare it with Splashtop On-Prem rather than with Splashtop's SaaS plans.
+
+**Open-source client and community server.** RustDesk's core client and free server are AGPL-licensed, so teams can inspect the code and evaluate basic self-hosting before buying Server Pro. TeamViewer and Splashtop are proprietary products.
+
+**A third option for the MSP workflow.** A self-hosted web console, custom client generator, device groups, and a shared address book cover the "one console, many technicians" requirement. RustDesk still licenses login users and managed devices, and Customized V2 has a concurrency allowance. See [RustDesk for MSPs](/blog/rustdesk-for-msps), [RustDesk vs TeamViewer](/blog/rustdesk-vs-teamviewer), and [Self-Hosted Splashtop Alternative: What IT Teams Should Evaluate Before Switching](/blog/rustdesk-vs-splashtop).
+
+## The honest caveat
+
+Self-hosting does not remove operational cost. Running RustDesk Server Pro or Splashtop On-Prem means **your team** operates server infrastructure. TeamViewer and Splashtop SaaS shift more of that work to the vendor. If your team does not want to own TLS, monitoring, backup, upgrades, and availability, a managed product may be the better fit.
+
+## Try it
+
+Self-host the free community server today. 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).
diff --git a/v3/src/content/post/en/upgrade-rustdesk-license-mid-subscription.md b/v3/src/content/post/en/upgrade-rustdesk-license-mid-subscription.md
new file mode 100644
index 00000000..3edcc236
--- /dev/null
+++ b/v3/src/content/post/en/upgrade-rustdesk-license-mid-subscription.md
@@ -0,0 +1,58 @@
+---
+publishDate: 2026-07-06T00:00:00Z
+lang: en
+translationKey: upgrade-rustdesk-license-mid-subscription
+draft: false
+title: 'Upgrade RustDesk License Mid-Subscription: How It Works'
+excerpt: 'Yes—you can upgrade your RustDesk license anytime to add users or devices as you grow. Learn how proration works and why you must refresh the license after.'
+image: ~/assets/images/blog/upgrade-rustdesk-license-mid-subscription-og.png
+category: Pricing
+tags:
+ - RustDesk
+ - pricing
+ - licensing
+author: RustDesk Team
+faq:
+ - question: 'Can I upgrade my RustDesk license mid-subscription?'
+ answer: 'Yes. You can upgrade your RustDesk license at any time during your subscription to add more managed devices or users. Upgrades are prorated, and after purchasing you must manually refresh the license in the web console for the new limits to take effect.'
+ - question: 'How is a RustDesk license upgrade prorated?'
+ answer: 'The upgrade is prorated against the time left on your current term: the system charges the difference for the added users or devices based on the remaining days, rather than a full new price. See rustdesk.com/pricing for tier details.'
+ - question: "Why don't my new devices appear after I upgrade my license?"
+ answer: 'The new limits are not always applied instantly. After completing the upgrade you must manually refresh the license in the web console to pull the updated entitlement, after which the added devices or users become usable.'
+ - question: 'How do I refresh my license in the web console?'
+ answer: 'Open the web console after purchasing the upgrade and use the license refresh action to pull your updated entitlement. This activates the higher user and device limits for your deployment.'
+ - question: 'Can I downgrade or reduce seats mid-subscription?'
+ answer: 'This article covers upgrades, which you can make at any time. For reducing seats or downgrading mid-term, confirm the current handling with the RustDesk team at sales@rustdesk.com.'
+
+metadata:
+ description: 'Yes—you can upgrade your RustDesk license anytime to add users or devices as you grow. Learn how proration works and why you must refresh the license after.'
+ keywords: 'upgrade RustDesk license mid-subscription, add more devices RustDesk license, RustDesk license proration, increase managed devices RustDesk, refresh license web console RustDesk, RustDesk per-user per-device licensing'
+---
+
+Yes—you can upgrade your RustDesk license mid-subscription to add more [managed devices](/blog/what-counts-as-a-managed-device) or users whenever your team grows. Upgrades are allowed at any time and are prorated, so you only pay for the difference for the remainder of your term.
+
+## The short answer
+
+You do not have to wait for renewal to scale up. RustDesk lets you upgrade your existing license at any point during the subscription year. The cost is prorated against the time left on your current term, and once the upgrade is complete you refresh the license in your [web console](/blog/rustdesk-web-console-custom-client-generator-port-21114) to activate the higher limits.
+
+## In detail
+
+RustDesk licensing is structured around per-user and per-device seats, and a growing IT team or [MSP](/blog/rustdesk-for-msps) will naturally hit the point where more devices or users need coverage. Rather than forcing you to buy a whole new subscription or wait for the annual renewal date, RustDesk treats the upgrade as an in-place change to your existing license.
+
+Because you have already paid for part of the year, the upgrade is prorated. In practice that means the system calculates the additional cost based on the time remaining on your subscription, so you are charged the difference for the new capacity rather than a full new price. If the amount ever looks higher than you expect, you can check the math against your remaining term and confirm you have not been overcharged.
+
+One operational detail is easy to miss: the new limits are not always applied instantly. After you complete the upgrade, you need to manually refresh the license inside the web console. This pulls the updated entitlement so your added devices or users become usable. If you upgrade and the new seats do not appear right away, this refresh step is almost always the reason.
+
+For teams migrating from TeamViewer or AnyDesk, this flexibility is a meaningful difference: you can start with the capacity you need today and expand incrementally, paying only for what you add, without renegotiating a contract mid-term. Exact pricing tiers and seat definitions are on the official pricing page [rustdesk.com/pricing](https://rustdesk.com/pricing).
+
+## Who asks this
+
+This question comes up most often from IT admins and MSPs who bought a license sized for their current fleet and are now onboarding new endpoints, staff, or client sites partway through the year. The concern behind it is usually twofold: whether scaling up is even possible mid-term, and whether they will be fairly charged for it.
+
+## Related questions
+
+- [How is the upgrade cost prorated for the remaining time on my subscription?](/blog/rustdesk-pro-license-cost-how-to-pay)
+- [How do I manually refresh my license in the web console?](/blog/rustdesk-web-console-custom-client-generator-port-21114)
+- [What is the difference between per-user and per-device licensing in RustDesk?](/blog/what-counts-as-a-managed-device)
+
+Growing your deployment? Upgrade your license whenever you need more capacity, then refresh it in the web console—and double-check the prorated amount against your remaining term if you want to confirm the numbers.
diff --git a/v3/src/content/post/en/what-counts-as-a-managed-device.md b/v3/src/content/post/en/what-counts-as-a-managed-device.md
new file mode 100644
index 00000000..a0350458
--- /dev/null
+++ b/v3/src/content/post/en/what-counts-as-a-managed-device.md
@@ -0,0 +1,63 @@
+---
+publishDate: 2026-07-06T00:00:00Z
+lang: en
+translationKey: what-counts-as-a-managed-device
+draft: false
+title: 'What Counts as a Managed Device in RustDesk?'
+excerpt: 'Every device you reach counts once toward your RustDesk license, regardless of attended/unattended or connection frequency. Ad-hoc support has its own model.'
+image: ~/assets/images/blog/what-counts-as-a-managed-device-og.png
+category: Pricing
+tags:
+ - RustDesk
+ - pricing
+ - licensing
+author: RustDesk Team
+faq:
+ - question: 'How does RustDesk count managed devices?'
+ answer: "Every device you want to be able to access counts as one managed device, counted a single time. It makes no difference whether a machine is attended or unattended, or whether you connect to it once or a thousand times. For pure ad-hoc, one-off support where you don't retain a permanent connection, RustDesk offers a separate quick-support license model."
+ - question: 'What is the quick-support (ad-hoc) license model, and when should I use it?'
+ answer: "Quick support is a separate model for spontaneous, one-off sessions where you don't keep a permanent connection to the machine. If your work is purely ad-hoc — you help someone once and move on — it fits better than counting every endpoint as a managed device."
+ - question: 'Do concurrent connections to the same device count more than once?'
+ answer: 'No. A device is counted a single time no matter how many times, or how simultaneously, you connect to it. You pay for the device being reachable, not per connection to it.'
+ - question: 'Does an attended device count differently from an unattended one?'
+ answer: 'No. An unattended server and an attended employee laptop each count as one managed device. The attended/unattended split does not create two pricing buckets — what changes the model is whether support is permanent or ad-hoc.'
+
+metadata:
+ description: 'Every device you reach counts once toward your RustDesk license, regardless of attended/unattended or connection frequency. Ad-hoc support has its own model.'
+ keywords: 'what counts as a managed device, rustdesk device counting, rustdesk vs teamviewer licensing, unattended vs attended device license, rustdesk quick support license, msp remote support licensing'
+---
+
+If you're coming from TeamViewer's per-seat model, the counting rule in RustDesk is refreshingly simple: **every device you want to access counts as one managed device, counted once.** Attended or unattended, connected once or constantly, it's the same single count. Pure ad-hoc support is handled by a separate quick-support model.
+
+## The short answer
+
+A "managed device" is any machine you want to be able to reach. The server counts each one a single time. It doesn't matter:
+
+- whether the device is **attended** (someone is sitting at it) or **unattended** (a headless server, kiosk, or always-on workstation),
+- whether you'll connect **once** or **many times**,
+- how frequently you access it.
+
+The server has no way of knowing your intent, so it simply counts the devices you have set up to access. If your work is purely spontaneous, one-off support, look at the **quick-support license model** instead — that's the path built for ad-hoc sessions.
+
+## In detail
+
+The reasoning follows directly from how the counting works. The server tracks the devices registered to be accessed; it cannot see the future, so it can't distinguish a machine you'll touch once from one you'll touch daily, nor an attended desk from an unattended server. Every reachable device therefore counts the same way: **once.**
+
+That's a meaningful difference from per-seat or per-technician licensing. You aren't paying per concurrent session or per simultaneous connection to the same box — a device is a device. This makes capacity planning predictable: count the machines you intend to keep reachable, and that's your number.
+
+The important nuance is the **attended/unattended split you may be used to elsewhere doesn't create two pricing buckets here.** An unattended server and an attended employee laptop each count as one device. What _does_ change the model is whether the support is permanent or ad-hoc. If you don't need a standing, always-available connection — you just help someone once and move on — the quick-support model is the right tool, and it's licensed differently from your fleet of managed devices — see [rustdesk.com/pricing](https://rustdesk.com/pricing) for current terms.
+
+For example, imagine an [MSP](/blog/rustdesk-for-msps) with 20 technicians supporting roughly 1,000 customer machines: it would need to satisfy **both** licensing dimensions — enough login users for all 20 technicians and enough managed devices for the machines kept reachable. If many endpoints are truly one-time support calls, ask RustDesk whether the current quick-support terms fit that workload better; you can check current allowances at [rustdesk.com/pricing](https://rustdesk.com/pricing).
+
+## Who asks this
+
+This comes up from **MSPs and internal IT teams migrating off TeamViewer or AnyDesk**, where different licensing units make comparisons confusing. RustDesk paid plans require capacity for both the people who log in and the devices kept under management.
+
+## Related questions
+
+- [Does RustDesk license per user, per device, or both?](/blog/rustdesk-pro-license-cost-how-to-pay)
+- Do [concurrent connections](/blog/rustdesk-concurrent-connections-limit) to the same device count more than once?
+- [How do I count devices for a self-hosted RustDesk Server Pro deployment?](/blog/rustdesk-custom-quote-minimum-users-invoice-fees)
+- [Coming from TeamViewer — how does RustDesk's pricing compare for MSPs?](/blog/rustdesk-vs-teamviewer)
+
+Sizing a fleet and not sure whether one-off support calls belong in your device count? Check the current terms at [rustdesk.com/pricing](https://rustdesk.com/pricing) or ask the team before you buy.
diff --git a/v3/src/content/post/en/why-self-host-remote-desktop-software.md b/v3/src/content/post/en/why-self-host-remote-desktop-software.md
new file mode 100644
index 00000000..815cb34c
--- /dev/null
+++ b/v3/src/content/post/en/why-self-host-remote-desktop-software.md
@@ -0,0 +1,84 @@
+---
+publishDate: 2026-07-06T00:00:00Z
+lang: en
+translationKey: why-self-host-remote-desktop-software
+draft: false
+title: 'Why Self-Host Your Remote Desktop Software'
+excerpt: 'Why teams leaving TeamViewer and AnyDesk are choosing to self-host remote desktop: data control, predictable cost, and no cloud in the middle.'
+image: ~/assets/images/blog/why-self-host-remote-desktop-software-og.png
+category: Guides
+tags:
+ - RustDesk
+ - self-hosting
+author: RustDesk Team
+metadata:
+ description: 'The case for self-hosting remote desktop software: data control, predictable cost, no vendor lock-in, no cloud outage. RustDesk as the concrete example.'
+ keywords: 'why self-host remote desktop, self-hosted remote desktop benefits, on-premise remote access, remote desktop without vendor cloud'
+---
+
+Self-hosting is often evaluated when organizations want more control over price, features, and infrastructure. This article focuses on those structural trade-offs.
+
+There is another way to run remote access, and it is not new — it is just less marketed, because it doesn't come with a recurring cloud subscription attached. It's the decision to **self-host your remote desktop software**: run the server that coordinates connections and relays traffic when direct connectivity fails on infrastructure you control. This article makes the case for that model and uses RustDesk as the concrete example.
+
+## What "self-host remote desktop" actually means
+
+Most mainstream remote-support tools are cloud-only. When your technician connects to a client's PC, the session is coordinated — and often relayed — through the vendor's servers. That's convenient. It also means your device list, your connection metadata, and sometimes your session traffic pass through a third party, on their uptime, under their pricing, subject to their security posture.
+
+Self-hosting flips that. With RustDesk Server Pro, the ID/rendezvous server, relay, console, and stored deployment data run on **your infrastructure**. Direct sessions still flow between endpoints; relayed sessions use your configured relay. The core client is [open source (AGPL)](/blog/case-for-open-source-remote-access) and the free community server runs indefinitely—the auditability argument for that is [its own topic](/blog/case-for-open-source-remote-access); this piece stays on the self-hosting decision itself.
+
+## Four reasons the self-hosted model wins
+
+### 1. You control the server-side infrastructure
+
+Self-hosting lets you choose where rendezvous, relay, console, and device data run. Direct connections still travel between endpoints, so self-hosting alone does not guarantee in-country traffic or GDPR compliance. Document the full [data flow and obligations](/blog/remote-desktop-data-sovereignty-gdpr).
+
+### 2. Predictable cost, not an annual surprise
+
+A common pattern is that one renewal hike pushes a team off a cloud tool, and the next vendor increase makes them re-evaluate the model itself rather than just the brand.
+
+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. For current numbers, [see rustdesk.com/pricing](https://rustdesk.com/pricing).
+
+### 3. No vendor lock-in, no cloud outage dependency
+
+Self-hosting moves the coordinating-service failure domain into your own operations, where you can design redundancy and recovery. Open source also reduces dependence on a single vendor's roadmap.
+
+### 4. It scales, and it's built for IT teams
+
+Self-hosting doesn't mean settling for a toy. RustDesk publishes [large-fleet planning guidance](/blog/rustdesk-scale-50000-200000-devices) for teams that need to support bigger estates. For [MSPs](/blog/rustdesk-for-msps) and internal IT, there's 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.
+
+## Cloud-only vs. self-hosted, at a glance
+
+| | Typical cloud-only tool | Self-hosted (RustDesk Server Pro) |
+| ---------------------------- | --------------------------------------- | --------------------------------------------------------------------------------------------------------------------------- |
+| Where sessions are brokered | Vendor's cloud | Your on-prem box or VPS |
+| Data residency | Vendor-controlled | Server-side services run on infrastructure you control; endpoint routes still matter |
+| Concurrent-connection limits | Often per-channel/seat | Standard plans unlimited; Customized V2 metered |
+| Pricing model | Per-seat/per-channel cloud subscription | [Per login-user + per managed-device](/blog/rustdesk-pro-license-cost-how-to-pay) ([pricing](https://rustdesk.com/pricing)) |
+| Source code | Closed | Open source (AGPL), auditable |
+| Outage dependency | Vendor uptime | Your own ops |
+| Who runs the server | Vendor | You |
+
+## The honest caveat
+
+Self-hosting is a trade, not a free lunch. Someone on your side has to **run the server**: provision a host, open the right ports, set up TLS, and keep it patched. That's real, ongoing 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 it is not that. The upside of doing the ops is exactly the control described above; if your team can't own a server, this model isn't for you, and that's fine.
+
+The good news is the bar to find out is low. You don't need a sales call to evaluate.
+
+## What running the server actually involves
+
+The control described above is inseparable from the operational work that buys it. Before you commit, here's the concrete reality — not a feature list:
+
+- **Provision a host.** A modest Linux VM — on-prem or a VPS you rent — runs the ID/rendezvous and relay services. Size it for your device count and how much traffic ends up relayed rather than peer-to-peer.
+- **Open only the ports you use.** Native RustDesk clients require **TCP 21115-21117 and UDP 21116** for NAT testing, connection services, registration, heartbeat, and relay. Do not expose the whole 21114-21119 range. TCP 21118-21119 are WebSocket backends, and TCP 21114 is the Pro HTTP API/console backend. When an HTTPS/WSS reverse proxy fronts the Pro API and WebSocket services, expose only TCP 443 publicly for that traffic and keep 21114 and 21118-21119 internal. Public 443 does not replace the native-client core ports when native clients also connect. See the [official port reference](https://rustdesk.com/docs/en/self-host/).
+- **Set up TLS.** Terminate HTTPS and WSS at the reverse proxy so credentials, API calls, and browser-client traffic use public TCP 443 rather than exposing the plain-HTTP console/API or raw WebSocket backends.
+- **Back up.** The server holds your device inventory, user accounts, address book, and access rules. Schedule backups — and actually test that you can restore from them.
+- **Keep a patch cadence.** New server builds ship over time, and you own the OS underneath. Decide who applies updates and how often.
+- **Monitor it.** The coordinating service is now yours, so you watch uptime, disk, and relay throughput. When it goes down, nobody else is paged.
+
+## How to evaluate self-hosting
+
+- **Self-host the free open-source community server today.** The core is AGPL — deploy it, audit it, and run it indefinitely at no cost.
+- **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.
+
+If price hikes, closed code, or a cloud you don't control are what pushed you to start shopping, self-hosting is the structural fix, not a discount. Own the server, own the data, own the cost.
diff --git a/v3/src/content/post/en/zoho-assist-alternative-self-hosted.md b/v3/src/content/post/en/zoho-assist-alternative-self-hosted.md
new file mode 100644
index 00000000..ce8341ff
--- /dev/null
+++ b/v3/src/content/post/en/zoho-assist-alternative-self-hosted.md
@@ -0,0 +1,86 @@
+---
+publishDate: 2026-07-07T00:00:00Z
+lang: en
+translationKey: zoho-assist-alternative-self-hosted
+draft: false
+title: 'Zoho Assist Alternative: Self-Hosted and Open Source'
+excerpt: 'Looking for a self-hosted Zoho Assist alternative? See how RustDesk compares on hosting, open source, and licensing — plus an honest look at the trade-offs.'
+image: ~/assets/images/blog/zoho-assist-alternative-self-hosted-og.png
+category: Alternatives
+tags:
+ - RustDesk
+ - Zoho Assist
+ - alternative
+ - self-hosting
+author: RustDesk Team
+faq:
+ - question: 'Is there a self-hosted alternative to Zoho Assist?'
+ answer: "Yes. Zoho Assist is a cloud-based SaaS, so sessions are brokered through Zoho's infrastructure. RustDesk is self-hosted by design: you run the ID/rendezvous and relay servers on your own machine or VPS, so session brokering and your device list stay on infrastructure you control. The RustDesk client is also open source under the AGPL, which Zoho Assist is not."
+ - question: 'How is RustDesk licensed compared to Zoho Assist?'
+ answer: 'Zoho Assist generally meters remote support per technician and unattended access per computer through a cloud subscription. RustDesk Server Pro is licensed per login-user plus per managed-device, hosted on your own server. There is no per-technician cloud metering layered on top. For current per-unit rates, see rustdesk.com/pricing.'
+ - question: 'Does RustDesk let me rebrand the client like Zoho Assist?'
+ answer: "Yes. RustDesk Pro includes a custom-branded client generator, so you can ship a preconfigured installer with your own name and logo. Zoho Assist also offers rebranding on its cloud plans. The difference is where everything runs: RustDesk's branded client points at your self-hosted server, not a vendor cloud."
+ - question: 'What is the catch with a self-hosted Zoho Assist alternative?'
+ answer: 'Someone on your side has to run the server. You provision a host, open ports, set up TLS, and keep it patched. Zoho Assist is a mature managed SaaS with a large ecosystem and zero server maintenance, and that convenience is real. Self-hosting trades that convenience for control and auditability.'
+metadata:
+ description: 'A self-hosted Zoho Assist alternative: RustDesk is open-source, runs on your own server, and licenses per login-user and per managed-device. See the comparison.'
+ keywords: 'Zoho Assist alternative, self-hosted Zoho Assist alternative, open source Zoho Assist alternative, RustDesk vs Zoho Assist, self-hosted remote support, on-premise remote support software'
+---
+
+[Zoho Assist](https://www.zoho.com/assist/) is a capable, cloud-based remote support and remote access product, and part of the broader Zoho suite. If you have landed here, you are probably not unhappy with what it does — you are asking a different question: **can I run something like this on my own infrastructure, and stop routing every session through a vendor's cloud?**
+
+This page is an honest comparison. RustDesk is a genuinely different model, with real advantages and one real trade-off. Here is where it fits as a self-hosted Zoho Assist alternative, and where it doesn't.
+
+## What Zoho Assist does well
+
+Credit where it is due. Zoho Assist is [cloud-based](https://www.zoho.com/assist/) remote support and unattended access software that runs in the browser with no installation needed for technicians to start a session. It handles attended support and unattended access, file transfer, multi-monitor navigation, and it can be rebranded to suit your business. It integrates tightly with the rest of the Zoho ecosystem, and — like any mature SaaS — it means **zero server maintenance** on your side. Zoho runs the infrastructure; you log in and work.
+
+For many teams that is exactly the right call. The reason people go looking for an alternative is usually one of two things: they want their session data and brokering on their _own_ servers, or they want to get out of a per-technician cloud subscription model.
+
+## The core difference: you host it, you own it
+
+Zoho Assist is a SaaS. Your sessions are brokered through Zoho's cloud, on Zoho's terms, and your device list lives there too. That is convenient, and for regulated teams or anyone with strict [data-sovereignty](/blog/remote-desktop-data-sovereignty-gdpr) requirements, it is also the sticking point.
+
+RustDesk flips the model. **RustDesk Server Pro is [self-hosted by design](/blog/why-self-host-remote-desktop-software)** — 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.
+
+And **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 the client does on your machines, build it yourself, and run the [free community server](/blog/open-source-remote-desktop-software) indefinitely. Zoho Assist is a proprietary, closed product. That is a different trust model: you do not have to take a vendor's word for what the software does, because you can look.
+
+## Zoho Assist vs. RustDesk at a glance
+
+| | Zoho Assist (cloud) | RustDesk (self-hosted) |
+| --------------------------------------------------------------------- | ------------------------------------------------ | -------------------------------------------------------------------------------------------------- |
+| Hosting | Vendor cloud (SaaS) | Your server (on-prem or your VPS) |
+| Source code | Proprietary | Open source (AGPL) core |
+| Where sessions are brokered | Zoho's infrastructure | Infrastructure you control |
+| Licensing model | Per-technician / per-computer cloud subscription | [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 |
+| Custom branding | Yes, on cloud plans | Yes, [self-hosted client generator](/blog/rustdesk-web-console-custom-client-generator-port-21114) |
+| Server maintenance | None (Zoho runs it) | Yours to run |
+
+_Zoho Assist plan details and pricing vary by tier and change over time — confirm current terms on [Zoho's pricing page](https://www.zoho.com/assist/pricing.html). For RustDesk rates, see [rustdesk.com/pricing](https://rustdesk.com/pricing)._
+
+## Licensing: no per-technician cloud meter
+
+This is where the models diverge most. Zoho Assist typically meters **remote support per technician** and **unattended access per computer** through a cloud subscription — the free tier, for example, covers one technician and a small number of computers, with paid tiers scaling from there ([Zoho pricing](https://www.zoho.com/assist/pricing.html)).
+
+RustDesk licenses **login users plus managed devices** and runs on a server you host. Standard plans include unlimited concurrent connections; Customized V2 has a defined allowance. Mid-term upgrades may be prorated under current terms. For device counting, see [what counts as a managed device](/blog/what-counts-as-a-managed-device), then verify rates and limits on the current [pricing page](https://rustdesk.com/pricing).
+
+## Built for support teams and MSPs
+
+Self-hosting does not mean going without the tooling a support desk expects. RustDesk Pro includes a [self-hosted web console](/blog/rustdesk-web-console-custom-client-generator-port-21114), a **custom-branded client generator**, and **device groups with a [shared address book](/blog/rustdesk-per-user-access-control-device-groups-shared-address-book)** for per-user access control. [LDAP/AD and OIDC single sign-on](/blog/rustdesk-active-directory-ldap-sso) are available from the Basic plan and up. For teams supporting many clients, that rebuilds the "one console, many technicians, many managed devices" workflow Zoho Assist users expect — on infrastructure you own. If you run a managed-services practice, our [guide for MSPs](/blog/rustdesk-for-msps) goes deeper.
+
+## The honest caveat: someone has to run the server
+
+Here is the trade-off, stated plainly. Self-hosting means **someone on your side runs the server** — you provision a host, open ports, set up TLS, and keep it patched over time. For most IT teams and MSPs that is a modest lift, but it is real work.
+
+Zoho Assist, by contrast, is a mature managed SaaS with a large ecosystem, mobile apps, deep Zoho integrations, and **nothing for you to maintain**. If what you actually want is a zero-maintenance cloud product and you are comfortable with sessions brokered through a vendor, Zoho Assist may be the better fit — and we would rather say so than oversell. RustDesk Server Pro is [self-hosted by design](/blog/rustdesk-self-hosted-vs-cloud-saas-option) and is not a managed cloud service. The upside of owning your infrastructure is inseparable from the responsibility of operating it.
+
+## Evaluate it on your own infrastructure
+
+You don't need a sales call to find out whether this fits:
+
+- **Self-host the free, open-source community server today** — no cost, no expiry — and see how it runs on your own hardware.
+- **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 control and open source are why you are looking past Zoho Assist, a self-hosted alternative is worth an afternoon of evaluation.
diff --git a/v3/src/pages/[...blog]/[category]/[...page].astro b/v3/src/pages/[...blog]/[category]/[...page].astro
index 50fe1b5a..7c3078a7 100644
--- a/v3/src/pages/[...blog]/[category]/[...page].astro
+++ b/v3/src/pages/[...blog]/[category]/[...page].astro
@@ -22,6 +22,164 @@ const { page, category, lang } = Astro.props as Props & { lang: Lang };
const currentPage = page.currentPage ?? 1;
const copy = getBlogCopy(lang);
+const categorySlug = String(category.slug ?? '').toLowerCase();
+const localizedCategoryDescriptions: Record> = {
+ en: {
+ alternatives:
+ 'Evaluate self-hosted and open-source alternatives by deployment model, licensing, security, workflow fit, and migration effort.',
+ comparisons:
+ 'Compare RustDesk with remote-access products and protocols using current requirements, explicit trade-offs, and proof-of-concept criteria.',
+ deployment:
+ 'Plan and operate RustDesk deployments, from server sizing and networking to identity, access control, client rollout, and recovery.',
+ guides:
+ 'Practical guides for evaluating, configuring, and operating RustDesk across platforms, teams, and deployment models.',
+ pricing:
+ 'Understand RustDesk licensing, users, managed devices, concurrency, purchase terms, upgrades, and evaluation options.',
+ security:
+ 'Assess remote-access security, data flows, scams, vulnerabilities, access controls, and deployment hardening without absolute compliance claims.',
+ troubleshooting:
+ 'Diagnose connection, display, configuration, and licensing symptoms with targeted checks and safe escalation paths.',
+ },
+ de: {
+ alternatives:
+ 'Bewerte selbst gehostete und Open-Source-Alternativen nach Bereitstellungsmodell, Lizenzierung, Sicherheit, Workflow-Fit und Migrationsaufwand.',
+ comparisons:
+ 'Vergleiche RustDesk mit Remote-Access-Produkten und -Protokollen anhand aktueller Anforderungen, klarer Abwägungen und Proof-of-Concept-Kriterien.',
+ deployment:
+ 'Plane und betreibe RustDesk-Bereitstellungen, von Server-Größe und Netzwerk bis zu Identität, Zugriffskontrolle, Client-Rollout und Wiederherstellung.',
+ guides:
+ 'Praktische Anleitungen zum Bewerten, Konfigurieren und Betreiben von RustDesk auf verschiedenen Plattformen, in Teams und in unterschiedlichen Bereitstellungsmodellen.',
+ pricing:
+ 'Verstehe RustDesk-Lizenzierung, Nutzer, verwaltete Geräte, Gleichzeitigkeit, Kaufbedingungen, Upgrades und Testoptionen.',
+ security:
+ 'Beurteile Sicherheit, Datenflüsse, Betrugsversuche, Schwachstellen, Zugriffskontrollen und Härtung für Remote-Zugriffe ohne pauschale Compliance-Behauptungen.',
+ troubleshooting:
+ 'Diagnostiziere Verbindungs-, Anzeige-, Konfigurations- und Lizenzsymptome mit gezielten Prüfungen und sicheren Eskalationspfaden.',
+ },
+ es: {
+ alternatives:
+ 'Evalúa alternativas autoalojadas y de código abierto por modelo de despliegue, licencias, seguridad, ajuste al flujo de trabajo y esfuerzo de migración.',
+ comparisons:
+ 'Compara RustDesk con productos y protocolos de acceso remoto usando requisitos actuales, compensaciones explícitas y criterios de prueba de concepto.',
+ deployment:
+ 'Planifica y opera implementaciones de RustDesk, desde el tamaño del servidor y la red hasta la identidad, el control de acceso, el despliegue de clientes y la recuperación.',
+ guides:
+ 'Guías prácticas para evaluar, configurar y operar RustDesk en distintas plataformas, equipos y modelos de despliegue.',
+ pricing:
+ 'Entiende la licencia de RustDesk, usuarios, dispositivos gestionados, concurrencia, condiciones de compra, actualizaciones y opciones de evaluación.',
+ security:
+ 'Evalúa la seguridad del acceso remoto, los flujos de datos, las estafas, las vulnerabilidades, los controles de acceso y el endurecimiento del despliegue sin afirmaciones absolutas de cumplimiento.',
+ troubleshooting:
+ 'Diagnostica síntomas de conexión, pantalla, configuración y licencias con comprobaciones dirigidas y rutas seguras de escalado.',
+ },
+ fr: {
+ alternatives:
+ 'Évaluez les alternatives auto-hébergées et open source selon le modèle de déploiement, la licence, la sécurité, l’adéquation au flux de travail et l’effort de migration.',
+ comparisons:
+ 'Comparez RustDesk avec des produits et protocoles d’accès à distance à l’aide d’exigences actuelles, de compromis explicites et de critères de preuve de concept.',
+ deployment:
+ 'Planifiez et exploitez des déploiements RustDesk, du dimensionnement des serveurs et du réseau à l’identité, au contrôle d’accès, au déploiement client et à la reprise.',
+ guides:
+ 'Guides pratiques pour évaluer, configurer et exploiter RustDesk sur différentes plateformes, pour diverses équipes et selon plusieurs modèles de déploiement.',
+ pricing:
+ 'Comprenez la licence RustDesk, les utilisateurs, les appareils gérés, la concurrence, les conditions d’achat, les mises à niveau et les options d’évaluation.',
+ security:
+ 'Évaluez la sécurité de l’accès à distance, les flux de données, les arnaques, les vulnérabilités, les contrôles d’accès et le durcissement du déploiement sans affirmation de conformité absolue.',
+ troubleshooting:
+ 'Diagnostiquez les symptômes de connexion, d’affichage, de configuration et de licence avec des vérifications ciblées et des voies d’escalade sûres.',
+ },
+ it: {
+ alternatives:
+ 'Valuta alternative self-hosted e open source per modello di distribuzione, licenze, sicurezza, aderenza al flusso di lavoro e sforzo di migrazione.',
+ comparisons:
+ 'Confronta RustDesk con prodotti e protocolli di accesso remoto usando requisiti attuali, compromessi espliciti e criteri di prova di concetto.',
+ deployment:
+ 'Pianifica e gestisci distribuzioni RustDesk, dal dimensionamento del server e della rete fino a identità, controllo accessi, rollout dei client e ripristino.',
+ guides:
+ 'Guide pratiche per valutare, configurare e gestire RustDesk su piattaforme, team e modelli di distribuzione diversi.',
+ pricing:
+ 'Comprendi la licenza RustDesk, gli utenti, i dispositivi gestiti, la concorrenza, i termini di acquisto, gli upgrade e le opzioni di valutazione.',
+ security:
+ 'Valuta sicurezza, flussi di dati, truffe, vulnerabilità, controlli di accesso e hardening del deployment senza affermazioni assolute di conformità.',
+ troubleshooting:
+ 'Diagnostica sintomi di connessione, schermo, configurazione e licenza con controlli mirati e percorsi di escalation sicuri.',
+ },
+ ja: {
+ alternatives:
+ 'デプロイ形態、ライセンス、セキュリティ、業務フローとの適合性、移行コストでセルフホスト型とオープンソースの代替案を評価します。',
+ comparisons:
+ '最新の要件、明確なトレードオフ、PoC の基準を使って、RustDesk をリモートアクセス製品やプロトコルと比較します。',
+ deployment:
+ 'サーバーの規模設計やネットワークから、ID 管理、アクセス制御、クライアント展開、復旧まで RustDesk の導入と運用を計画します。',
+ guides: 'RustDesk をさまざまなプラットフォーム、チーム、導入形態で評価・設定・運用するための実践ガイドです。',
+ pricing:
+ 'RustDesk のライセンス、ユーザー数、管理デバイス、同時接続、購入条件、アップグレード、評価方法を理解します。',
+ security:
+ 'リモートアクセスのセキュリティ、データフロー、詐欺、脆弱性、アクセス制御、導入時の強化策を、断定的な適合性主張なしで評価します。',
+ troubleshooting: '接続、表示、設定、ライセンスの症状を、的を絞った確認と安全なエスカレーション手順で切り分けます。',
+ },
+ ko: {
+ alternatives:
+ '배포 방식, 라이선스, 보안, 업무 흐름 적합성, 마이그레이션 노력 기준으로 자체 호스팅 및 오픈소스 대안을 평가합니다.',
+ comparisons:
+ '최신 요구사항, 명확한 트레이드오프, PoC 기준을 사용해 RustDesk를 원격 액세스 제품과 프로토콜과 비교합니다.',
+ deployment: '서버 규모와 네트워크부터 ID, 접근 제어, 클라이언트 배포, 복구까지 RustDesk 배포와 운영을 계획합니다.',
+ guides: '다양한 플랫폼, 팀, 배포 모델에서 RustDesk를 평가·구성·운영하는 실용 가이드입니다.',
+ pricing: 'RustDesk 라이선스, 사용자, 관리 장치, 동시성, 구매 조건, 업그레이드, 평가 옵션을 이해합니다.',
+ security:
+ '원격 액세스 보안, 데이터 흐름, 사기, 취약점, 접근 제어, 배포 강화 방안을 절대적인 준수 주장 없이 평가합니다.',
+ troubleshooting: '연결, 화면, 설정, 라이선스 증상을 집중 점검과 안전한 에스컬레이션 경로로 진단합니다.',
+ },
+ pt: {
+ alternatives:
+ 'Avalie alternativas auto-hospedadas e de código aberto por modelo de implantação, licenciamento, segurança, aderência ao fluxo de trabalho e esforço de migração.',
+ comparisons:
+ 'Compare o RustDesk com produtos e protocolos de acesso remoto usando requisitos atuais, trocas explícitas e critérios de prova de conceito.',
+ deployment:
+ 'Planeje e opere implantações do RustDesk, do dimensionamento do servidor e da rede até identidade, controle de acesso, implantação de clientes e recuperação.',
+ guides:
+ 'Guias práticos para avaliar, configurar e operar o RustDesk em diferentes plataformas, equipes e modelos de implantação.',
+ pricing:
+ 'Entenda o licenciamento do RustDesk, usuários, dispositivos gerenciados, concorrência, termos de compra, upgrades e opções de avaliação.',
+ security:
+ 'Avalie a segurança de acesso remoto, fluxos de dados, golpes, vulnerabilidades, controles de acesso e endurecimento da implantação sem alegações absolutas de conformidade.',
+ troubleshooting:
+ 'Diagnostique sintomas de conexão, tela, configuração e licenciamento com verificações direcionadas e caminhos seguros de escalonamento.',
+ },
+ 'zh-cn': {
+ alternatives: '按部署模式、许可、安全性、工作流匹配度和迁移成本评估自托管与开源替代方案。',
+ comparisons: '使用当前需求、明确取舍和概念验证标准，将 RustDesk 与远程访问产品和协议进行比较。',
+ deployment: '规划和运行 RustDesk 部署，从服务器规格和网络，到身份、访问控制、客户端推广和恢复。',
+ guides: '用于在不同平台、团队和部署模式下评估、配置和运行 RustDesk 的实用指南。',
+ pricing: '了解 RustDesk 的许可、用户、受管设备、并发、购买条款、升级和评估选项。',
+ security: '在不做绝对合规断言的前提下，评估远程访问安全、数据流、诈骗、漏洞、访问控制和部署加固。',
+ troubleshooting: '通过有针对性的检查和安全的升级路径，诊断连接、显示、配置和许可问题。',
+ },
+ 'zh-tw': {
+ alternatives: '依部署模式、授權、安全性、工作流程契合度與遷移成本，評估自架與開源替代方案。',
+ comparisons: '使用當前需求、明確取捨與概念驗證標準，將 RustDesk 與遠端存取產品和協定進行比較。',
+ deployment: '規劃並營運 RustDesk 部署，從伺服器規模與網路，到身分、存取控制、用戶端推廣與復原。',
+ guides: '協助在不同平台、團隊與部署模式下評估、設定與營運 RustDesk 的實用指南。',
+ pricing: '了解 RustDesk 的授權、使用者、受管裝置、同時連線、購買條款、升級與評估選項。',
+ security: '在不做絕對合規宣稱的前提下，評估遠端存取安全、資料流、詐騙、漏洞、存取控制與部署強化。',
+ troubleshooting: '透過有針對性的檢查與安全的升級路徑，診斷連線、顯示、設定與授權症狀。',
+ },
+ ar: {
+ alternatives:
+ 'قيّم البدائل ذاتية الاستضافة ومفتوحة المصدر حسب نموذج النشر والترخيص والأمان وملاءمة سير العمل وجهد الانتقال.',
+ comparisons:
+ 'قارن RustDesk بمنتجات وبروتوكولات الوصول عن بُعد باستخدام المتطلبات الحالية والمفاضلات الواضحة ومعايير إثبات المفهوم.',
+ deployment:
+ 'خطّط وشغّل عمليات نشر RustDesk، من تحديد حجم الخادم والشبكة إلى الهوية والتحكم في الوصول وتوزيع العملاء والاستعادة.',
+ guides: 'أدلة عملية لتقييم RustDesk وتهيئته وتشغيله عبر منصات وفرق ونماذج نشر مختلفة.',
+ pricing: 'افهم ترخيص RustDesk والمستخدمين والأجهزة المُدارة والتزامن وشروط الشراء والترقيات وخيارات التقييم.',
+ security:
+ 'قيّم أمان الوصول عن بُعد وتدفقات البيانات وعمليات الاحتيال والثغرات وضوابط الوصول وتقوية النشر دون ادعاءات امتثال مطلقة.',
+ troubleshooting: 'شخّص أعراض الاتصال والعرض والتهيئة والترخيص عبر فحوصات محددة ومسارات تصعيد آمنة.',
+ },
+};
+const categoryDescription =
+ localizedCategoryDescriptions[lang]?.[categorySlug] ?? localizedCategoryDescriptions.en[categorySlug];
const localePaths = (Object.keys(LOCALES) as Lang[]).map((targetLang) => ({
lang: targetLang,
path: getBlogPermalink(targetLang),
@@ -29,7 +187,7 @@ const localePaths = (Object.keys(LOCALES) as Lang[]).map((targetLang) => ({
const metadata = {
title: `${copy.category}: ${category.title}${currentPage > 1 ? ` — ${copy.page} ${currentPage}` : ''}`,
- description: `${copy.subtitle} ${copy.category}: ${category.title}.`,
+ description: categoryDescription ?? `${copy.subtitle} ${copy.category}: ${category.title}.`,
robots: {
index: blogCategoryRobots?.index,
follow: blogCategoryRobots?.follow,
@@ -40,6 +198,11 @@ const metadata = {
{category.title}
+ {
+ categoryDescription && currentPage === 1 && (
+
{categoryDescription}
+ )
+ }
diff --git a/v3/src/pages/[...blog]/index.astro b/v3/src/pages/[...blog]/index.astro
index e16e7232..62103ccb 100644
--- a/v3/src/pages/[...blog]/index.astro
+++ b/v3/src/pages/[...blog]/index.astro
@@ -12,6 +12,7 @@ import { getPostAlternates, getStaticPathsBlogPost, blogPostRobots } from '~/uti
import { findImage } from '~/utils/images';
import type { MetaData } from '~/types';
import RelatedPosts from '~/components/blog/RelatedPosts.astro';
+import BlogFaq from '~/components/blog/BlogFaq.astro';
export const prerender = true;
@@ -68,9 +69,11 @@ const articleData = {
alternateLinks={localePaths}
structuredDataType="article"
articleData={articleData}
+ faqItems={post.faq}
>
{post.Content ? : }
+
diff --git a/v3/src/types.d.ts b/v3/src/types.d.ts
index 02e82e7a..bd4668d4 100644
--- a/v3/src/types.d.ts
+++ b/v3/src/types.d.ts
@@ -37,6 +37,9 @@ export interface Post {
/** */
author?: string;
+ /** Optional Q&A pairs rendered as FAQPage structured data. */
+ faq?: Array<{ question: string; answer: string }>;
+
/** */
metadata?: MetaData;
diff --git a/v3/src/utils/blog-i18n.mjs b/v3/src/utils/blog-i18n.mjs
index 7849ef0a..98222fbf 100644
--- a/v3/src/utils/blog-i18n.mjs
+++ b/v3/src/utils/blog-i18n.mjs
@@ -42,6 +42,8 @@ export function validatePostTranslations(posts, locales) {
}
for (const [translationKey, group] of groupPostsByTranslationKey(posts)) {
+ if (group.length === 1) continue;
+
for (const locale of locales) {
const count = group.filter((post) => post.lang === locale).length;
if (count === 0) {
diff --git a/v3/src/utils/blog.ts b/v3/src/utils/blog.ts
index 854b2b9b..bd3ef134 100644
--- a/v3/src/utils/blog.ts
+++ b/v3/src/utils/blog.ts
@@ -59,6 +59,7 @@ const getNormalizedPost = async (post: CollectionEntry<'post'>): Promise =
tags: rawTags = [],
category: rawCategory,
author,
+ faq,
draft = false,
metadata = {},
lang,
@@ -98,6 +99,7 @@ const getNormalizedPost = async (post: CollectionEntry<'post'>): Promise =
category: category,
tags: tags,
author: author,
+ faq: faq,
draft: draft,
diff --git a/v3/tests/blog-i18n.test.mjs b/v3/tests/blog-i18n.test.mjs
index dcd0de38..9387ddd4 100644
--- a/v3/tests/blog-i18n.test.mjs
+++ b/v3/tests/blog-i18n.test.mjs
@@ -43,6 +43,10 @@ test('reports missing locales and duplicate locale entries', () => {
);
});
+test('allows a post to publish in one locale before translations exist', () => {
+ assert.doesNotThrow(() => validatePostTranslations([posts[0]], ['en', 'zh-cn', 'de']));
+});
+
test('rejects unsupported locales and duplicate slugs in one locale', () => {
assert.throws(() => validatePostTranslations([{ ...posts[0], lang: 'xx' }], ['en']), /unsupported locale xx/i);
assert.throws(
diff --git a/v3/tests/blog-publication-review.test.mjs b/v3/tests/blog-publication-review.test.mjs
new file mode 100644
index 00000000..1dce3270
--- /dev/null
+++ b/v3/tests/blog-publication-review.test.mjs
@@ -0,0 +1,308 @@
+import assert from 'node:assert/strict';
+import { existsSync, readFileSync, readdirSync } from 'node:fs';
+import { join } from 'node:path';
+import test from 'node:test';
+
+const root = new URL('..', import.meta.url).pathname;
+const postsDir = join(root, 'src/content/post/en');
+const read = (path) => readFileSync(join(root, path), 'utf8');
+const readPost = (name) => readFileSync(join(postsDir, name), 'utf8');
+
+test('uses a verified organizational byline for the reviewed publication batch', () => {
+ const affected = readdirSync(postsDir)
+ .filter((name) => name.endsWith('.md') || name.endsWith('.mdx'))
+ .filter((name) => readPost(name).includes('author: Hoabing Ziu, CTO'));
+
+ assert.deepEqual(affected, []);
+});
+
+test('renders post FAQ data visibly and attributes RustDesk Team to the organization schema', () => {
+ const route = read('src/pages/[...blog]/index.astro');
+ const faqComponent = read('src/components/blog/BlogFaq.astro');
+ const structuredData = read('src/components/common/StructuredData.astro');
+
+ assert.match(route, //);
+ assert.match(faqComponent, /]*>Frequently asked questions<\/h2>/);
+ assert.match(faqComponent, /item\.question/);
+ assert.match(faqComponent, /item\.answer/);
+ assert.match(structuredData, /article\.author === 'RustDesk Team'/);
+ assert.match(structuredData, /author: articleAuthorSchema/);
+});
+
+test('requires a protected path before entering initial web-console credentials', () => {
+ const article = readPost('rustdesk-web-console-custom-client-generator-port-21114.md');
+
+ assert.match(article, /do not enter credentials over plain HTTP on a public or untrusted network\./i);
+ assert.match(article, /localhost, an SSH tunnel, or a trusted private network/);
+});
+
+test('limits no-inbound-port and iOS host claims in the RDP comparison', () => {
+ const article = readPost('rustdesk-vs-rdp.md');
+
+ assert.match(article, /endpoint clients initiate outbound connections/);
+ assert.match(article, /self-hosted server still accepts inbound connections/);
+ assert.match(article, /iOS acts as a controller only/);
+ assert.doesNotMatch(article, /controlling and being controlled/);
+ assert.doesNotMatch(article, /Host platforms\s*\|[^\n]*iOS/);
+});
+
+test('does not claim that self-hosted RustDesk exposes nothing inbound', () => {
+ const affected = readdirSync(postsDir)
+ .filter((name) => name.endsWith('.md') || name.endsWith('.mdx'))
+ .filter((name) => /nothing inbound is exposed/i.test(readPost(name)));
+
+ assert.deepEqual(affected, []);
+});
+
+test('uses protocol-specific RustDesk server port guidance', () => {
+ const article = readPost('rustdesk-connected-waiting-for-image.md');
+
+ assert.doesNotMatch(article, /TCP\/UDP 21115-21119/);
+ assert.match(article, /TCP 21115-21117 and UDP 21116/);
+ assert.match(article, /TCP 21118-21119 only if you use WebSocket clients/);
+});
+
+test('states the evidence and limits behind the large-fleet capacity example', () => {
+ const article = readPost('rustdesk-scale-50000-200000-devices.md');
+
+ assert.match(article, /more than two million online endpoints/);
+ assert.match(article, /12-core CPU and 32 GB of RAM/);
+ assert.match(article, /not two million simultaneous remote-control sessions/);
+ assert.match(article, /production observation, not a reproducible Server Pro benchmark/);
+ assert.doesNotMatch(article, /one million|million-plus/i);
+});
+
+test('lists first-party ScreenConnect sources promised by the comparison', () => {
+ const article = readPost('rustdesk-vs-screenconnect.md');
+
+ assert.match(article, /## Sources/);
+ assert.match(article, /https:\/\/www\.screenconnect\.com\/pricing/);
+ assert.match(
+ article,
+ /https:\/\/docs\.connectwise\.com\/ScreenConnect_Documentation\/Get_started\/Host_client\/Host_client_requirements/
+ );
+ assert.match(
+ article,
+ /https:\/\/www\.connectwise\.com\/company\/trust\/security-bulletins\/connectwise-screenconnect-23\.9\.8/
+ );
+});
+
+test('opens only the RustDesk ports required by each deployed feature', () => {
+ const article = readPost('why-self-host-remote-desktop-software.md');
+
+ assert.doesNotMatch(article, /default ports are \*\*21114–21119\*\*/);
+ assert.match(article, /TCP 21115-21117 and UDP 21116/);
+ assert.match(article, /expose only TCP 443 publicly/);
+ assert.match(article, /keep 21114 and 21118-21119 internal/);
+});
+
+test('limits the no-code scam advice to the typical social-engineering flow', () => {
+ const article = readPost('avoid-remote-desktop-scams.md');
+
+ assert.doesNotMatch(article, /they cannot simply connect/);
+ assert.match(article, /typical social-engineering flow/);
+ assert.match(
+ article,
+ /does not rule out existing unattended access, stolen credentials, malware, or exposed services/
+ );
+});
+
+test('distinguishes Splashtop cloud plans from Splashtop On-Prem', () => {
+ const article = readPost('rustdesk-vs-splashtop.md');
+
+ assert.match(article, /managed SaaS plans and a \*\*separately licensed On-Prem\*\* product/);
+ assert.match(article, /https:\/\/www\.splashtop\.com\/products\/on-prem/);
+ assert.match(article, /customer-operated Splashtop (?:On-Prem )?Gateway/i);
+ assert.doesNotMatch(article, /It remains a managed cloud service/);
+ assert.doesNotMatch(article, /Splashtop is a cloud service/);
+});
+
+test('consolidates Splashtop comparisons without erasing the On-Prem product', () => {
+ const removedSlug = 'teamviewer-vs-anydesk-vs-splashtop';
+ const teamViewerComparison = readPost('teamviewer-vs-splashtop.md');
+ const rustDeskComparison = readPost('rustdesk-vs-splashtop.md');
+ const mspComparison = readPost('teamviewer-vs-anydesk-for-msps.md');
+ const netlify = read('netlify.toml');
+ const vercel = read('vercel.json');
+
+ assert.equal(existsSync(join(postsDir, `${removedSlug}.md`)), false);
+ assert.equal(existsSync(join(root, `src/assets/images/blog/${removedSlug}-og.png`)), false);
+ assert.doesNotMatch(mspComparison, new RegExp(`/blog/${removedSlug}`));
+ assert.match(
+ netlify,
+ new RegExp(`from = "/blog/${removedSlug}"[\\s\\S]*?to = "/blog/teamviewer-vs-splashtop"[\\s\\S]*?status = 301`)
+ );
+ assert.match(
+ vercel,
+ new RegExp(
+ `"source": "/blog/${removedSlug}"[\\s\\S]*?"destination": "/blog/teamviewer-vs-splashtop"[\\s\\S]*?"permanent": true`
+ )
+ );
+
+ for (const article of [teamViewerComparison, rustDeskComparison]) {
+ assert.match(article, /separately licensed On-Prem/i);
+ assert.match(article, /Splashtop (?:On-Prem )?Gateway/i);
+ assert.doesNotMatch(article, /Splashtop[^\n]*cloud only/i);
+ assert.doesNotMatch(article, /(?:almost|hardly|nearly) (?:no one|nobody)|few customers use/i);
+ }
+});
+
+test('positions the Splashtop alternative page as an evidence-bounded IT switching guide', () => {
+ const article = readPost('rustdesk-vs-splashtop.md');
+
+ assert.match(article, /title: 'Self-Hosted Splashtop Alternative: What IT Teams Should Evaluate Before Switching'/);
+ assert.match(article, /excerpt: 'A self-hosted Splashtop alternative evaluation guide/);
+ assert.match(article, /## Why IT teams evaluate alternatives to Splashtop/);
+ assert.match(article, /do not establish how common/i);
+ assert.match(article, /integration-specific/i);
+ assert.match(article, /remote audio/i);
+ assert.match(article, /monitor mapping/i);
+ assert.match(article, /parallel pilot/i);
+ assert.match(article, /rollback/i);
+ assert.doesNotMatch(article, /72 (?:signals|customers|emails)|3\/72/);
+ assert.doesNotMatch(article, /Kent Tec|Kimray|KinderCare|Liberty Tax|WaliaTech/);
+ assert.doesNotMatch(article, /£50|£200|\$8K|\$8000/);
+});
+
+test('describes the exploited ScreenConnect vulnerability without calling it a ConnectWise hack', () => {
+ const article = readPost('best-screenconnect-alternative-msps.md');
+
+ assert.doesNotMatch(article, /ConnectWise hack|remote-access vendor gets breached/i);
+ assert.match(article, /exploitation of CVE-2024-1709 in affected ScreenConnect servers/);
+});
+
+test('does not impose a personal-use-only license on Chrome Remote Desktop', () => {
+ const article = readPost('best-free-remote-desktop-software.md');
+
+ assert.doesNotMatch(
+ article,
+ /Chrome Remote Desktop is free but licensed for personal use|terms center on personal use/
+ );
+ assert.match(article, /Google documents enterprise administration policies/);
+ assert.match(article, /https:\/\/support\.google\.com\/chrome\/a\/answer\/2799701/);
+});
+
+test('separates Chrome Remote Desktop signaling from direct and relayed session traffic', () => {
+ const article = readPost('chrome-remote-desktop-alternative.md');
+
+ assert.doesNotMatch(article, /every session runs through Google/i);
+ assert.match(article, /initially negotiated through Google services/);
+ assert.match(article, /Direct, STUN, or TURN\/relay/);
+ assert.match(article, /https:\/\/support\.google\.com\/chrome\/a\/answer\/16364503/);
+});
+
+test('does not lean on a competitor blog for the Chrome Remote Desktop limitations section', () => {
+ const article = readPost('chrome-remote-desktop-alternative.md');
+
+ assert.doesNotMatch(article, /helpwire\.app\/blog\/chrome-remote-desktop/i);
+ assert.match(article, /https:\/\/support\.google\.com\/chrome\/answer\/1649523/);
+ assert.match(article, /https:\/\/support\.google\.com\/chrome\/a\/answer\/16364503/);
+});
+
+test('does not present RustDesk iOS as an unattended host in the Chrome Remote Desktop comparison', () => {
+ const article = readPost('chrome-remote-desktop-alternative.md');
+
+ assert.doesNotMatch(
+ article,
+ /Real file transfer and permanent-password unattended access come standard, across Windows, macOS, Linux, Android, and iOS\./
+ );
+ assert.match(article, /the iOS app is controller-only/);
+});
+
+test('does not explain AnyDesk commercial-use detection through mandatory cloud relay', () => {
+ const article = readPost('anydesk-commercial-use-detected.md');
+
+ assert.doesNotMatch(article, /every session runs through _their_ cloud/);
+ assert.match(article, /AnyDesk supports direct client-to-client connections/);
+ assert.match(article, /https:\/\/support\.anydesk\.com\/docs\/settings/);
+});
+
+test('labels the public-server capacity number as a non-audited point-in-time internal observation', () => {
+ const article = readPost('rustdesk-scale-50000-200000-devices.md');
+
+ assert.match(article, /point-in-time internal production observation recorded on July 7, 2026/);
+ assert.match(article, /not independently audited/);
+ assert.match(article, /no public monitoring dashboard/);
+ assert.doesNotMatch(article, /has operated stably/);
+});
+
+test('sources AnyDesk plan limits from the current official pricing page', () => {
+ const article = readPost('rustdesk-vs-anydesk.md');
+
+ assert.match(article, /https:\/\/anydesk\.com\/en\/pricing/);
+ assert.match(article, /checked July 7, 2026/);
+ assert.doesNotMatch(article, /third-party pricing trackers|Independent trackers/);
+});
+
+test('splits RustDesk iOS controller support from host features in the free-software roundup', () => {
+ const article = readPost('best-free-remote-desktop-software.md');
+
+ assert.doesNotMatch(
+ article,
+ /cross-platform \(Windows, macOS, Linux, Android, iOS\), with file transfer and unattended access/i
+ );
+ assert.match(article, /Windows, macOS, Linux, and Android hosts; iOS is a controller app/);
+});
+
+test('sources and bounds TeamViewer and Splashtop security claims', () => {
+ const article = readPost('teamviewer-vs-splashtop.md');
+
+ assert.match(article, /https:\/\/www\.splashtop\.com\/security/);
+ assert.match(article, /https:\/\/www\.splashtop\.com\/press\/splashtop-achieves-iso-iec-27001-2022-certification/);
+ assert.match(article, /https:\/\/www\.teamviewer\.com\/en\/resources\/trust-center/);
+ assert.match(article, /tv-2024-1005/);
+ assert.doesNotMatch(article, /no publicly disclosed breach/);
+});
+
+test('removes the unsupported claim that AnyDesk detection became stricter in 2025', () => {
+ const article = readPost('anydesk-commercial-use-detected.md');
+
+ assert.doesNotMatch(article, /got stricter in 2025|became stricter in 2025/i);
+});
+
+test('uses AnyDesk official pricing instead of unnamed trackers in the MSP FAQ', () => {
+ const article = readPost('teamviewer-vs-anydesk-for-msps.md');
+
+ assert.doesNotMatch(article, /Multiple trackers|multiple trackers reporting/i);
+ assert.match(article, /https:\/\/anydesk\.com\/en\/pricing/);
+ assert.match(article, /official pricing page, checked July 7, 2026/);
+});
+
+test('explains why RustDesk is unavailable on Google Play and gives current Android sources', () => {
+ const article = readPost('rustdesk-remote-control-android-ios.md');
+
+ assert.doesNotMatch(article, /install (?:the app )?from Google Play/i);
+ assert.doesNotMatch(article, /Android client is on Google Play/i);
+ assert.match(article, /not currently distributed through Google Play/i);
+ assert.match(article, /\/blog\/rustdesk-and-remote-access-scams/);
+ assert.match(article, /github\.com\/rustdesk\/rustdesk\/releases/);
+ assert.match(article, /f-droid\.org\/packages\/com\.carriez\.flutter_hbb/);
+});
+
+test('documents RustDesk anti-scam actions and controlled-device defenses', () => {
+ const article = readPost('rustdesk-and-remote-access-scams.md');
+
+ assert.match(article, /x\.com\/rustdesk\/status\/1698372220379349421/);
+ assert.match(article, /github\.com\/rustdesk\/rustdesk\/discussions\/5660/);
+ assert.match(article, /Login-required-for-public-server/);
+ assert.match(article, /strong, unique permanent password/i);
+ assert.match(article, /controlled device[^\n]*2FA|2FA[^\n]*controlled device/i);
+ assert.match(article, /IP allowlist/i);
+ assert.match(article, /\/32/);
+ assert.match(article, /\/24/);
+ assert.match(article, /\/128/);
+ assert.match(article, /\/64/);
+ assert.doesNotMatch(article, /Server Pro (?:account|web-console) 2FA/i);
+});
+
+test('uses Server Pro Access Control rather than address-book visibility for authorization', () => {
+ const article = readPost('rustdesk-per-user-access-control-device-groups-shared-address-book.md');
+
+ assert.match(article, /https:\/\/rustdesk\.com\/docs\/en\/self-host\/rustdesk-server-pro\/permissions\//);
+ assert.match(article, /address book[^\n]*(?:visibility|convenience)[^\n]*not[^\n]*authorization/i);
+ assert.match(article, /user assignments, device groups, and cross-group access settings/i);
+ assert.match(article, /permissions are cumulative/i);
+ assert.match(article, /known device ID/i);
+ assert.doesNotMatch(article, /working approach today[^\n]*shared address book/i);
+ assert.doesNotMatch(article, /per-user access control today[^\n]*shared address book/i);
+});
diff --git a/v3/vercel.json b/v3/vercel.json
index 35262826..4f977018 100644
--- a/v3/vercel.json
+++ b/v3/vercel.json
@@ -11,5 +11,177 @@
}
]
}
+ ],
+ "redirects": [
+ {
+ "source": "/blog/teamviewer-vs-anydesk-vs-splashtop",
+ "destination": "/blog/teamviewer-vs-splashtop",
+ "permanent": true
+ },
+ {
+ "source": "/ar/blog/2024/10/muayinat-rustdesk-web-client-v2",
+ "destination": "/ar/blog/muayinat-rustdesk-web-client-v2",
+ "permanent": true
+ },
+ {
+ "source": "/ar/blog/2024/12/tashghil-flutter-3-24-ala-windows-7",
+ "destination": "/ar/blog/tashghil-flutter-3-24-ala-windows-7",
+ "permanent": true
+ },
+ {
+ "source": "/ar/blog/2025/02/tahsin-acl-fi-rustdesk-server-pro-1-5-0",
+ "destination": "/ar/blog/tahsin-acl-fi-rustdesk-server-pro-1-5-0",
+ "permanent": true
+ },
+ {
+ "source": "/blog/2024/10/rustdesk-web-client-v2-preview",
+ "destination": "/blog/rustdesk-web-client-v2-preview",
+ "permanent": true
+ },
+ {
+ "source": "/blog/2024/12/how-to-make-flutter-3-24-run-on-windows-7",
+ "destination": "/blog/how-to-make-flutter-3-24-run-on-windows-7",
+ "permanent": true
+ },
+ {
+ "source": "/blog/2025/02/enhanced-acl-in-rustdesk-server-pro-1-5-0",
+ "destination": "/blog/enhanced-acl-in-rustdesk-server-pro-1-5-0",
+ "permanent": true
+ },
+ {
+ "source": "/de/blog/2024/10/vorschau-rustdesk-web-client-v2",
+ "destination": "/de/blog/vorschau-rustdesk-web-client-v2",
+ "permanent": true
+ },
+ {
+ "source": "/de/blog/2024/12/flutter-3-24-unter-windows-7-ausfuehren",
+ "destination": "/de/blog/flutter-3-24-unter-windows-7-ausfuehren",
+ "permanent": true
+ },
+ {
+ "source": "/de/blog/2025/02/erweiterte-acl-in-rustdesk-server-pro-1-5-0",
+ "destination": "/de/blog/erweiterte-acl-in-rustdesk-server-pro-1-5-0",
+ "permanent": true
+ },
+ {
+ "source": "/es/blog/2024/10/vista-previa-cliente-web-rustdesk-v2",
+ "destination": "/es/blog/vista-previa-cliente-web-rustdesk-v2",
+ "permanent": true
+ },
+ {
+ "source": "/es/blog/2024/12/ejecutar-flutter-3-24-en-windows-7",
+ "destination": "/es/blog/ejecutar-flutter-3-24-en-windows-7",
+ "permanent": true
+ },
+ {
+ "source": "/es/blog/2025/02/acl-mejoradas-rustdesk-server-pro-1-5-0",
+ "destination": "/es/blog/acl-mejoradas-rustdesk-server-pro-1-5-0",
+ "permanent": true
+ },
+ {
+ "source": "/fr/blog/2024/10/apercu-client-web-rustdesk-v2",
+ "destination": "/fr/blog/apercu-client-web-rustdesk-v2",
+ "permanent": true
+ },
+ {
+ "source": "/fr/blog/2024/12/executer-flutter-3-24-sous-windows-7",
+ "destination": "/fr/blog/executer-flutter-3-24-sous-windows-7",
+ "permanent": true
+ },
+ {
+ "source": "/fr/blog/2025/02/acl-ameliorees-rustdesk-server-pro-1-5-0",
+ "destination": "/fr/blog/acl-ameliorees-rustdesk-server-pro-1-5-0",
+ "permanent": true
+ },
+ {
+ "source": "/it/blog/2024/10/anteprima-client-web-rustdesk-v2",
+ "destination": "/it/blog/anteprima-client-web-rustdesk-v2",
+ "permanent": true
+ },
+ {
+ "source": "/it/blog/2024/12/eseguire-flutter-3-24-su-windows-7",
+ "destination": "/it/blog/eseguire-flutter-3-24-su-windows-7",
+ "permanent": true
+ },
+ {
+ "source": "/it/blog/2025/02/acl-migliorate-rustdesk-server-pro-1-5-0",
+ "destination": "/it/blog/acl-migliorate-rustdesk-server-pro-1-5-0",
+ "permanent": true
+ },
+ {
+ "source": "/ja/blog/2024/10/rustdesk-web-client-v2-preview-ja",
+ "destination": "/ja/blog/rustdesk-web-client-v2-preview-ja",
+ "permanent": true
+ },
+ {
+ "source": "/ja/blog/2024/12/flutter-3-24-windows-7-de-ugokasu-houhou",
+ "destination": "/ja/blog/flutter-3-24-windows-7-de-ugokasu-houhou",
+ "permanent": true
+ },
+ {
+ "source": "/ja/blog/2025/02/rustdesk-server-pro-1-5-0-acl-kyouka",
+ "destination": "/ja/blog/rustdesk-server-pro-1-5-0-acl-kyouka",
+ "permanent": true
+ },
+ {
+ "source": "/ko/blog/2024/10/rustdesk-web-client-v2-miribogi",
+ "destination": "/ko/blog/rustdesk-web-client-v2-miribogi",
+ "permanent": true
+ },
+ {
+ "source": "/ko/blog/2024/12/windows-7-flutter-3-24-silhaeng-haneun-bangbeop",
+ "destination": "/ko/blog/windows-7-flutter-3-24-silhaeng-haneun-bangbeop",
+ "permanent": true
+ },
+ {
+ "source": "/ko/blog/2025/02/rustdesk-server-pro-1-5-0-hyangsangdoen-acl",
+ "destination": "/ko/blog/rustdesk-server-pro-1-5-0-hyangsangdoen-acl",
+ "permanent": true
+ },
+ {
+ "source": "/pt/blog/2024/10/previa-cliente-web-rustdesk-v2",
+ "destination": "/pt/blog/previa-cliente-web-rustdesk-v2",
+ "permanent": true
+ },
+ {
+ "source": "/pt/blog/2024/12/executar-flutter-3-24-no-windows-7",
+ "destination": "/pt/blog/executar-flutter-3-24-no-windows-7",
+ "permanent": true
+ },
+ {
+ "source": "/pt/blog/2025/02/acl-aprimorada-rustdesk-server-pro-1-5-0",
+ "destination": "/pt/blog/acl-aprimorada-rustdesk-server-pro-1-5-0",
+ "permanent": true
+ },
+ {
+ "source": "/zh-cn/blog/2024/10/rustdesk-web-ke-hu-duan-v2-yu-lan",
+ "destination": "/zh-cn/blog/rustdesk-web-ke-hu-duan-v2-yu-lan",
+ "permanent": true
+ },
+ {
+ "source": "/zh-cn/blog/2024/12/ru-he-rang-flutter-3-24-yun-xing-yu-windows-7",
+ "destination": "/zh-cn/blog/ru-he-rang-flutter-3-24-yun-xing-yu-windows-7",
+ "permanent": true
+ },
+ {
+ "source": "/zh-cn/blog/2025/02/rustdesk-server-pro-1-5-0-zeng-qiang-acl",
+ "destination": "/zh-cn/blog/rustdesk-server-pro-1-5-0-zeng-qiang-acl",
+ "permanent": true
+ },
+ {
+ "source": "/zh-tw/blog/2024/10/rustdesk-web-yong-hu-duan-v2-yu-lan",
+ "destination": "/zh-tw/blog/rustdesk-web-yong-hu-duan-v2-yu-lan",
+ "permanent": true
+ },
+ {
+ "source": "/zh-tw/blog/2024/12/ru-he-rang-flutter-3-24-zai-windows-7-shang-zhi-xing",
+ "destination": "/zh-tw/blog/ru-he-rang-flutter-3-24-zai-windows-7-shang-zhi-xing",
+ "permanent": true
+ },
+ {
+ "source": "/zh-tw/blog/2025/02/rustdesk-server-pro-1-5-0-qiang-hua-acl",
+ "destination": "/zh-tw/blog/rustdesk-server-pro-1-5-0-qiang-hua-acl",
+ "permanent": true
+ }
]
}