SSD Nodes Learn 🎉 VPS da $4.99/mese
Guide Matt ConnorDi Matt Connor · Aggiornato 2026-08-07

Alternative a n8n self-hosted: confronto su VPS

Confronta Activepieces, Windmill, Node-RED, Automatisch e Huginn con n8n per licenza, RAM, database, passaggi AI e backup che rompe i ripristini.

Cosa usare al posto di n8n

Le alternative self-hosted a n8n che vale la pena usare su un VPS (virtual private server) sono Activepieces, Windmill, Node-RED, Automatisch e Huginn. Activepieces è il sostituto più vicino al modo in cui la maggior parte degli utenti utilizza n8n e il suo componente principale è distribuito con licenza MIT. Windmill è adatto ai team che preferiscono scrivere codice Python o TypeScript invece di trascinare blocchi su un canvas. Node-RED è la soluzione più semplice e non richiede alcun database.

Molti lettori dovrebbero restare con n8n. La licenza di n8n consente l'uso interno in ambito aziendale, quindi se esegui i workflow per la tua azienda, la licenza non rappresenta un problema. Anche la migrazione richiede lavoro. Nessuna delle soluzioni elencate importa un'esportazione di n8n: devi ricreare manualmente ogni workflow e inserire nuovamente tutte le credenziali. L'installazione di n8n è un'attività separata, descritta in installare n8n su un VPS con Docker e HTTPS, mentre n8n a confronto con Zapier e Make spiega come confrontare questa categoria con i servizi gestiti.

Perché si cercano alternative self-hosted a n8n

I motivi principali sono due.

Il primo riguarda la licenza. n8n viene distribuito con la Sustainable Use License v1.0, che il progetto definisce fair-code anziché open source. La licenza concede il diritto di «usare o modificare il software esclusivamente per le proprie attività aziendali interne oppure per uso non commerciale o personale» e vieta di fornire commercialmente il software ad altre persone. I file e le directory il cui nome contiene .ee sono soggetti a una licenza n8n Enterprise separata. Se vuoi eseguire automazioni per conto di clienti paganti, questo è un limite vincolante. Se lavori in un team operativo interno, per la tua attività quotidiana non cambia nulla.

Il secondo riguarda la memoria. n8n è un processo Node.js e i dati del workflow restano in memoria durante l'esecuzione. La documentazione di n8n indica queste cause: quantità di dati JSON, dimensione dei dati binari, numero di nodi nel workflow, nodo Code, esecuzioni manuali (che copiano nuovamente i dati per l'editor) e altri workflow eseguiti contemporaneamente. La soluzione documentata non consiste nell'utilizzare un prodotto diverso. Consiste nell'abilitare la queue mode con processi worker separati e nell'utilizzare Postgres invece del file SQLite predefinito in ~/.n8n/database.sqlite. I job di grandi dimensioni richiedono inoltre l'elaborazione a batch, perché un nodo Loop Over Items che alimenta un sub-workflow mantiene in memoria una sola porzione dei dati alla volta. Prova questa configurazione prima di ricostruire altrove sessanta flow.

Quali alternative self-hosted a n8n sono ancora mantenute

Il testo della licenza è facile da leggere, quindi tutti confrontano le licenze. È più facile trascurare lo stato del progetto. Questi sono i 6 progetti inclusi in questo confronto, con l'ultima release contrassegnata disponibile per ciascuno al 4 agosto 2026.

ChartNewest tagged release, checked 4 August 2026
The data behind this chart
[
  {
    "tool": "n8n",
    "licence": "Sustainable Use License",
    "latest_release": "2.33.3",
    "released": "2026-07-31",
    "days_since_release": 4
  },
  {
    "tool": "Activepieces",
    "licence": "MIT core, commercial ee",
    "latest_release": "0.86.3",
    "released": "2026-07-17",
    "days_since_release": 18
  },
  {
    "tool": "Windmill",
    "licence": "AGPLv3 source, CE image",
    "latest_release": "v1.778.0",
    "released": "2026-08-04",
    "days_since_release": 0
  },
  {
    "tool": "Node-RED",
    "licence": "Apache 2.0",
    "latest_release": "5.0.4",
    "released": "2026-07-30",
    "days_since_release": 5
  },
  {
    "tool": "Automatisch",
    "licence": "AGPL-3.0, commercial ee",
    "latest_release": "v0.15.0",
    "released": "2025-08-08",
    "days_since_release": 361
  },
  {
    "tool": "Huginn",
    "licence": "MIT",
    "latest_release": "v2022.08.18",
    "released": "2022-08-18",
    "days_since_release": 1447
  }
]

