· RustDesk Team · Guide · 5 min di lettura
Perché fare self-hosting del tuo software di desktop remoto
Perché i team che abbandonano TeamViewer e AnyDesk scelgono di fare self-hosting del desktop remoto: controllo dei dati, costi prevedibili e nessun cloud di mezzo.
La maggior parte degli strumenti di desktop remoto viene venduta in un solo modo: come abbonamento cloud, con i server del fornitore che fanno da intermediari — e spesso da relay — per ogni sessione. Esiste un altro modo di gestire l’accesso remoto, e non è nuovo: è semplicemente meno pubblicizzato, perché non porta con sé un abbonamento cloud ricorrente. È la scelta di fare self-hosting del proprio software di desktop remoto: eseguire, su un’infrastruttura sotto il proprio controllo, il server che coordina le connessioni e inoltra il traffico quando la connettività diretta non è disponibile. Questo articolo espone le ragioni a favore di questo modello e utilizza RustDesk come esempio concreto.
Cosa significa realmente “self-host” per il desktop remoto
Il prezzo della comodità del solo cloud è che l’elenco dei dispositivi, i metadati di connessione e talvolta il traffico stesso della sessione passano attraverso una terza parte, soggetti al suo uptime, ai suoi prezzi e al suo livello di sicurezza.
Il self-hosting ribalta questo schema. Con RustDesk Server Pro, il server ID/rendezvous, il relay, la console e i dati di distribuzione memorizzati vengono eseguiti sulla tua infrastruttura. Le sessioni dirette continuano a fluire tra gli endpoint; le sessioni inoltrate (relayed) utilizzano il relay che hai configurato. RustDesk è open source (AGPL) e il server community gratuito può essere eseguito a tempo indeterminato.
Solo cloud vs. self-hosted, in sintesi
| Strumento tipico solo cloud | Self-hosted (RustDesk Server Pro) | |
|---|---|---|
| Dove vengono intermediate le sessioni | Cloud del fornitore | Il tuo box on-prem o VPS |
| Residenza dei dati | Controllata dal fornitore | I servizi lato server vengono eseguiti su un’infrastruttura che controlli; i percorsi degli endpoint restano comunque rilevanti |
| Limiti di connessioni simultanee | Spesso per canale/postazione | Piani standard illimitati; Customized V2 a consumo |
| Modello di prezzo | Abbonamento cloud per postazione/canale | Per utente di accesso + per dispositivo gestito (pricing) |
| Codice sorgente | Chiuso | Open source (AGPL), verificabile |
| Dipendenza da interruzioni | Uptime del fornitore | Le tue operazioni |
| Chi gestisce il server | Il fornitore | Tu |
Il self-hosting non significa rinunciare a scalabilità o funzionalità. RustDesk pubblica linee guida per la pianificazione di grandi flotte per i team che devono supportare parchi dispositivi più grandi. Per gli MSP e l’IT interno è disponibile una console web self-hosted, un generatore di client con marchio personalizzato, e gruppi di dispositivi con una rubrica condivisa per il controllo degli accessi per singolo utente. LDAP/SSO (OIDC) è disponibile a partire dal piano Basic.
Cosa comporta realmente gestire il server
Il controllo comporta un certo lavoro operativo — meno di quanto la maggior parte dei team si aspetti, e per lo più una tantum. Ecco la realtà concreta:
- Predisponi un host. I requisiti hardware di RustDesk sono minimi, quindi una modesta VM Linux — on-prem o un VPS economico — è sufficiente per eseguire i servizi ID/rendezvous e relay. Dimensionala in base al numero di dispositivi e alla quantità di traffico che finisce per essere inoltrato (relayed) anziché peer-to-peer.
- Apri solo le porte che utilizzi. I client RustDesk nativi richiedono TCP 21115-21117 e UDP 21116 per il test NAT, i servizi di connessione, la registrazione, l’heartbeat e il relay. Non esporre l’intero intervallo 21114-21119. TCP 21118-21119 sono i backend WebSocket, mentre TCP 21114 è il backend dell’API HTTP/console Pro. Quando un reverse proxy HTTPS/WSS fa da front-end all’API Pro e ai servizi WebSocket, esponi pubblicamente solo TCP 443 per quel traffico e mantieni 21114 e 21118-21119 interni. La porta pubblica 443 non sostituisce le porte principali dei client nativi quando anche i client nativi si connettono. Consulta il riferimento ufficiale delle porte.
- Configura il TLS. Termina HTTPS e WSS a livello di reverse proxy in modo che le credenziali, le chiamate API e il traffico del client browser utilizzino la porta pubblica TCP 443, invece di esporre la console/API in HTTP semplice o i backend WebSocket non cifrati.
- Esegui i backup. Il server contiene l’inventario dei dispositivi, gli account utente, la rubrica e le regole di accesso. Pianifica i backup — e verifica realmente di riuscire a ripristinarli.
- Mantieni una cadenza di patch. Nel tempo vengono rilasciate nuove build del server, e il sistema operativo sottostante è di tua responsabilità. Decidi chi applica gli aggiornamenti e con quale frequenza.
- Monitoralo. Il servizio di coordinamento è ora tuo, quindi tieni sotto controllo uptime, spazio disco e throughput del relay, e gestisci in prima persona gli alert e il ripristino.
Niente di tutto questo è particolarmente esotico, e gran parte è configurazione una tantum. Se sorge una domanda in qualsiasi momento, il supporto RustDesk può aiutarti a risolverla.
Come valutare il self-hosting
- Inizia con il server community. Il core è AGPL: puoi distribuire il server open source gratuito già questo pomeriggio, sottoporlo ad audit ed eseguirlo per tutto il tempo che vuoi senza alcun costo.
- Ti serve il set di funzionalità Pro? Le tariffe dei piani attuali sono disponibili su rustdesk.com/pricing, e [email protected] può indicarti quali opzioni di valutazione sono disponibili al momento.
- Preferisci guardare piuttosto che installare? È disponibile una demo video completa sul canale YouTube di RustDesk.
Se sono stati gli aumenti di prezzo, il codice chiuso o un cloud che non controlli a spingerti a cercare alternative, il self-hosting è la soluzione strutturale, non semplicemente uno sconto. Per un team che gestisce già un’infrastruttura, è un passo successivo, non un salto: possiedi il server, possiedi i dati, possiedi i costi.
Frequently asked questions
Cosa significa fare self-hosting del software di desktop remoto?
Significa eseguire, su un'infrastruttura sotto il proprio controllo, il server che coordina le connessioni e inoltra il traffico quando la connettività diretta non è possibile, invece di instradare le sessioni attraverso il cloud di un fornitore. Con RustDesk Server Pro, il server ID/rendezvous, il relay, la console e i dati di distribuzione memorizzati vengono eseguiti sulla propria infrastruttura.
Cosa comporta realmente la gestione di un server RustDesk self-hosted?
I requisiti hardware sono minimi e la maggior parte del lavoro è una tantum: si predispone un piccolo host Linux, si aprono solo le porte effettivamente utilizzate (i client nativi richiedono TCP 21115-21117 e UDP 21116), si configura il TLS su un reverse proxy e si pianificano i backup; dopodiché si tratta di normale applicazione di patch e monitoraggio, con il supporto RustDesk disponibile in caso di difficoltà.
Il self-hosting aiuta con la residenza dei dati e la conformità al GDPR?
Sì: in questo ambito offre un controllo reale, perché sei tu a scegliere dove vengono eseguiti il rendezvous, il relay, la console e i dati dei dispositivi. Si tratta però di una base di partenza e non di una garanzia assoluta, perché le connessioni dirette continuano comunque a viaggiare tra gli endpoint: mantenere il traffico all'interno del paese e rispettare gli obblighi del GDPR dipende quindi anche da come instradi e gestisci la distribuzione.
Il self-hosting è adatto a ogni team?
Il self-hosting è adatto ai team che vogliono avere il controllo dei propri dati e della propria infrastruttura. Comporta effettivamente la gestione di un server — un impegno modesto e per lo più una tantum in fase di configurazione — quindi se preferisci non gestire alcun server, un SaaS gestito rappresenta il modello alternativo. Ma RustDesk Server Pro è progettato fin dall'origine per essere self-hosted, proprio affinché i tuoi dati restino sulla tua infrastruttura senza alcun cloud di un fornitore di mezzo — e per i team che gestiscono già un'infrastruttura, questo controllo è proprio il punto centrale.
