Dify vs LiteLLM: you probably need both
Dify and LiteLLM are not alternatives to each other. LiteLLM is a gateway: one OpenAI-format endpoint in front of 100+ providers, with virtual keys, spend tracking and budgets. Dify is an app platform: RAG pipelines, agents and visual workflows built on top of whatever model provider you give it. Most teams run Dify pointed at LiteLLM.
Every licence and version on this page was read from the project's own repository or docs on 2026-09-09. Where a number came from our own Docker test instead, it says so, with the date it was measured.
Which one do I actually need?
| If you want to… | Use | Why |
|---|---|---|
| Give five developers one API key and see who spends what | LiteLLM | Virtual keys, per-key budgets, load balancing and fallbacks, per BerriAI/litellm |
| Build a chatbot over your own documents without writing the retrieval code | Dify | Workflow, RAG pipeline, agent and prompt IDE in one platform, per langgenius/dify |
| Run a model on your own hardware, no API key at all | Ollama | MIT-licensed runtime with an OpenAI-compatible endpoint on :11434/v1 |
| Give a team a ChatGPT-style window over models you already have | Open WebUI | Self-hosted chat UI that speaks both Ollama and OpenAI-compatible APIs |
| Cap spend and build apps | LiteLLM and Dify | Different layers. See the stack order below. |
If you only need one of these, it is usually LiteLLM. A gateway pays for itself the first month someone leaves a runaway agent loop running against a frontier model. Dify pays off later, when you have more than one LLM app to maintain.
How do the four layers stack up?
The pieces compose because all four speak the OpenAI wire format. In deployment order:
- Runtime. Ollama serves local models and exposes OpenAI-compatible endpoints at
http://localhost:11434/v1, including/v1/chat/completions(ollama.com/blog/openai-compatibility). vLLM is the alternative when you need production throughput rather than a one-command install. - Gateway. LiteLLM proxies that runtime alongside your hosted providers. Clients point an OpenAI SDK at the proxy —
base_url="http://0.0.0.0:4000"in LiteLLM's own README example — and the gateway decides which provider actually serves the call. - App platform. Dify connects to the gateway through its first-party OpenAI-API-compatible model provider, which covers LLM, text-embedding, rerank, speech-to-text and TTS model types (dify-official-plugins). Dify never needs to know a provider key; LiteLLM holds them.
- Chat UI. Open WebUI sits beside Dify, not under it. It describes itself as "a self-hosted AI platform that's extensible, feature-rich, user-friendly, and built to run entirely offline" (docs.openwebui.com), and it talks to Ollama or to any OpenAI-compatible URL — including the same LiteLLM proxy.
The practical consequence: put LiteLLM in first. Every layer above it then has one endpoint to configure and one place where keys and budgets live.
What do these actually cost in RAM?
Measured on our own Docker host (4 vCPU) on 2026-05-02, on the versions listed. Current releases are newer, so treat these as the floor, not a guarantee.
| Tool | Layer | Idle RAM measured | Version tested | Latest release (2026-09-09) |
|---|---|---|---|---|
| Ollama | Runtime | ~100 MB with no model loaded; ~5.1 GB with Llama 3 8B | v0.6.5 | v0.33.3 (2026-09-02) |
| LiteLLM | Gateway | 400 MB, including PostgreSQL and Caddy | v1.49.5 | v1.100.0 (2026-09-06) |
| Open WebUI | Chat UI | 300 MB, SQLite, no separate database container | v0.6.5 | v0.11.3 (2026-08-31) |
| Dify | App platform | 3 GB across 8 containers | v1.1.3 | 1.17.0 (2026-08-25) |
The gap between the runtime and the app platform is the whole sizing story. Ollama, LiteLLM and Open WebUI together idle under 1 GB before a model loads. Dify alone idles at 3 GB, because it brings PostgreSQL, Redis and Weaviate with it. A 4 GB box runs the first three comfortably and will thrash under Dify.
Release cadence is worth a look before you pin versions. Ollama, LiteLLM and Open WebUI each shipped a stable release in the ten days before 2026-09-09 — v0.33.3 on 2026-09-02, v1.100.0 on 2026-09-06 and v0.11.3 on 2026-08-31. Pin a tag in your Compose file and upgrade deliberately.
Which licence clauses actually bite when you self-host?
All four are open source. Two of them attach conditions that matter the moment your deployment stops being a personal one.
| Tool | Licence as published on 2026-09-09 | The clause to read before you deploy |
|---|---|---|
| Ollama | MIT | None |
| LiteLLM | MIT, except the enterprise/ directory | Anything under enterprise/ is licensed separately by enterprise/LICENSE |
| Open WebUI | "Open WebUI License": BSD 3-Clause text plus a branding clause | You may not alter, remove or obscure Open WebUI branding above 50 end users |
| Dify | Modified Apache 2.0 | No multi-tenant operation without written authorisation; no removing the console LOGO or copyright |
| Flowise | Apache 2.0, except the enterprise directory and specific flagged files | Flagged files carry a Commercial License |
| AnythingLLM | MIT | None |
The Open WebUI branding clause is the one people get wrong. Its LICENSE is no longer plain BSD-3-Clause. Clause 4 prohibits altering, removing, obscuring or replacing any "Open WebUI" branding, "including but not limited to the name, logo, or any visual, textual, or symbolic identifiers," with three exemptions: deployments with no more than fifty end users in any rolling 30-day period, specific prior written permission, or an enterprise licence. That clause was added to the LICENSE file on 2025-04-18 and the file was last revised on 2026-04-14. If you white-label Open WebUI for an internal tool and cross fifty users in a month, you are in breach. Under fifty, rebrand freely.
Dify's addendum is narrower than its reputation. You may run Dify commercially, including as a backend for your own product. What you may not do is operate it as a multi-tenant service without written authorisation from LangGenius, or strip the LOGO and copyright from the console. Internal self-hosting is unaffected.
When should you not self-host any of this?
- Fewer than about ten users and no data-residency requirement. A hosted API key plus a hosted chat product costs less than your time keeping four containers patched. Self-hosting starts winning on cost when GPU utilisation is steady, not spiky.
- You need SSO, audit logs or granular RBAC. These sit behind commercial tiers on Dify's self-hosted edition, and behind LiteLLM's
enterprise/directory. The community editions are genuinely capable; the governance layer is where the paid line is drawn. - You want one chat UI and nothing else. Skip Dify and LiteLLM entirely. Open WebUI plus Ollama is two containers and roughly 400 MB before a model loads.
- Your bottleneck is inference speed on CPU. Our own CPU test measured 5–10 tokens/sec on Llama 3 8B with 4 vCPU (2026-05-02). That is fine for batch summarisation and painful for interactive chat. Either rent a GPU or route those calls to a hosted provider through LiteLLM and keep the local model for the cheap work.
Where does scraped web data fit?
The retrieval half of a RAG stack is usually the harder half. Dify ingests documents; it does not go and get them. If your corpus is other people's websites, the crawl, the anti-bot handling and the refresh schedule are separate problems.
That is the job we cover on the Apify side of this site: feeding live web data into a RAG pipeline covers extraction, chunking and re-crawl cadence. The Apify Store lists "70,000+ ready-to-run tools called Actors" as of 2026-09-09, which is where most teams start rather than writing crawlers. The output lands in Dify's knowledge base or a vector store; the self-hosted stack on this page handles everything after that.
Guides in this category
Each guide includes a tested Docker Compose file, measured resource numbers and the failure modes we hit.
- Ollama — CPU and GPU deployment, model sizing, keeping models warm
- LiteLLM — proxy with PostgreSQL spend tracking, virtual keys, budgets
- Open WebUI — chat UI with Caddy, multi-model, RAG and voice
- Dify — the full 8-container stack, and when not to run it
For agent-style assistants that wrap these runtimes, see self-hosted AI assistants. For the rest of the categories, see the self-hosted software index.
No. They sit at different layers. LiteLLM is a gateway that normalises 100+ providers behind one OpenAI-format endpoint and adds virtual keys, spend tracking and budgets. Dify is an application platform for RAG pipelines, agents and workflows. Dify connects to LiteLLM through its OpenAI-API-compatible model provider, so the usual deployment runs both.
Yes, two ways. Point Dify's OpenAI-API-compatible provider straight at Ollama's OpenAI endpoint on port 11434, or put LiteLLM in between. The second option is better once you have more than one model or more than one team, because budgets and keys then live in one place instead of being duplicated per app.
Only for the runtime, and only if you run models locally. LiteLLM, Open WebUI and Dify are all CPU workloads: they route requests and manage state. Ollama on a 4 vCPU CPU gave us 5-10 tokens/sec on Llama 3 8B when we tested on 2026-05-02, which suits batch jobs but not interactive chat. Hosted providers behind LiteLLM avoid the GPU question entirely.
Under fifty end users in any rolling 30-day period, yes. Above that, the Open WebUI License forbids altering, removing or obscuring the Open WebUI name, logo and other identifiers unless you have written permission or an enterprise licence. That branding clause was added on 2025-04-18, so older write-ups describing the project as plain BSD-3-Clause are out of date. Read the LICENSE file before you ship a rebrand.
Without Dify, about 800 MB idle: Ollama at roughly 100 MB with no model loaded, LiteLLM plus PostgreSQL at 400 MB, Open WebUI at 300 MB, measured on 2026-05-02 on 4 vCPU Docker. Add Dify and the floor jumps to about 3 GB more, because it ships PostgreSQL, Redis and Weaviate. Then add the model itself, roughly 5 GB for Llama 3 8B.