Due righe modificano la selezione. Automatisch ha contrassegnato l'ultima release v0.15.0, che risale a 361 giorni fa, e il relativo branch predefinito non contiene commit dal 15 gennaio 2026. Huginn ha contrassegnato una release 1447 giorni fa, ma il relativo log dei commit è attivo questo mese. È lo schema opposto: il codice cambia, ma le release non vengono pubblicate. Eseguire il progetto significa quindi usare un'immagine senza tag.

Verificalo personalmente prima di fidarti di qualsiasi confronto, incluso questo. Apri la pagina delle release del progetto su GitHub, quindi l'elenco dei commit del relativo branch predefinito. Un progetto con una release recente e un log dei commit inattivo procede per inerzia. Un progetto con commit recenti e senza release da anni ti chiede di eseguire codice per il quale nessuno ha pubblicato una versione.

Activepieces: la corrispondenza più vicina, con il core sotto licenza MIT

Activepieces è la scelta più simile. È un builder visuale con trigger e passaggi, chiamati pieces, e il README ne dichiara più di 280. Ogni piece è inoltre esposto come server MCP (model context protocol), quindi un client LLM (large language model) può chiamare gli stessi connettori come strumenti. Il core è distribuito con licenza MIT. Due directory, packages/ee/ e packages/server/api/src/app/ee, sono coperte da una licenza commerciale; per usare ciò che contengono sul proprio server è necessario un accordo a pagamento.

Leggete questa separazione prima della migrazione, perché è più ampia rispetto alla maggior parte dei progetti MIT. La pagina dei prezzi di Activepieces descrive la Community Edition come "open source, free forever, with no cap on runs, users, or flows" e colloca al di fuori di essa Agents e Chat, i Projects, l'accesso API e l'intero livello di amministrazione (single sign-on, ruoli utente, audit log, secret manager, branding, sincronizzazione Git). La Community Edition è quindi un motore di automazione completo, con flow e utenti illimitati, ma non è una piattaforma che si possa gestire tramite API. Se il piano prevedeva di generare i flow in modo programmatico, serve una licenza.

L'architettura di runtime comprende un container dell'applicazione, uno o più container worker, Postgres e Redis. AP_DB_TYPE=POSTGRES e AP_REDIS_TYPE=STANDALONE sono i valori predefiniti. È disponibile una modalità con un singolo container, un database incorporato e una coda in-process (AP_DB_TYPE=PGLITE con AP_REDIS_TYPE=MEMORY); la documentazione specifica che questa modalità "is only meant for personal use or testing". Considerate questa indicazione in modo letterale. Queste modalità non possono eseguire più di un'istanza, quindi il passaggio a un'architettura più grande richiede una migrazione, non la modifica di un flag.

Windmill: il codice viene prima, ma l’installazione è più pesante di quanto sembri

Windmill esegue script in Python, TypeScript, Go, Bash e SQL, quindi li combina in flussi. Se le automazioni sono costituite soprattutto da codice con una piccola quantità di logica di collegamento, Windmill è più adatto di qualsiasi canvas a nodi.

La licenza richiede attenzione. Il codice sorgente è rilasciato con licenza AGPLv3 quando viene compilato senza il flag delle funzionalità enterprise. Le immagini pubblicate in ghcr.io/windmill-labs/windmill sono la Community Edition, che include codice non open source ed è utilizzabile gratuitamente entro i limiti previsti. La pagina dei prezzi di Windmill indica i limiti in 50 utenti, 3 workspace e 10 GiB di object storage per i workspace, con esecuzioni illimitate. Per una singola persona o un piccolo team, questi limiti sono difficili da raggiungere. La questione pratica, quindi, non riguarda la quota. Riguarda il fatto che il binario in esecuzione non è la build AGPL.

