Cosa ho imparato dopo 48 ore di n8n

Giugno 29, 2025 technews

Era da mesi che volevo testare n8n, essendo stato in passato un grande fan di Node-RED. Ora, complice la disponibilità di un chart Helm per Kubernetes, mi sono avventurato nell’installarlo on-prem perché sono e rimango un grande fan del software installato sul proprio hardware, senza dipendere da servizi cloud che possono diventare costosi (e molto) con poco preavviso.

Premetto che la mia non è una situazione comune: uso da anni una soluzione ibrida di sistemi di domotica (il cuore pulsante è una piattaforma basata su Legrand Vantage InFusion, una offerta commerciale poco cloud-ready ma estremamente affidabile), adattata per poter lavorare con MQTT e Prometheus (ne parleremo un’altra volta) tramite HomeAssistant ed un nuvolo di script Python containerizzati in un cluster Kubernetes casalingo che alimentano appunto MQTT.

Ho quindi tante fonti dati (l’intera casa, la stessa auto è integrata in MQTT), uso Paperless-ngx sempre self-hosted per tutto ciò che “era” carta e da ormai un decennio anche Telegram per piccoli task casalinghi.
Come dicevo, non è una situazione comune in cui tutti si possano ritrovare.

A cosa serve?

In un’epoca in cui si parla incessantemente di soluzioni no-code, spesso associate al cosiddetto Vibe Coding (l’uso dell’IA per sviluppare applicazioni senza competenze di programmazione), n8n si distingue come strumento che permette di automatizzare workflow senza scrivere codice – a meno che non sia necessaria un’integrazione specifica non disponibile, caso in cui rimane comunque possibile implementare codice personalizzato. Funzionalmente, ricorda piattaforme come IFTTT (If This Then That), ma con maggiore flessibilità e potenza, ma soprattutto la possibilità di poterla operare senza costi con la versione community disponibile su Github.

Graficamente si combinano trigger (eventi che avviano il workflow, come un nuovo messaggio in chat, una mail ricevuta o una nuova stella sul vostro progetto GitHub), operazioni (rispondere a un messaggio, interrogare un LLM, accendere una luce) e condizioni di varia complessità.

C’è meno del 25% di benzina nel serbatoio dell’auto? Manda un messaggio via Telegram e ricorda di fare il pieno (ci arriveremo).

L’installazione

