Cosa conta come strumento open source di automazione (e cosa no)
Uno strumento open source di automazione è un motore che orchestra flussi — attiva, connette app, sposta dati, decide tra i passaggi — e il cui codice puoi ospitare sulla tua infrastruttura invece che nel cloud di un terzo. La differenza con Zapier o Make non è cosa fanno, è dove vive il motore e chi controlla il dato: in un SaaS chiuso, sui loro server; in uno strumento open source, dove decidi tu.
Vale la pena sciogliere una confusione di nome. «IA open source» di solito indica i modelli di linguaggio che puoi auto-ospitare (Llama, Mistral e simili), e quella è un'altra decisione — modello aperto vs. API chiusa. Qui parliamo di orchestrazione: lo strumento che esegue il flusso e chiama il modello, qualunque sia. Due strati separati, scelti con criteri diversi.
I tre che contano: n8n, Activepieces e Windmill
Il panorama open source è ampio, ma per l'automazione IA in azienda la conversazione reale ruota attorno a tre. Tutti e tre si auto-ospitano; differiscono per licenza, impostazione e a chi sono rivolti.
| Strumento | Licenza | Impostazione | A chi si adatta |
|---|---|---|---|
| n8n | Sustainable Use License (fair-code) | Editor visivo a nodi + codice dove serve | Team misti; la community più grande e più integrazioni |
| Activepieces | MIT (la più permissiva) | No-code visivo, semplice | Team poco tecnici che vogliono libertà di licenza totale |
| Windmill | AGPLv3 | Code-first (TypeScript, Python, Go, Bash, SQL) con UI auto-generate | Team di ingegneria che vogliono tooling interno come codice |
La licenza non è una nota per avvocati: cambia cosa puoi fare. Quella di n8n è aperta per uso interno ma vieta di rivenderlo come servizio gestito a terzi. Activepieces, sotto MIT, non ti lega quasi a nulla. Windmill, sotto AGPLv3, ti obbliga a pubblicare le modifiche solo se distribuisci il software — non se lo usi tra le tue mura. Per il 90% delle aziende, che lo ospitano per la propria operatività, tutti e tre si comportano come vero open source.
Quando conviene ospitarlo tu (e quando no)
Il self-host non è gratis né superiore per default. Conviene quando una di queste pressioni è reale — e non conviene quando nessuna lo è.
Conviene se:
- Il dato non può uscire di casa. Settore regolato, informazione sensibile o una policy GDPR che esige che il dato viva nel tuo perimetro. È il motivo numero uno e quello che pesa di più.
- Il volume fa esplodere il prezzo. Il SaaS fattura a operazione o a task; oltre un certo volume, il costo per esecuzione di un piano cloud cresce più in fretta di quello di un tuo server.
- Ti serve logica su misura o codice. Quando il flusso chiede qualcosa che il no-code non copre, poter inserire codice in qualsiasi passaggio smette di essere un lusso.
- Vuoi evitare il lock-in. Controllare il motore significa che un cambio di prezzo o di condizioni del fornitore non ti mette con le spalle al muro.
Non conviene se:
- Connetti solo un paio di app e il piano cloud ti va bene: cambiare costa più di quanto risparmi.
- Non hai chi mantenga l'infrastruttura (vedi il costo reale più sotto).
- Il tuo collo di bottiglia non è l'esecuzione, è il criterio: leggere testo libero, capire l'intenzione, decidere sull'ambiguo. Cambiare strumento non lo risolve; è mettere uno strato di IA sopra.
Il costo reale del self-host, oltre la licenza
«0 € di licenza» è vero e ingannevole al tempo stesso. Il costo non è nella licenza; è nell'operare il sistema. Ecco cosa compare davvero in fattura:
- Server e hosting: la macchina su cui gira, la sua banda e il suo storage.
- Backup e alta disponibilità: un flusso critico che cade senza copia è un incidente, non un'automazione.
- Aggiornamenti e patch di sicurezza: ogni versione porta correzioni da applicare; un motore aperto e non aggiornato è una porta aperta.
- Monitoraggio e log: senza osservabilità non sai che il flusso è fallito finché qualcuno non si lamenta.
- La persona che lo mantiene: il costo dominante. Non è il software, è il tempo tecnico per tenerlo sano.
Self-host e GDPR: sovranità del dato, non una casella
Ospitare tu lo strumento tiene motore e database nel tuo perimetro. È un buon punto di partenza per il GDPR, ma non chiude la questione. La sovranità del dato la decide l'intera catena del flusso, non l'etichetta del pannello.
Il punto cieco solito: il motore è a casa, ma il flusso chiama un'API di LLM ospitata negli Stati Uniti, o lancia un webhook verso terzi, o salva un allegato in uno storage cloud. A ognuno di questi salti il dato esce dal tuo perimetro come con un SaaS. Auto-ospitare l'orchestratore e mandare contenuto sensibile a un modello esterno non controllato è mezza sovranità. Bisogna guardare dove vive ogni salto — ed è qui che n8n auto-ospitato brilla rispetto alle alternative cloud, proprio perché puoi tenere l'intera catena sotto il tuo tetto.
Come scegliere in una frase
Team poco tecnico e libertà di licenza totale → Activepieces (MIT). Team misto che valorizza community e integrazioni → n8n (fair-code). Team di ingegneria che vuole tutto come codice e versionato in Git → Windmill (AGPLv3). E un avvertimento che salva progetti: se il tuo vero problema è che il flusso ha bisogno di criterio, nessuno dei tre lo risolve da solo — è uno strato di IA sopra, non un cambio di strumento.