Gli strumenti RPA open source da considerare e dove eseguirli

Diversi strumenti presenti in una tipica selezione di RPA open source non possono funzionare su un server Linux privo di ambiente grafico. Automatizzano interfacce desktop e dipendono da una sessione grafica, mentre un server senza desktop non ha alcuna sessione da controllare. Questa sola proprietà divide la categoria in due e determina dove può funzionare il bot.

Le licenze commerciali RPA sono il motivo principale delle ricerche dei migliori strumenti RPA open source. Ho ricontrollato i dati su licenze, attività e pacchetti riportati sotto il 5 ottobre 2026. Ogni affermazione sullo stato rimanda alla fonte da cui proviene.

Punti chiave

• Parti dai requisiti della sessione, non dall'elenco delle funzionalità. Oculix, OpenRPA e taskt privilegiano le interfacce grafiche e richiedono una sessione grafica per lavorare sul desktop locale. RPA Framework non la richiede per browser, file e dati. Per TagUI e UI.Vision dipende dalla modalità utilizzata.
• RPA Framework ha pubblicato versioni a febbraio, marzo, maggio, giugno, agosto e ottobre 2026: la cadenza di rilascio più costante verificata qui.
• TagUI è sotto Apache-2.0 e accetta ancora contributi, ma AI Singapore ne ha interrotto manutenzione e supporto. Il suo wrapper Python non ha ricevuto nuove versioni da luglio 2023.
• Automagica e OpenBots non appartengono a una selezione attuale. Automagica ha abbandonato AGPL3 quando Netcall ha acquisito l'azienda nell'ottobre 2020, e OpenBots non ha un repository pubblico mantenuto per un prodotto RPA.
• Se i sistemi da collegare espongono già API o webhook, serve l'automazione dei workflow, non RPA. Categoria diversa, strumenti diversi, sviluppo molto più breve.

Cosa questo articolo non tratta

Tre domande vicine restano fuori dall'ambito, ciascuna per un motivo diverso.

• Piattaforme commerciali con piani gratuiti. UiPath Community Edition e il piano gratuito di Power Automate riguardano una scelta distinta da quella trattata qui.
• Installazione e configurazione. Quanto segue non è una guida all'installazione e nessuno strumento è accompagnato da comandi da eseguire.
• Agenti IA che utilizzano il computer. Uno strumento della lista offre un'integrazione con uno di questi agenti: gli dedichiamo una frase, non un confronto.

Gli strumenti RPA open source ancora mantenuti

I sei progetti seguenti soddisfano il criterio adottato: software RPA realmente open source con attività pubblica dalla metà del 2025. Gli strumenti RPA gratuiti la cui manutenzione è cessata restano gratuiti; quindi la colonna più importante è quella delle date, non delle licenze. Le altre indicano cosa automatizza ogni strumento e cosa richiede alla macchina sottostante.

rpaframework è una raccolta di librerie, non un'applicazione. Scrivi Python o Robot Framework e importi i componenti necessari: l'avvio è più impegnativo rispetto a registrare una macro, ma la manutenzione è molto più semplice. Il repository lo descrive come ottimizzato per Control Room, il prodotto commerciale di orchestrazione costruito da Robocorp attorno alla libreria. Un membro di Sema4.ai in una discussione su r/rpa descrive Robocorp come parte di Sema4.ai e chiarisce la distinzione. La libreria è Apache-2.0, la piattaforma no. La proprietà è cambiata, quella distinzione no. Anche il Robot Framework sottostante è Apache-2.0 e non costituisce un altro strumento da inserire nella selezione.

L'estensione browser di UI.Vision è il nucleo open source. L'automazione desktop richiede un download separato: un'applicazione locale chiamata XModules fornisce riconoscimento di immagini e testo per fare clic al di fuori del browser. La licenza è doppia (AGPLv3 o un accordo commerciale). Se modifichi il nucleo open source e non vuoi rispettare gli obblighi di condivisione del sorgente previsti da AGPLv3, l'alternativa è la licenza commerciale.

taskt è il caso difficile da classificare. Il ramo di sviluppo ha ricevuto un commit a luglio 2025, mentre la sua ultima versione con tag, v3.5.0.0, è stata pubblicata a maggio 2020. Commit e rilasci sono segnali diversi: tanto tempo senza una build versionata non significa che quella esistente abbia smesso di funzionare.

SikuliX merita una nota perché il nome indica ormai la linea storica. L'upstream originale è stato archiviato a marzo 2026 e il mirror oculix-org indirizza gli utenti attuali a Oculix, la continuazione attiva sotto MIT. È quindi Oculix il progetto da considerare oggi; SikuliX1 serve come contesto di provenienza e compatibilità, non come voce mantenuta.

Due nomi continuano ad apparire nelle selezioni, ma non dovrebbero esserci. Il README di Automagica annuncia che Netcall ha acquisito l'azienda il 13 ottobre 2020 e che il robot non è più disponibile sotto AGPL3. L'organizzazione GitHub pubblica di OpenBots contiene un repository per siti statici e una libreria di emulazione terminale, ma nessun nucleo RPA.