Ho fatto un errore nelle prime due ore di lavoro: non utilizzare un database degno di questo nome accontentandomi di SQLite. Non fatelo, potete installare fin da subito PostgreSQL e se usate Kubernetes ed Helm il tutto è ad un chart di distanza (https://artifacthub.io/packages/helm/bitnami/postgresql). Il PostgreSQL, oltre a poter gestire meglio il quantitativo di dati che si vengono a generare, diventa un comodo store per il Vector Database compatibile per gli usi con IA che potrebbero venirvi in mente… perché alla fine vi verranno in mente.
Se fate l’errore di iniziare con SQLite non fasciatevi la testa; fermatevi un attimo, usate la CLI per fare un backup e restore di credenziali e workflow e ripartite da zero, importando tutto con:

# Prima
n8n export:credentials --all --output=credentials.json
n8n export:workflows --all --output=workflows.json

# Dopo
n8n import:credentials --input=credentials.json
n8n import:workflow --input=workflows.json

Ri-registrate l’account di login e siete di nuovo al lavoro. Nel mio caso era anche necessario montare alcuni filesystem locali (dove finiscono i documenti generati dalla stampante/scanner) ed il chart Helm lo prevede. Da qui viene un altro consiglio, n8n è costituito da almeno tre componenti:

  • la GUI (l’interfaccia web), con cui avrete a che fare
  • il webhook manager che riceve le callback che attivano n8n
  • il workflow manager che esegue i workflow

Se rendete disponibile il filesystem aggiuntivo solo alla GUI, i workflow in test vi funzioneranno in maniera meravigliosa, ma in produzione quando poi dovranno funzionare davvero, non lo faranno e saranno molto omertosi al riguardo.

Dopo aver configurato tramite un Ingress l’accesso dalla rete locale, non dimenticate che per buona parte dei workflow n8n dovrà essere accessibile dall’esterno; evitate di esporre l’intera applicazione ed esponete per lo meno i path /webhook, /webhook-test e /rest (quest’ultimo per configurare alcune integrazioni, come Dropbox e Teams). Nel farlo evitate magari il path di default e aggiungete un context aggiuntivo al vostro reverse proxy, ad esempio con Apache, in modo da mitigare l’effetto delle scansioni automatiche da parte di “security researcher”:

 <Location /my-n8n/webhook/>
    Require all granted
    ProxyPass https://n8n.local.lan/webhook/
 </Location>
 <Location /my-n8n/webhook-test/>
    Require all granted
    ProxyPass https://n8n.local.lan/webhook-test/
 </Location>
 <Location /my-n8n/rest/>
    Require all granted
    ProxyPass https://n8n.local.lan/rest/
 </Location>

e visto che n8n non lo sa, avvisatelo del fatto che i webhook esposti su Internet avranno un indirizzo differente dalla GUI:

config:
  n8n:
    webhook:
      url: "https://your-public-site/my-n8n"

Il primo workflow

Ora che siete i fortunati possessori di una installazione n8n locale potete lanciarvi nel vostro primo workflow, il che significherà probabilmente che avrete bisogno di configurare un po’ di credenziali. Ricordate che nella versione “community” del prodotto:

  • potete registrare più utenti, ma solo uno avrà diritti amministrativi
  • ogni utente avrà il proprio set di workflow e credenziali (username/password o token di autenticazione di API server) e non avrete quindi nulla di condiviso

A questo si aggiunge il limite di non poter condividere variabili con più task e questo alla lunga può essere un limite. Se usate l’integrazione con Telegram ad esempio vorreste salvare la chatid del gruppo di famiglia o un URL di un servizio ricorrentemente chiamato. Per farlo potete però aggiungere plugin di terze parti (“Community Nodes”) ed io nel particolare ho installato i seguenti:

  • n8n-nodes-datastore
  • n8n-nodes-globals

Per oggi parliamo del globals. E’ possibile ora creare una “credenziale” (fasulla):

e grazie al plugin sarà possibile leggere questi valori in più workflow, risolvendo il problema delle mancate variabili globali.

Il primo workflow, credo di averlo spoilerato, è un bot Telegram. Io ho già ben due bot, uno scritto in Python che mi gestisce alcune “funzionalità” di casa ed uno operato direttamente da HomeAssistant per le notifiche (es. se è arrivata o meno posta nella cassetta postale condominiale… si, via Zigbee con https://shop.swiss-domotique.ch/it/gateway-antenne/2390-smlight-adattatore-wifi-zigbee-ethernet-poe-usb-slzb-06m.html). Questa dispersione di codice e controllo mi tormenta e visto che sono attività banali posso convogliarle su n8n.

Creo il bot, mi scarico il token e creo il mio primo workflow. Ogni workflow deve iniziare con un trigger, cioè con una azione che “attiva” il job. In questo caso è un messaggio Telegram:

Qui viene uno dei punti di forza di questo tool: se voglio testare questo singol task del workflow basta che prema “Execute Step” e verrà configurato al volo il “bot” per chiamare il webhook di test (e non quello produttivo, se stiamo ad esempio lavorando su una nuova versione del nostro workflow), una volta ricevuta una singola chiamata (quindi al prossimo messaggio Telegram) otterrò in “output” il contenuto ricevuto.

Posso così continuare il mio sviluppo:

posso limitarmi a intercettare comandi precedentemente definiti, ad esempio /garage aprirà il garage (cosa che ora fa il vecchio bot Python), ma posso anche coinvolgere un LLM ed è questo uno dei motivi per cui si parla tanto di n8n: la disponibilità di molte integrazioni già comprese nel prodotto, incluse alcune con LLM.

A cosa può servire un LLM in una chat Telegram? Principalmente a due cose:

  • la prima è capire quale sia l’intenzione dell’interlocutore, utilizzando il linguaggio naturale. Information Extractor può infatti analizzare il messaggio ricevuto dalla chat e sulla base di un prompt di sistema che descrive il tipo di output che si desidera, può capire se si tratta di un messaggio relazionato con la domotica di casa ed estrarre in formato JSON informazioni chiave come “cosa”, “quanto” e “quando”. Posso dire “stasera alle 8 accendi il condizionatore a 25 gradi” e l’estrattore normalizzerà l’input riducendolo a input gestibili dal resto del workflow
  • la seconda è semplificare alcune attività ricorrenti, per cui usereste la chat di Perplexity, ChatGPT o DeepSeek. Mettiamo il caso che vogliate verificare periodicamente la correttezza sintattica di una frase scritta in inglese: è un caso d’uso che potete tranquillamente gestire con le chat (o le app) dei più comuni fornitori. Potreste anche, in queste chat, definire degli spaces preconfigurati con un system prompt dove quindi basti copiare ed incollare la frase da verificare (senza dover ogni volta dire “please fix or rephrase if needed”) per ottenere il risultato voluto.
    La chat Telegram però ha i suoi vantaggi: non mi devo ri-loggare sul portale di ChatGPT o Perplexity, non devo ogni volta creare una nuova chat (per poi fare pulizia ogni tanto), posso non pagare un abbonamento “Pro” ma semplicemente pagare per l’uso tramite le API e scegliere per ciascun caso d’uso il fornitore più conveniente o appropriato.
    Non ci sono invece vantaggi in termini di privacy, se non la comodità di mantenere la history, magari configurata con una retention massima di una settimana, in un unico posto.

Il secondo workflow: qualcosa non va

Una volta giocato per qualche ora con Telegram, la domotica e gli LLM, viene il momento di fare qualcosa di serio.

Uso da anni Paperless-ngx che non è altro che l’archivio casalingo di tutti i documenti:

cerchi “Salt” (un operatore telefonico qui in Svizzera) e trovi le fatture, i contratti. Per farlo ovviamente lo strumento deve essere alimentato. Si può fare drag&drop dei documenti nella GUI, si può inviare una mail e attenderne la scansione (senza nessun feedback), si può inviare un documento via API.

Ed ecco qui che n8n, anche se non provvisto di una integrazione nativa per Paperless, ci può aiutare. Come dicevo Paperless ha un difetto: supporta l’acquisizione di documenti da una directory o via mail, ma non ama inviare feedback in proposito.

Possiamo ad esempio monitorare una directory, cosa che paperless farebbe già in autonomia, attendere un documento nuovo, leggerlo, inviarlo a Paperless e… venire notificati su come è andata a finire.

Possiamo ricevere una mail in caso di insuccesso, ma possiamo anche ricevere una notifica via mail e Telegram in caso di successo, eventualmente con una copia del documento appena scannerizzato, per poi cancellare il tutto.

E qui qualcosa non è andato come doveva:

n8n tiene traccia di ogni esecuzione, avvenuta sia in debug (la modalità di test che abbiamo visto prima), sia in produzione. Per ogni esecuzione abbiamo il flow seguito, gli errori, gli input ed output di ogni mudulo e tramite “debug in editor” è possibile portare queste informazioni nell’editor.

Cosa possiamo fare? Ri-eseguire l’intero workflow (come se fosse una nuova esecuzione, senza attendere il trigger), modificarlo per correggere eventuali errori.

Questo effettivamente è uno degli indubbi vantaggi di utilizzare questo tool, in sostituzione ad uno script in Python o Golang in cui, anche con un logging adeguato, risulta difficile verificare cosa sia successo durante una esecuzione anomala.

E ricordati di fare il pieno…

Veniamo all’ultimo workflow di queste folli prime 48 ore. Ne abbiamo già parlato, il mio non è un caso comune. Tramite https://github.com/tillsteinbach/CarConnectivity parlo con la mia auto, ricevo della telemetria (stato delle portiere, stato di movimento, posizione, livello di benzina e odometro), tutte informazioni già interessanti per Grafana

e che ad ogni aggiornamento posso verificare se è ora o meno di far benzina, soprattutto quando la macchina è usata raramente e condivisa tra più persone. Cosa ho imparato in questo caso?
Che stiamo inviando un allarme quando l’autonomia è inferiore al 25%, ma che non dobbiamo continuare a farlo quando l’autonomia è al 24%.. 23%.. 3%, continuamente. Per questo motivo un componente interessante può essere il Key/Value store incluso nel prodotto:

in modo da poter memorizzare il fatto che si è generato un primo messaggio di allarme e di non ripeterlo alle successive esecuzioni del workflow. Da buon elettronico ricordo anche che sarebbe ancora più consigliato prevedere che l’allarme scatti una volta raggiunto il 25%, ma si resetti ad una quota più alta (es. 27-30%) in modo tale da evitare allarmi multipli perché il sensore della benzina ha deciso di ballare.

Ed ora?

Il primo obiettivo ad una settimana di distanza è quello di terminare la migrazione delle automazioni dai vari bot o altri script containerizzati, in modo da utilizzare n8n come principale motore di workflow. Non nascondo che colleghi mi hanno già solleticato con le funzionalità di Agentic AI (supportate) e RAG (di nuovo supportate e dove il PostgreSQL sottostante può essere utilizzato, in ambito domestico), ma preferisco per ora fermarmi un attimo per consolidare, condividere l’esperienza e riprendere a mente fredda.

Ma n8n per ora è qui per restare!