Anche l’impatto sulle risorse è un fattore da considerare. Il docker-compose.yml ufficiale di Windmill include un database PostgreSQL 16, un server, tre worker predefiniti con un limite di memoria di 2048M ciascuno, un worker nativo e un proxy Caddy. La regola pratica documentata è «1 worker per 1vCPU e 1-2 GB di RAM». Su un server di piccole dimensioni puoi ridurre il numero di repliche. Devi però sapere che stai riducendo proprio i componenti che eseguono effettivamente i job.

Le funzionalità AI di Windmill sono documentate come strumenti di assistenza durante la fase di sviluppo: generazione del codice, creazione di flussi, chat e compilazione di moduli. Prima devi aggiungere una risorsa che indichi il model provider nelle impostazioni del workspace. Se vuoi un passaggio agent che venga eseguito secondo una pianificazione e chiami strumenti, il nodo AI Agent di n8n resta la soluzione più diretta. creare un agente AI in n8n descrive questo scenario.

Node-RED: la soluzione più compatta, senza alcun database

Node-RED è distribuito con licenza Apache 2.0, la più permissiva tra quelle considerate. È costituito da un singolo processo Node.js con un volume /data. Non usa Postgres né Redis. Bloccalo alla versione nodered/node-red:5.0.4, che è la release corrente.

Nasce dall'ambito IoT (internet of things) e quindi segue un modello basato sugli eventi, non sui connettori. I nodi per i servizi di terze parti provengono dalla libreria della community e hanno livelli di qualità variabili. Questo è il compromesso per ottenere un footprint ridotto. Non è disponibile un passaggio nativo per gli agenti AI. Per un VPS di piccole dimensioni che gestisce webhook e traffico di code di messaggi, è la soluzione più leggera tra quelle considerate e si avvia in pochi secondi.

Huginn e Automatisch: controllare prima il registro dei commit

Huginn è rilasciato con licenza MIT, è scritto in Ruby on Rails e richiede MySQL o PostgreSQL. Funziona tramite agenti che monitorano una sorgente ed emettono eventi. È un modello diverso da quello di un canvas per i flussi e non offre un’integrazione con gli LLM. Il codice riceve ancora commit, ma l’ultima release contrassegnata risale ad August 2022. Eseguirlo significa quindi usare l’immagine ghcr.io/huginn/huginn compilata dal branch predefinito. Sceglilo quando il modello basato su agenti corrisponde al problema da risolvere, non come sostituto generico di n8n.

Automatisch è rilasciato con licenza AGPL-3.0, ad eccezione dei file .ee, e sembra una versione più semplice di n8n: Postgres, Redis e un catalogo ridotto di applicazioni. È lo strumento che i tutorial per una singola installazione continuano a raccomandare. La cronologia delle release suggerisce di attendere. Un anno senza release e sei mesi senza commit non sono un motivo di allarme se lo esegui già, ma sono un motivo per non avviare una nuova installazione in produzione basata su questo progetto.

Quanto costa davvero in RAM uno stack Activepieces

La memoria misurata quando lo stack è inattivo o sotto carico non è un valore che altri possono pubblicare al posto tuo, perché dipende dai tuoi flow e dalla quantità di dati che gestiscono. Puoi però leggere il budget indicato da ciascun fornitore. Activepieces documenta la configurazione seguente, ma la frase accanto conta più dei numeri: "Un worker con concorrenza pari a 1 resta occupato per tutta la durata di un flow, fino a 10 min; dimensiona quindi in base ai flow simultanei, non alla frequenza dei trigger."

ChartActivepieces published production sizing, per component
The data behind this chart
[
  {
    "label": "App container",
    "vcpu": 1,
    "ram_gb": 1
  },
  {
    "label": "Worker (each)",
    "vcpu": 0.5,
    "ram_gb": 1
  },
  {
    "label": "Postgres",
    "vcpu": 2,
    "ram_gb": 4
  },
  {
    "label": "Redis",
    "vcpu": 1,
    "ram_gb": 1
  }
]