Interfaccia grafica o headless: la distinzione che decide il server

Uno strumento RPA open source richiede una sessione desktop quando il workflow automatizza interfacce desktop. Le attività su API, file e dati possono funzionare senza interfaccia grafica, così come quelle del browser se eseguito in modalità headless. Gli strumenti di riconoscimento immagini richiedono inoltre pixel da esaminare, ma l'automazione desktop può dipendere da una sessione grafica anche quando identifica controlli tramite selettori anziché immagini.

Una sessione desktop è l'ambiente grafico disponibile dopo l'accesso: schermo, gestore delle finestre e puntatore del mouse con coordinate. Headless significa il contrario: una macchina in esecuzione senza schermo collegato. La maggior parte dei server Linux noleggiati arriva così per impostazione predefinita.

La distinzione deriva dalle dipendenze dell'automazione. Oculix, come SikuliX prima di lui, usa la visione artificiale per trovare un pulsante confrontando un'immagine salvata con i pixel attualmente sullo schermo; richiede quindi una superficie grafica da esaminare. Un browser pilotato da un'API di automazione può funzionare senza schermo desktop. L'automazione desktop basata su selettori è ancora diversa: identifica controlli anziché pixel, ma può comunque dipendere da un ambiente desktop grafico. Per RPA open source su server, la domanda pratica è se il workflow richiede una sessione grafica.

TagUI e UI.Vision appartengono a entrambi i gruppi a seconda della modalità. La documentazione di riferimento di TagUI dice che l'opzione -headless esegue un flusso con un browser Chrome invisibile e non funziona per l'automazione visiva. UI.Vision lavora nel browser tramite un'estensione e sul desktop tramite XModules, che riconosce immagini sullo schermo e necessita quindi di uno schermo su cui riconoscerle.

Uno schermo virtuale colma parte della distanza. Xvfb è un metodo comune per fornire a una macchina Linux headless uno schermo in memoria su cui i programmi grafici possono disegnare senza spettatori. Rende possibile l'automazione visiva su un server senza monitor. Non farà funzionare su Linux uno strumento esclusivo di Windows e aggiunge un ulteriore livello che deve continuare a funzionare alle tre del mattino.

Una licenza e una data di commit ti dicono se uno strumento esisterà ancora l'anno prossimo. I requisiti della sessione ti dicono se puoi eseguirlo o meno.

Dove funziona ciascuno

Un bot che agisce sullo schermo richiede una sessione grafica controllabile, reale, remota o virtuale. Un bot headless no. Sembrano entrambe banalità finché il bot deve partire alle 3 del mattino senza nessuno davanti alla tastiera.

La RPA auto-ospitata ha un requisito operativo che resta indipendentemente dallo strumento: la macchina deve essere nello stato corretto quando scatta la pianificazione. Su Windows questo stato è specifico e Microsoft lo documenta per il proprio prodotto. La guida ai flussi desktop non presidiati di Power Automate spiega che il prodotto crea una sessione desktop remoto sulla macchina di destinazione, che non si può usare la sessione console per esecuzioni non presidiate e che un dispositivo Windows 10 o Windows 11 non può eseguirne una se esiste una sessione utente, anche bloccata. Su Windows Server, una sessione bloccata aperta con lo stesso utente della connessione restituisce invece un errore.

È l'implementazione di un fornitore, non una legge di Windows, ma offre una mappa utile dei problemi: ogni bot visivo deve risolvere la stessa questione. Qualcosa deve disporre di una sessione interattiva, e spesso il tuo desktop con accesso effettuato è l'ostacolo. Su Linux il problema equivalente è minore, ma esiste: un processo che continua dopo la chiusura della sessione SSH richiede uno scheduler e un gestore dei servizi, non un terminale lasciato aperto.

Windows Server gestisce le sessioni diversamente dalle edizioni desktop. Il ruolo RD Session Host esegue desktop basati su sessioni su una sola macchina per usare più sessioni in modo efficiente, quindi la sessione del bot e la tua possono coesistere. Per questo utilizzo di RD Session Host, ogni utente o dispositivo collegato richiede una RDS CAL: un costo da considerare subito, non un dettaglio da scoprire alla fine.

Il dimensionamento è modesto. Non assegnerei più di 1 vCPU e 2 GB di RAM a un bot che percorre un modulo facendo clic e scrive un file. Per qualsiasi attività che controlli un browser completo prevederei 2 vCPU e almeno 4 GB, soprattutto con più schede: Chrome è la parte costosa del carico, non lo strumento di automazione che lo guida.

Una vecchia macchina in un armadio soddisfa questi requisiti. Deve restare accesa e con l'accesso effettuato, e non essere il portatile che chiudi la sera. Un server noleggiato elimina questi problemi: resta attivo indipendentemente dal portatile e non compete con la sessione desktop su cui lavori.

Se noleggiare la macchina conviene più che mantenerne una, la distinzione corrisponde abbastanza bene a due prodotti. Un Windows VPS con immagine Desktop o Server offre al bot visivo un ambiente Windows dedicato, mentre un Linux VPS copre il lato headless. Entrambi funzionano anche con il portatile chiuso.

