Solutions for
Please select
Try the Web App
ki-werkzeuge

Self-Hosted Agent Stack (n8n, Dify, Ollama)

Redaktion ·

When client data must not leave the building — why this matters to you

A tax firm wants to pre-sort client receipts automatically. A medical practice wants a model to summarize contact-form enquiries. Both hit the same wall: the moment the data goes to OpenAI or Anthropic, it leaves their own infrastructure. For many regulated industries that is a non-starter — not on principle, but because of professional confidentiality, data-processing agreements, and the question of what ends up in the record of processing activities if something goes wrong.

This is exactly where the self-hosted AI stack comes in. The combination of n8n, Dify and Ollama has become the pragmatic standard in 2026 for running AI automation entirely on your own hardware — without a single token leaving the server. The appeal isn’t ideology, it’s a clean division of labor: each of the three tools owns one layer, and none of them tries to do the others’ job.

This article explains who does what, how the three work together, what it costs versus the cloud (in money and in effort) and which use cases make the work worthwhile. By the end you should be able to explain the stack to someone who has never seen a Docker Compose file.

The core mechanics: three layers, three jobs

The most common mistake in self-hosting attempts is grabbing a single tool and piling everything onto it — integrations, prompt logic, RAG, model hosting. That ends in an unmaintainable monolith. The n8n/Dify/Ollama stack does the opposite: it separates three things that most DIY setups blend together.

Layer 1 — Ollama: the model runtime

At the very bottom sits Ollama. It is the runtime that executes open-weight models (Llama, Mistral, Qwen, Gemma and many others) on your own hardware. You pull a model with a command like ollama pull llama3.1, and Ollama exposes it over an HTTP API. Crucially, that API is OpenAI-compatible. Any tool that can talk to the OpenAI interface can talk to Ollama too — you just swap the base URL. That single fact is what makes the whole stack pluggable.

Ollama doesn’t care about workflows or prompts. A request comes in, an answer goes out. Full stop. It’s the lowest, dumbest and most important layer — it keeps the actual language model running.

Layer 2 — Dify: the LLM app platform

In the middle sits Dify. This is where you build what people actually mean by an “AI application”: conversational apps, agent-style flows, knowledge bases (RAG), prompt and version management. Dify is the layer where the LLM logic lives — which system prompt applies, which documents get pulled into context, how a chatbot’s memory works.

Two things matter for the integration: Dify talks to Ollama as a model backend via plugins, and Dify exposes the finished result back as an API. So you build a RAG chatbot over your company PDFs inside Dify and end up with an endpoint that other systems can call.

Layer 3 — n8n: the workflow automation

At the top sits n8n. It’s the automation bus: triggers (webhooks, schedules, polling), branching, retries on failure, and above all hundreds of connectors to SaaS services — email, CRM, databases, file storage. n8n is the tool that moves data from A to B and enforces the business logic of the flow.

n8n itself is not an AI tool. It calls the AI layer (Dify, or Ollama directly) as one step among many. To put it in familiar terms: n8n is the self-hosted counterpart to Make or Zapier — except it runs on your server and there are no per-task fees.

How the three work together — the typical architecture

The most common pattern looks like this: an event hits n8n (new email, uploaded file, scheduled run). n8n prepares the data and calls Dify as the AI layer. Dify takes the request, pulls relevant documents from its knowledge base if needed (RAG), assembles the prompt and sends it to Ollama. Ollama runs the model and returns the answer — back through Dify to n8n, which then processes the result (writes to a database, sends a reply email, posts to Slack).

The clean separation has a concrete payoff: you can swap each layer independently. A better open-weight model drops? One ollama pull and you’re done — Dify and n8n never notice. Want to rework the RAG logic? That happens only in Dify. A new data source appears? Only n8n gets touched.

When you can drop Dify

Not every use case needs all three layers. For simple tasks — “summarize this email”, “classify this enquiry into three buckets” — n8n can talk to Ollama directly and skip Dify. n8n supports Ollama endpoints natively. Dify earns its place once RAG, conversation memory, agent behavior or a reusable AI API come into play. For pure “text in, text out” it’s overhead.

Pitfalls almost everyone underestimates

