n8n + Ollama: Self-Hosted AI Automation in Docker

Published on April 10, 2026 · Updated August 23, 2026 — 18 min read

To run self-hosted AI automation, pair n8n (an open-source workflow engine) with Ollama (a local model runtime) in Docker and connect them through n8n's native Ollama node, added in n8n v1.25. Both are open source, so the only recurring cost is the electricity your machine draws — there is no per-task fee and no per-token bill. A 3B-class model runs on 8GB of RAM without a GPU; 16GB and an NVIDIA card make 7B-class models comfortable.

Most AI automation advice starts with "connect to the OpenAI API" and ends with a bill that scales with your success. The alternative is to run the workflow engine and the model on the same box you already own: n8n handles triggers, branching and 400+ integrations, Ollama serves the model over localhost, and neither one charges per execution.

Whether that is actually cheaper for you is arithmetic, not opinion — the cost section below gives you the formula rather than a number from someone else's setup. This guide covers the Docker stack, three workflows that do real work, and the honest limits of local models in an automation pipeline.

---

What you will build:

• n8n + Ollama running together in Docker
• Workflow 1: Automatic email summarizer (IMAP trigger → Ollama → Slack)
• Workflow 2: Document processor (webhook → file parse → Ollama → database)
• Workflow 3: Customer support chatbot (webhook → Ollama with context → response)
• Cost comparison and migration strategy from cloud tools

Prerequisites:

• A machine with Docker installed (Linux, macOS, or Windows with WSL2)
• 8GB+ RAM (16GB recommended for running 7B models alongside n8n)
• Basic understanding of REST APIs and JSON

For local AI model setup, see the free local AI models guide. For AI agent patterns that pair well with n8n, check the AI agents local guide.

Table of Contents

1. What is n8n and Why Pair It with Ollama
2. Docker Setup for n8n + Ollama
3. Connecting n8n to Ollama
4. Workflow 1: Email Summarizer
5. Workflow 2: Document Processor
6. Workflow 3: Support Chatbot
7. Triggers, Scheduling, and Webhooks
8. Cost Comparison: n8n + Ollama vs Cloud
9. Performance and Limitations
10. Troubleshooting
11. n8n in Mid-2026: What Changed

---