Quale scegliere

Se l'attività avviene in un browser o nei file e sai scrivere Python, la scelta è RPA Framework; il resto di questa sezione riguarda casi particolari. La risposta cambia quando entra in gioco un'applicazione desktop senza API: serve uno strumento capace di interagire con un desktop grafico, e la selezione diventa più breve e più vecchia.

Per browser, file e dati su un server Linux scegli RPA Framework. Funziona headless, non richiede infrastrutture grafiche aggiuntive e ha pubblicato una versione anche a ottobre 2026. Il prezzo è scrivere Python o Robot Framework invece di registrare una macro: costa il primo giorno e ripaga ogni volta che cambia l'applicazione di destinazione.

Per un'applicazione Windows datata senza API, se vuoi automazione visiva anziché scrivere un'intera base di codice, scegli UI.Vision con la relativa condizione. Riceve commit quest'anno, a differenza di varie opzioni desktop. La parte AGPLv3 della doppia licenza comporta obblighi di condivisione del sorgente se modifichi e distribuisci il software open source. taskt è la seconda scelta: il ramo di sviluppo è vivo, ma l'ultima versione con tag risale a maggio 2020. Devi valutare la differenza tra ricevere commit e pubblicare versioni.

Per automatizzare visivamente ciò che appare sullo schermo su più piattaforme scegli Oculix, la continuazione attiva di SikuliX. Privilegia ancora le immagini rispetto ai selettori, ma ora ha un IDE e rilasci attivi, non solo primitive di confronto immagini. Usalo quando l'obiettivo sono pixel anziché un DOM o un albero di accessibilità; considera il repository archiviato SikuliX1 come la linea storica, non il prodotto mantenuto.

TagUI continua a essere consigliato per un motivo: il linguaggio assomiglia all'inglese comune e l'apprendimento è il più semplice dei sei. La contropartita è nel README: AI Singapore ha interrotto la manutenzione e il supporto di TagUI, mentre i contributori open source e la comunità continuano il progetto. Non è abbandono: arrivano correzioni sul ramo predefinito e il repository non è archiviato. Non è nemmeno slancio, e il wrapper Python rpa su PyPI è anni indietro rispetto ai commit. Scegli TagUI per un'attività che puoi congelare, non per una piattaforma da estendere per tre anni.

OpenRPA è più difficile da valutare. Offre vere funzionalità di orchestrazione sotto MPL-2.0, ma il suo ultimo commit di codice e la sua versione con tag più recente risalgono entrambi a giugno 2025, e da allora l'unica attività nel repository sono branch automatici per l'aggiornamento delle dipendenze. Non si tratta di abbandono, perché nulla è archiviato, ma non è stato neppure rilasciato nulla. Valuta questo divario rispetto alla durata prevista dei bot.

Quando uno strumento RPA dedicato è la risposta sbagliata

L'argomento più forte contro quanto sopra arriva da chi fa questo lavoro. In una discussione su r/selfhosted avviata da un operatore che voleva uscire da un contratto RPA commerciale, una risposta propone Python con un framework di automazione come Selenium. Più lavoro iniziale, meno rotture dopo e minori costi di possesso nel tempo rispetto al software RPA usato dal commentatore. Un altro partecipante nella stessa discussione concorda indipendentemente.

La soglia è la manutenzione. Se l'attività durerà anni, il volume è alto e tu o qualcuno nel team potete mantenere una piccola base di codice, scrivi il codice. Selenium e Playwright costano di più il primo giorno e meno al quattrocentesimo, perché uno script scritto da te si rompe in modi che puoi comprendere. Se l'orizzonte dell'attività è di mesi o nessuno nel team scrive codice, il percorso più breve dello strumento RPA verso un bot funzionante vale la sua fragilità.

L'output del registratore invecchia peggio di tutto. Uno script generato osservando i clic dipende dal layout registrato: una pagina ridisegnata o un pulsante spostato lo rompe in un modo che il messaggio d'errore raramente spiega. Lo scetticismo va anche oltre: un commentatore in una discussione su r/rpa sulle opzioni open source definisce la RPA scripting riconfezionato e venduto a manager non tecnici. Per un'attività abbastanza circoscritta, non è una descrizione ingiusta.

Va individuato presto anche un errore di categoria. Se i sistemi collegati espongono API o webhook, non serve RPA. La RPA guida l'interfaccia perché non esiste un altro accesso; l'automazione dei workflow usa direttamente quell'accesso, richiedendo meno sviluppo ed essendo molto meno fragile. Sono strumenti diversi con altri costi, e la licenza di n8n e il costo di auto-ospitarlo sono la prima questione da risolvere. n8n, Node-RED, Apache Airflow, Kestra e Dagu sono applicazioni installabili con un clic nel nostro marketplace, se vuoi avviarne una oggi.

Il sito attuale di UI.Vision pubblicizza un'integrazione con Anthropic Computer Use, quindi la categoria sta già incorporando agenti che guidano lo schermo ragionando su ciò che vedono anziché confrontare immagini salvate.

Domande frequenti