Hardware is the real cost block. Self-hosting isn’t free — you’re just moving the cost from the cloud bill to hardware and ops effort. A usable local model needs a GPU with decent VRAM. One practitioner running an NVIDIA A10 (24 GB VRAM) reports being able to load several smaller models at once, or a single larger one. Rule of thumb: small models (7–8B, quantized) run on consumer GPUs from around 8–12 GB VRAM, large ones (70B) need substantially more or must be heavily quantized — with noticeable quality loss.

“Self-hosted” doesn’t automatically mean “sealed”. Logs, traces and third-party plugins can leak context if you’re not deliberate. Add a plugin to Dify or a cloud connector to n8n that phones home, and you’ve already broken the privacy promise. Self-hosting is a foundation, not a guarantee.

Operations is work. Updates, backups, GPU drivers, reverse proxy, TLS, monitoring — everything the cloud provider handles for you, you now handle yourself. For an agency with IT skills, that’s doable. For a solo operator with no ops experience, it’s often the point where the cloud wins after all.

Self-hosted vs. cloud — the honest comparison

| Criterion | Self-hosted stack | Cloud AI (OpenAI/Anthropic) | |---|---|---| | Privacy | Data stays on your hardware | Data goes to the provider (DPA required) | | Running cost | Hardware + power + ops time, no token fees | per-token billing, no hardware capex | | Barrier to entry | high (GPU, Docker, operations) | low (an API key is enough) | | Model quality | open-weight, limited by hardware | frontier models, best quality | | Scaling | bounded by your own hardware | effectively unlimited | | Control | full control over stack and updates | dependent on the provider |

The decision is rarely black and white. Many setups run hybrid: sensitive routine workloads locally via Ollama, demanding tasks (complex analysis, high-quality copy) via a cloud API. n8n as the orchestration layer makes that fork trivial — the same workflow can route to one AI layer or the other depending on data sensitivity. For how the pure automation side works without AI, see the article on automating AI workflows.

Worked example: receipt pre-sorting in a tax firm

Played out concretely: a firm receives client receipts by email. n8n watches the inbox (trigger), grabs the attachment, sends the PDF to Dify. Dify uses a local model via Ollama to extract the relevant fields (date, amount, category) and matches them against a knowledge base of accounts (RAG). The structured result goes back to n8n, which writes the record into the firm’s software and, when uncertain, raises a query for a human to check.

The decisive point: not a single receipt leaves the firm’s server. Professional confidentiality is preserved, no DPA with a US provider is needed, and the running cost is the hardware — not a token bill that grows with every new client.

FAQ

Do I really need all three tools?
No. For simple "text in, text out" tasks, n8n can talk to Ollama directly and Dify is optional. Dify only pays off once you need RAG, conversation memory or a reusable AI API.
What's the minimum hardware?
Small, quantized models (7–8B) run on consumer GPUs from around 8–12 GB VRAM. Larger models (70B) need much more — one practitioner runs several models in parallel on an NVIDIA A10 with 24 GB VRAM.
Is self-hosting automatically GDPR-compliant?
No. The stack is the foundation, not a guarantee. Logs, traces and third-party plugins can leak data. You have to actively make sure nothing goes out.
Is it cheaper than the cloud?
It shifts the cost. You save token fees but pay for hardware, power and above all operations. Self-hosting tends to win at high, steady volume rather than sporadic use.
Do I get the same quality as GPT or Claude locally?
Usually not. Open-weight models on affordable hardware sit below the frontier models of the big providers. That's fine for many routine tasks — often not enough for demanding copy or complex analysis.

Conclusion

The self-hosted stack of n8n, Dify and Ollama is, in 2026, the pragmatic answer to a simple question: how do I use AI without giving up control of my data? Its strength is clean layering — Ollama runs models, Dify builds the AI logic, n8n wires it all into the real world. Each layer is independently swappable, and for simple cases two of the three are enough.

The price is honesty about effort: hardware costs money, operations costs time, and frontier-model quality isn’t free locally. For industries with hard privacy requirements — firms, practices, public bodies — the stack is often still the only clean option. For everyone else, the hybrid approach pays off: local where it’s sensitive, cloud where quality counts.

Themenuebersicht

KI-WerkzeugeWorkflow-Automation