Un worker richiede 0.5 vCPU e 1 GB e gestisce esattamente un flow alla volta. Postgres è dimensionato a 4 GB. Il file compose del progetto include cinque repliche dei worker; con questo dimensionamento, quindi, lo stack nel repository richiede circa 11 GB prima che i tuoi flow inizino a generare un carico significativo. I tutorial dedicati a un singolo strumento copiano quel file e definiscono questa configurazione come un deployment di piccole dimensioni.

Su una VPS da 4 GB, esegui due worker, mantieni Postgres nello stesso progetto compose e misura. docker stats --no-stream stampa una riga per container con la memoria residente effettiva; questo dato è più affidabile di qualsiasi valore pubblicato da un fornitore o in un blog. Se un container cresce senza limiti, impostane un limite; i limiti di memoria in Docker Compose mostra la sintassi.

Un file Compose per Activepieces su un singolo VPS

Blocca il tag. latest significa che il successivo docker compose pull può modificare lo schema del database senza preavviso. La versione 0.86.3 è quella indicata dal progetto nel proprio file Compose al 4 agosto 2026.

Genera prima i due secret, usando le lunghezze specificate nella documentazione.

openssl rand -hex 16    # AP_ENCRYPTION_KEY, encrypts stored connections
openssl rand -hex 32    # AP_JWT_SECRET, signs session tokens

Scrivi .env accanto al file Compose:

AP_ENGINE_EXECUTABLE_PATH=dist/packages/engine/main.js
AP_ENVIRONMENT=prod
AP_FRONTEND_URL=https://automation.example.com
AP_ENCRYPTION_KEY=REPLACE_WITH_HEX_16
AP_JWT_SECRET=REPLACE_WITH_HEX_32
AP_DB_TYPE=POSTGRES
AP_POSTGRES_DATABASE=activepieces
AP_POSTGRES_HOST=postgres
AP_POSTGRES_PORT=5432
AP_POSTGRES_USERNAME=postgres
AP_POSTGRES_PASSWORD=REPLACE_WITH_A_LONG_RANDOM_PASSWORD
AP_REDIS_TYPE=STANDALONE
AP_REDIS_HOST=redis
AP_REDIS_PORT=6379
AP_EXECUTION_MODE=UNSANDBOXED
AP_TELEMETRY_ENABLED=false

AP_FRONTEND_URL deve essere l'indirizzo HTTPS pubblico, perché altrimenti Activepieces prova a usare l'indirizzo IP pubblico quando genera gli URL dei webhook. Ogni webhook che fornisci a terzi viene generato a partire da questo valore. Se punta ancora a localhost, l'URL incollato in un altro servizio non raggiunge mai il server.

services:
  app:
    image: ghcr.io/activepieces/activepieces:0.86.3
    restart: unless-stopped
    ports:
      - '127.0.0.1:8080:80'
    depends_on:
      - postgres
      - redis
    env_file: .env
    environment:
      - AP_CONTAINER_TYPE=APP
    volumes:
      - ./cache:/usr/src/app/cache
  worker:
    image: ghcr.io/activepieces/activepieces:0.86.3
    restart: unless-stopped
    depends_on:
      - app
    env_file: .env
    environment:
      - AP_CONTAINER_TYPE=WORKER
    deploy:
      replicas: 2
    volumes:
      - ./cache:/usr/src/app/cache
  postgres:
    image: pgvector/pgvector:0.8.0-pg14
    restart: unless-stopped
    env_file: .env
    environment:
      - POSTGRES_DB=${AP_POSTGRES_DATABASE}
      - POSTGRES_USER=${AP_POSTGRES_USERNAME}
      - POSTGRES_PASSWORD=${AP_POSTGRES_PASSWORD}
    volumes:
      - postgres_data:/var/lib/postgresql/data
  redis:
    image: redis:7.0.7
    restart: unless-stopped
    volumes:
      - redis_data:/data

volumes:
  postgres_data:
  redis_data:

Questo file è il Compose del progetto con quattro modifiche: il numero di worker passa da cinque a due, la porta pubblicata viene associata a 127.0.0.1 invece che a tutte le interfacce, i nomi fissi dei container vengono rimossi perché un servizio con repliche non può usarli e il blocco di rete esplicito viene rimosso perché Compose ne crea comunque uno.

docker compose up -d
docker compose ps