What is n8n and Why Pair It with Ollama {#what-is-n8n}

n8n is an open-source workflow automation platform. Think Zapier or Make.com, but you host it yourself and there are no per-execution limits. It has a visual editor where you drag and drop nodes — triggers, actions, conditions, loops — to build automation workflows without writing code.

n8n ships with 400+ integrations: Gmail, Slack, PostgreSQL, HTTP webhooks, cron schedules, Google Sheets, Notion, and hundreds more. What makes it powerful for AI automation is its native Ollama node, added in n8n v1.25. If you are still deciding whether a workflow engine is the right shape at all, the Opal vs n8n vs Glide vs Next.js comparison weighs it against no-code app builders and writing the thing yourself.

Why this combination works:

The tradeoff: local models are slower than GPT-4o and less capable at complex reasoning. For 80% of automation tasks — summarization, classification, extraction, reformatting — a local 7B or 13B model handles it fine. The 20% where you genuinely need GPT-4-level intelligence can still use a cloud API through n8n's OpenAI node.

---

Docker Setup for n8n + Ollama {#docker-setup}

Docker Compose File

mkdir -p ~/n8n-ollama && cd ~/n8n-ollama

# docker-compose.yml
version: "3.8"

services:
  ollama:
    image: ollama/ollama:latest
    container_name: ollama
    restart: unless-stopped
    ports:
      - "11434:11434"
    volumes:
      - ollama_data:/root/.ollama
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: all
              capabilities: [gpu]
    environment:
      - OLLAMA_NUM_PARALLEL=2
      - OLLAMA_FLASH_ATTENTION=1

  n8n:
    image: docker.n8n.io/n8nio/n8n:latest
    container_name: n8n
    restart: unless-stopped
    ports:
      - "5678:5678"
    volumes:
      - n8n_data:/home/node/.n8n
    environment:
      - N8N_HOST=0.0.0.0
      - N8N_PORT=5678
      - N8N_PROTOCOL=http
      - WEBHOOK_URL=http://localhost:5678
      - N8N_DIAGNOSTICS_ENABLED=false
      - N8N_HIRING_BANNER_ENABLED=false
    depends_on:
      - ollama

volumes:
  ollama_data:
  n8n_data:

Launch and Pull Models

# Start both services
docker compose up -d

# Wait 10 seconds for Ollama to initialize, then pull models
docker exec ollama ollama pull llama3.2
docker exec ollama ollama pull qwen3:8b

# Verify both are running
docker compose ps

# n8n is at http://localhost:5678
# Ollama API is at http://localhost:11434

CPU-Only Setup

If you do not have an NVIDIA GPU, remove the deploy block from the Ollama service. Pull a smaller model:

docker exec ollama ollama pull phi3:mini
docker exec ollama ollama pull gemma:2b

CPU generation is slower than GPU by roughly the ratio of their memory bandwidths — dual-channel system RAM moves on the order of 80-90 GB/s against several hundred for a discrete GPU — because producing each token requires reading the whole model out of memory. For background automation, where nothing is waiting on a response, that is usually an acceptable trade. Measure your own figure rather than guessing: docker exec -it ollama ollama run phi3:mini --verbose "hello" prints an eval rate line in tokens/second after the response.

---

Connecting n8n to Ollama {#connecting}

Step 1: Create Ollama Credentials in n8n

1. Open n8n at http://localhost:5678
2. Create your admin account (first-time setup)
3. Go to Settings → Credentials → Add Credential
4. Search for Ollama
5. Set the Base URL to http://ollama:11434
   • Use ollama (the Docker service name), not localhost
6. Click Save

Step 2: Test the Connection

Create a quick test workflow:

1. Click Add Workflow → Add first step
2. Add a Manual Trigger node (just to test)
3. Add an Ollama Chat Model node
4. Configure it:
   • Credential: select the Ollama credential you created
   • Model: llama3.2
5. Add a Basic LLM Chain node
6. Connect: Manual Trigger → Basic LLM Chain (with Ollama Chat Model as the AI model)
7. Set the prompt to: Summarize in one sentence: The quick brown fox jumped over the lazy dog.
8. Click Test Workflow

If you get a response, the connection works. If not, check the troubleshooting section.

---

Workflow 1: Email Summarizer {#email-summarizer}

This workflow checks your inbox every 5 minutes, summarizes new emails with Ollama, and posts the summaries to Slack — so you triage a channel of three-line summaries instead of an inbox.

Workflow Structure

[IMAP Trigger] → [Filter: skip newsletters] → [Ollama: summarize] → [Slack: post to channel]

Node Configuration

1. IMAP Email Trigger

• Mailbox: INBOX
• Poll interval: 5 minutes
• Credential: Your email (Gmail, Outlook, or any IMAP server)

2. IF Node (Filter)

• Condition: {{ $json.from }} does not contain "newsletter" AND does not contain "noreply"
• This skips marketing emails and only processes real messages

3. Ollama Chat Model + Basic LLM Chain

• Model: llama3.2 (fast enough for summarization)
• System prompt:

You are an email summarizer. For each email, produce:
1. SENDER: who sent it
2. URGENCY: high/medium/low
3. SUMMARY: 2-3 sentences max
4. ACTION NEEDED: yes/no, and what action

Be concise. No filler.

• User prompt: Summarize this email:\nFrom: {{ $json.from }}\nSubject: {{ $json.subject }}\nBody: {{ $json.text.substring(0, 3000) }}

4. Slack Node

• Channel: #email-summaries
• Message: *{{ $('IMAP').item.json.subject }}*\n{{ $json.text }}

Sizing the poll interval

The one setting to get right is the poll interval versus how long a summary takes. Time one email through the workflow (n8n shows per-node execution time in the editor), then make sure your interval comfortably exceeds emails per interval × seconds per email. Otherwise executions pile up behind each other and the queue grows all day. Five minutes is a safe starting point for a normal inbox; shorten it only after you have watched the node timings.

---

Workflow 2: Document Processor {#document-processor}

This workflow accepts PDF uploads via webhook, extracts text, chunks it, sends each chunk to Ollama for analysis, and stores structured output in a database.

Workflow Structure

[Webhook: POST /process] → [Extract PDF text] → [Split into chunks] → [Ollama: extract data] → [PostgreSQL: insert]

Node Configuration

1. Webhook Node

• Method: POST
• Path: /process
• Response mode: Last node (returns result to caller)

2. Extract from File Node

• Operation: Extract text from PDF
• Input: Binary data from webhook

3. Code Node (Text Splitter)

const text = $input.first().json.data;
const chunkSize = 2000;
const overlap = 200;
const chunks = [];

for (let i = 0; i < text.length; i += chunkSize - overlap) {
  chunks.push({
    json: {
      chunk: text.substring(i, i + chunkSize),
      index: chunks.length,
      total: Math.ceil(text.length / (chunkSize - overlap))
    }
  });
}

return chunks;

4. Ollama Chat Model + Basic LLM Chain

• Model: qwen3:8b (good at structured extraction)
• System prompt:

Extract structured data from this document chunk. Return JSON:
{
  "entities": ["list of people, companies, products mentioned"],
  "dates": ["any dates found"],
  "amounts": ["any monetary amounts"],
  "key_facts": ["2-3 important facts"],
  "category": "one of: legal, financial, technical, correspondence, other"
}
Return ONLY valid JSON. No explanation.

• User prompt: {{ $json.chunk }}

5. PostgreSQL Node

• Operation: Insert
• Table: document_extractions
• Columns: chunk_index, entities, dates, amounts, key_facts, category, processed_at

Triggering the Workflow

# Upload a PDF for processing
curl -X POST http://localhost:5678/webhook/process \
  -F "file=@contract.pdf"

---

Workflow 3: Support Chatbot {#support-chatbot}

A webhook-based chatbot that answers questions using your documentation. This is a lightweight RAG setup without a vector database — suitable for small knowledge bases (under 50 pages).

Workflow Structure

[Webhook: POST /chat] → [Load context docs] → [Build prompt] → [Ollama: answer] → [Respond to webhook]

Node Configuration

1. Webhook Node

• Path: /chat
• Method: POST
• Expected body: { "question": "How do I reset my password?" }

2. Read Binary Files Node

• Read from: /home/node/.n8n/knowledge-base/
• Pattern: *.txt
• This loads your documentation files as context

3. Code Node (Build Prompt)

const question = $('Webhook').first().json.body.question;
const docs = $input.all().map(item => item.json.data).join('\n---\n');

return [{
  json: {
    prompt: `Answer the user's question using ONLY the context below. If the context doesn't contain the answer, say "I don't have information about that."

CONTEXT:
{docs.substring(0, 6000)}

QUESTION: {question}

ANSWER:`
  }
}];

4. Ollama Chat Model + Basic LLM Chain

• Model: llama3.2
• Temperature: 0.3 (lower = more factual, less creative)
• User prompt: {{ $json.prompt }}

5. Respond to Webhook Node

• Response body: { "answer": "{{ $json.text }}" }

Testing

# Ask a question
curl -X POST http://localhost:5678/webhook/chat \
  -H "Content-Type: application/json" \
  -d '{"question": "What are your business hours?"}'

For a more sophisticated RAG setup with vector search and embedding, see the RAG local setup guide.

---

Triggers, Scheduling, and Webhooks {#triggers}

n8n supports multiple ways to start a workflow:

Cron / Schedule Trigger

Every 5 minutes: */5 * * * *
Every hour: 0 * * * *
Daily at 9 AM: 0 9 * * *
Weekdays at 8 AM: 0 8 * * 1-5

Webhook Trigger

Any external service can POST to your n8n webhook URL. Useful for:

• GitHub push events → AI code review
• Stripe payment events → AI receipt generation
• Form submissions → AI classification and routing

App-Specific Triggers

n8n has native triggers for:

• Gmail / IMAP: New email received
• Slack: New message in channel
• GitHub: Pull request opened, issue created
• Google Sheets: Row added or updated
• Telegram: New message to bot
• RSS: New feed item

Polling Triggers

For services without webhooks, n8n polls on a schedule:

• Check an API every N minutes
• Watch a folder for new files
• Monitor a database table for new rows

See the full integration list at n8n.io/integrations.

---

Cost Comparison: n8n + Ollama vs Cloud {#cost-comparison}

Every "self-hosting saves you $X" figure you will read is really a statement about someone else's workload, hardware and power tariff. Here is the model instead, so you can produce your own number in about two minutes.

The two sides of the comparison

Working out the electricity

This is the only recurring cost on the self-hosted side, and it is a one-line calculation:

monthly kWh  = average watts × 730 hours ÷ 1000
monthly cost = monthly kWh × your $/kWh

730 is the average hours in a month. Take the rate from your own utility bill — it varies by more than a factor of three between regions, which is exactly why quoting a single dollar figure here would be useless.

"Average watts" is the number people get wrong: an automation box is idle most of the time and only draws near its peak while a model is generating, so the wall figure is much closer to idle draw than to the PSU rating. A cheap plug-in power meter settles it.

Does it pay off?

break-even months = hardware cost ÷ (cloud monthly − electricity monthly)

If you already own a machine that is powered on anyway, hardware cost is zero and the answer is immediate. If you are buying one specifically for this, plug your quote into the formula before you buy — for a low-volume workload where the cloud bill is small, the honest answer is sometimes that it never pays off in cash, and you are buying privacy and no rate limits rather than savings.

Where Cloud Still Wins

Be honest about the limitations:

• Frontier-model reasoning: if your workflow needs complex multi-step reasoning, creative writing or nuanced judgement, the large hosted models still outperform local 7B-13B models by a wide margin.
• Zero maintenance: cloud services handle uptime, scaling and updates. Self-hosting means you are the ops team, and that time is a real cost the table above cannot price for you.
• First 10 minutes of setup: a cloud stack works in ten minutes. This guide takes 30-60.

The pragmatic split: run the straightforward work locally (summarization, classification, extraction, reformatting) and route the handful of workflows that genuinely need frontier reasoning through n8n's OpenAI node. n8n makes that a per-workflow choice rather than an all-or-nothing bet.

---

Performance and Limitations {#limitations}

Sizing throughput before you build

Rather than trusting anyone's tokens-per-second figure, measure yours once and derive the rest. ollama run <model> --verbose prints an eval rate after every response — that is your generation speed on your hardware, with your model and quantization. Then:

seconds per item ≈ output tokens ÷ eval rate  (+ a second or two of prompt processing)
items per hour   ≈ 3600 ÷ seconds per item

So a classification task emitting 20 tokens is nearly free regardless of hardware, while a summary emitting 200 tokens costs ten times as much. Output length, not input length, dominates the cost of a generation workflow — which makes "answer in at most three sentences" a genuine throughput optimization, not just a style preference.

If you want an upper bound before you own the hardware, generation speed cannot exceed memory bandwidth ÷ model size: a 3B model at Q4_K_M is roughly 1.8GB (about 0.6GB per billion parameters), so a card with 360 GB/s of published bandwidth tops out near 200 tok/s in theory. Real output lands well below that ceiling, but it tells you which side of "fast enough" you are on.

Bottlenecks

1. Model loading: First request after idle takes 5-15 seconds while the model loads into GPU memory. Set OLLAMA_KEEP_ALIVE=24h to keep models loaded.

2. Concurrency: With OLLAMA_NUM_PARALLEL=2, two workflows can process simultaneously. More parallel requests cause queueing. A 24GB GPU can handle NUM_PARALLEL=4 comfortably.

3. Context length: Most local models max out at 8K-32K tokens. If your document chunks are too large, the model truncates or produces garbage at the end. Keep prompts under 4K tokens for consistent results.

4. No streaming in workflows: Unlike a chatbot interface, n8n waits for the complete Ollama response before passing it to the next node. This means the total workflow time includes full generation time.

Setting OLLAMA_KEEP_ALIVE

# In docker-compose.yml, under ollama environment:
environment:
  - OLLAMA_KEEP_ALIVE=24h    # Keep model loaded for 24 hours
  - OLLAMA_NUM_PARALLEL=2

This eliminates cold-start latency at the cost of keeping GPU memory occupied.

---

Troubleshooting {#troubleshooting}

n8n cannot find the Ollama credential type

You need n8n v1.25 or newer. Check your version:

docker exec n8n n8n --version
# If below 1.25, update:
docker compose pull n8n
docker compose up -d n8n

"Connection refused" when n8n connects to Ollama

# The Ollama URL in n8n must use the Docker service name, not localhost
# Correct: http://ollama:11434
# Wrong:   http://localhost:11434

# Test from inside the n8n container
docker exec n8n curl -s http://ollama:11434/api/version

Ollama returns empty or garbled responses

# Check if the model is actually loaded
docker exec ollama ollama list

# Test the model directly
docker exec ollama ollama run llama3.2 "Say hello"

# If it works directly but not through n8n, the prompt may be too long
# Reduce chunk sizes or use a model with larger context window

n8n workflow times out

Default timeout for HTTP nodes in n8n is 60 seconds. Ollama can take longer for large prompts on CPU.

# Increase n8n timeout
environment:
  - N8N_DEFAULT_TIMEOUT=300

High memory usage

# Check what is consuming memory
docker stats

# n8n typically uses 200-500MB
# Ollama uses 4-12GB depending on the loaded model

# If running out of memory, use a smaller model
docker exec ollama ollama pull phi3:mini  # Only ~2GB in VRAM

Workflows stop running after restart

Make sure n8n workflows are set to Active (the toggle in the top-right of the workflow editor). Only active workflows run automatically. Manual triggers require you to click "Test" each time.

---

Migration from Zapier / Make.com

If you are currently using cloud automation tools, here is a practical migration path:

1. Audit your workflows: List every Zap or Scenario. Tag each as "simple AI task" or "needs GPT-4."
2. Recreate in n8n: Start with the highest-volume simple workflows. n8n has import guides for Zapier workflows.
3. Test side-by-side: Run both for a week. Compare output quality.
4. Cut over gradually: Disable cloud workflows one at a time as you validate the n8n replacements.
5. Keep a cloud fallback: Keep one OpenAI API node in n8n for tasks that genuinely need GPT-4o. Most workflows will not need it.

---

n8n in Mid-2026: What Changed {#mid-2026-update}

Update — August 23, 2026. Everything above still works on current n8n, which has been shipping weekly on the 2.x line. The Docker setup in this guide pulls the latest tag, so docker compose pull n8n puts you on the current release. Two additions from the 2026 releases are worth knowing about — check n8n's release notes for the version each one landed in, since that moves faster than any article:

• One-click MCP server connections. You can now pick an MCP server straight from the nodes panel, sign in, and your AI agent can use it — no manual MCP Client node configuration. If you want an Ollama-powered agent to reach external tools, this is the fastest path.
• Agent upgrades. Per n8n's docs, recent releases brought agentic loops with multi-agent delegation, tool-level human-in-the-loop approval (require sign-off before an agent runs a specific tool), and binary PDF passthrough in the AI Agent node, which lets an agent accept PDF files directly.

None of this changes the core setup: the Ollama credential, the Basic LLM Chain patterns and the cost model above all still apply.

---

Building more complex AI agents? See the AI agents local guide for multi-step reasoning patterns. For a visual flow builder alternative, check out Flowise + Ollama.