Salta al contenuto
geekandhackGH

Automazioni · dal video

n8n con Ollama: collegare un LLM locale a un workflow

n8n può orchestrare richieste verso Ollama, ma l'indirizzo cambia se uno dei due gira in Docker. Ecco l'architettura da verificare, il payload di chat e i principali controlli di sicurezza.

Di Manu · Pubblicato il

n8n può orchestrare un workflow che invia un prompt a un modello Ollama e usa la risposta nei passaggi successivi. Il punto che più spesso crea errori è la rete: se n8n gira in un container, localhost indica il container n8n, non necessariamente il PC dove sta girando Ollama. Prima di costruire il flusso, individua dove ascolta Ollama e come il container n8n può raggiungerlo.

Architettura: dove girano n8n e Ollama?

  • n8n e Ollama installati direttamente sullo stesso PC: usa l'endpoint locale del servizio Ollama, documentato su localhost:11434.
  • n8n in Docker Desktop su Windows/macOS e Ollama sul sistema host: Docker Desktop documenta host.docker.internal per raggiungere servizi del computer host dal container.
  • n8n e Ollama in container sulla stessa rete Docker: usa il nome del servizio e la porta interna del container, ad esempio ollama:11434, dopo aver verificato rete e Compose effettivi.
  • Docker Engine su Linux: la risoluzione verso l'host dipende dalla rete e dalla configurazione Docker; non copiare host.docker.internal senza verificarlo nel proprio ambiente.

Il flusso minimo da costruire

  • Manual Trigger per provare il flusso senza esporre un webhook pubblico.
  • Un nodo di input che fornisce un campo prompt controllato.
  • Un nodo HTTP Request che invia POST all'endpoint /api/chat raggiungibile dal container.
  • Un passaggio di validazione che controlla la risposta prima di passarla ad altri nodi o servizi.

Payload di esempio per l'API chat di Ollama

L'API di chat di Ollama accetta un modello e una lista di messaggi. Il nome deve corrispondere a un modello effettivamente installato; lo streaming va disattivato se il nodo successivo si aspetta un singolo oggetto JSON.

{
  "model": "MODELLO_INSTALLATO",
  "messages": [
    {
      "role": "user",
      "content": "PROMPT_DAL_WORKFLOW"
    }
  ],
  "stream": false
}

Dopo la prima prova, controlla nella risposta effettiva il campo message.content e costruisci il mapping in n8n sulla struttura restituita dalla tua versione. Non assumere che output, timeout o dimensione del contesto siano uguali per tutti i modelli.

Errori comuni e come interpretarli

  • Connection refused verso localhost: il container sta cercando Ollama dentro sé stesso. Usa l'host Docker o il nome del servizio sulla rete condivisa.
  • Modello non trovato: verifica il nome esatto del modello installato e provalo prima direttamente con l'API locale.
  • Timeout o memoria insufficiente: prova un modello più piccolo e un contesto più breve; RAM/VRAM e durata dipendono dal modello e dall'hardware.
  • Risposta non valida per il workflow: controlla il payload, disattiva lo streaming per i nodi che si aspettano JSON completo e valida lo schema prima di proseguire.

Sicurezza: non pubblicare le porte locali

Mantieni l'API Ollama e l'editor n8n su reti fidate mentre fai prove. Non esporre la porta 11434 o l'editor n8n direttamente a Internet senza autenticazione e configurazione di rete consapevole. Se un workflow chiama Telegram, un CRM o altri servizi cloud, quei dati escono dal PC: il modello locale da solo non rende locale l'intero workflow.

Fonti e approfondimenti

Fonte: API chat ufficiale di Ollama

Fonte: Docker Desktop networking: accesso ai servizi host

Fonte: Documentazione n8n: installazione con Docker Compose

Fonte: Guida correlata: modelli Ollama e Decision Models sul PC