Ogni servizio dovrebbe mostrare Up, inclusi due container worker. Un container che si riavvia continuamente indica il motivo in docker compose logs worker. Leggi quel messaggio prima di modificare qualsiasi cosa. L'associazione della porta impedisce l'accesso all'app dall'esterno finché non metti un reverse proxy con TLS (Transport Layer Security) davanti, come descritto in eseguire Traefik davanti a più app Compose. Mantieni .env con modalità 600 e fuori da git, come descritto in gestire i secret nei file env di Compose.

Il backup che quasi tutte le guide trascurano

Tutti questi strumenti cifrano le credenziali archiviate, quindi un dump del database non è un backup completo. Servono sia il dump sia la chiave che lo decifra. Il problema è che la maggior parte di questi strumenti genera automaticamente la chiave e la salva in un percorso che spesso non viene incluso nei backup.

n8n è il caso più evidente. Se non imposti mai N8N_ENCRYPTION_KEY, n8n «crea automaticamente una chiave di cifratura casuale al primo avvio e la salva nella directory ~/.n8n», quindi usa quella chiave per cifrare le credenziali prima di inserirle nel database. Esegui il dump di Postgres, ripristinalo in un nuovo container con un nuovo volume e i workflow ricompaiono, mentre tutte le credenziali restano cifrate e illeggibili. Imposta esplicitamente la variabile e usa lo stesso valore su ogni worker quando esegui n8n in modalità queue.

Node-RED segue lo stesso modello. Le credenziali risiedono in un file cifrato separato e la chiave è credentialSecret in settings.js. Se non ne imposti una, il runtime genera una chiave casuale e la salva in _credentialSecret nel proprio archivio delle impostazioni, all'interno di /data. Il file delle impostazioni predefinito indica chiaramente la conseguenza: «dopo aver impostato questa proprietà, non modificarla: Node-RED non potrà più decifrare le credenziali esistenti e andranno perse». Esegui il backup dell'intero volume /data, non soltanto del file dei flow.

Activepieces conserva AP_ENCRYPTION_KEY nel tuo .env, documentato come «chiave esadecimale di 32 caratteri (16 byte) usata per cifrare le connessioni». Huginn conserva APP_SECRET_TOKEN nel proprio ambiente. Automatisch ne usa tre: ENCRYPTION_KEY, WEBHOOK_SECRET_KEY e APP_SECRET_KEY. In tutti i casi, il secret si trova in un file di ambiente, quindi quel file fa parte del backup.

Windmill è l'eccezione da conoscere. Le variabili e i secret vengono cifrati con una chiave simmetrica specifica del workspace, che Windmill conserva nel proprio database. Di conseguenza, un singolo dump di Postgres contiene entrambe le parti. Questo semplifica i ripristini, ma significa anche che il solo dump è sufficiente per leggere ogni secret. Proteggi quindi il file come proteggeresti i secret stessi.

Per lo stack Activepieces descritto sopra, il backup consiste in due file:

cd /srv/activepieces
docker compose exec -T postgres pg_dump -U postgres -Fc activepieces > "ap-$(date +%F).dump"
cp .env "ap-env-$(date +%F).bak"
chmod 600 ap-*.dump ap-env-*.bak

Poi verifica che il backup funzioni, perché un backup non testato è soltanto un'ipotesi. Ripristina il dump in un progetto Compose di prova che usa un AP_ENCRYPTION_KEY volutamente diverso, quindi esegui un flow che utilizza una connessione salvata. L'esecuzione fallisce perché il ciphertext nel database è stato prodotto con l'altra chiave. Ripeti il ripristino usando la chiave reale di .env e lo stesso flow viene eseguito correttamente. Queste due prove sono l'unica evidenza che il tuo backup è realmente utilizzabile. Invia entrambi i file fuori dal server secondo una pianificazione, usando backup restic da un VPS, perché un backup salvato sullo stesso disco viene perso insieme al disco.

Quando restare su n8n

Resta su n8n se il lavoro è interno alla tua azienda, perché questo rientra esattamente in quanto consentito dalla Sustainable Use License. Resta su n8n se ti serve un'ampia scelta di integrazioni: n8n ne dichiara più di 1500. È inoltre disponibile il nodo AI Agent basato su LangChain, per il quale nessuna delle altre soluzioni qui esaminate offre un equivalente in termini di passaggi agentici pronti all'uso. Gestire i workflow n8n con Claude mostra come funziona in pratica.

Passa ad Activepieces se vuoi una licenza permissiva per il nucleo di automazione e uno stack che puoi analizzare da cima a fondo. Passa a Windmill se i tuoi flussi sono in realtà codice con un'interfaccia utente. Passa a Node-RED se il server è piccolo e il lavoro è basato su eventi. Non cambiare perché un benchmark ha stabilito che n8n è pesante. Misura prima la tua istanza, poi leggi cosa vale la pena eseguire in self-hosting nel 2026 e scegli una volta sola, perché la seconda migrazione costa quanto la prima.

FAQ

Qual è l'alternativa self-hosted a n8n più simile a n8n?

Activepieces. L'idea è la stessa: un builder visuale in cui un trigger avvia un flusso e ogni passaggio chiama un servizio, con un ampio catalogo di connettori. Il core è distribuito con licenza MIT, viene eseguito su Postgres e Redis tramite Docker e i suoi pieces possono funzionare anche come server MCP per client LLM. L'aspetto da verificare è che l'accesso alle API e le funzionalità per gli agenti si trovano nelle directory commerciali enterprise. Di conseguenza, un'istanza Community Edition viene gestita tramite l'interfaccia web, non programmaticamente.

Activepieces è davvero open source?

Il core lo è, con licenza MIT. Due directory, packages/ee/ e packages/server/api/src/app/ee, sono distribuite con licenza commerciale. Per usare queste funzionalità sul proprio server è necessaria una licenza a pagamento. La pagina dei prezzi del vendor indica che Agents and Chat, Projects, accesso alle API, single sign-on, ruoli utente, audit log, secret manager, branding e sincronizzazione Git non fanno parte della Community Edition. Il numero di esecuzioni, utenti e flussi resta invece senza limiti prefissati. Quindi Activepieces è realmente open source per creare ed eseguire automazioni, ma non per il livello dedicato a team e governance.

Quanta RAM richiede Activepieces su un VPS?

La documentazione di Activepieces indica 0.5 vCPU e 1 GB per ogni worker, 1 vCPU e 1 GB per il container dell'applicazione, 4 GB per Postgres e 1 GB per Redis. Un worker gestisce un solo flusso alla volta per tutta la durata del flusso. È quindi necessario dimensionare l'installazione in base al numero massimo di flussi simultanei, non alla frequenza con cui si attivano i trigger. Il file compose nel repository avvia cinque worker, per un dimensionamento indicativo di circa 11 GB. Due worker su un VPS da 4 GB sono un punto di partenza ragionevole. docker stats --no-stream consente di verificare il consumo effettivo dei propri flussi durante l'esecuzione.

Che cosa devo includere nel backup perché il ripristino funzioni davvero?

Il dump del database e la chiave di cifratura, entrambi. Per Activepieces si tratta di un pg_dump del database activepieces e del file .env che contiene AP_ENCRYPTION_KEY. Per n8n servono il database e N8N_ENCRYPTION_KEY. Se non è mai stato impostato, n8n lo ha generato nella directory ~/.n8n. Per Node-RED è necessario eseguire il backup dell'intero volume /data, perché contiene sia il file delle credenziali sia la chiave che lo decifra. Windmill è l'eccezione: la chiave del workspace si trova nel suo database Postgres. Il dump contiene quindi tutto e deve essere protetto come se contenesse direttamente i secret.

Posso importare i miei workflow di n8n in un altro strumento?

No. Questi progetti importano ed esportano i propri formati di flusso, non quelli di n8n. Una migrazione richiede la ricostruzione di ogni flusso nel nuovo builder e la ricreazione di ogni credenziale utilizzando il servizio originale. Questo lavoro è il costo reale del cambio di piattaforma. È quindi opportuno conteggiare i flussi prima di decidere. Dodici flussi richiedono un pomeriggio. Duecento flussi costituiscono un progetto e, nella maggior parte dei casi, è più economico risolvere il consumo eccessivo di memoria di n8n con queue mode e Postgres che ricostruirli tutti.

#n8n#activepieces#windmill#workflows#self-hosting