Dify 1.16.1
A workflow-and-agent platform with knowledge base features, deployed and measured against the same corpus as every other platform here.
In one paragraph
Deployed from its published image, Dify runs 15 containers and held 2,572.7 MB at peak during ingestion. It retained 82% of the facts planted in the corpus and answered 66% of the retrieval questions correctly.
Measured
| Measurement | Result | How |
|---|---|---|
| Time to first served request | 39 s | Includes image pull, from a clean host |
| Containers | 15 | Running after the stack settles |
| Idle memory | 1,948.1 MB | Sum across containers, 60s after ready |
| Peak memory during ingestion | 2,572.7 MB | Sampled every 5s across the whole corpus |
| Documents ingested | 11/11 | Failures counted, not excluded |
| Chunks stored | 1,149 | Across the whole corpus |
| Parsing fidelity | 82% | Planted facts found in stored chunks |
| Retrieval accuracy | 66% | Answer present in top-5 context, 29 questions |
| Retrieval latency | 303.4 / 359.9 ms | p50 / p95, CPU embedding |
| Licence | Dify Open Source License (Apache-2.0 with additional conditions) | Prohibits offering it as a service |
What it does well
- A dedicated retrieval endpoint separate from generation, so search quality can be measured on its own
- The most granular chunking of the platforms measured, which favours precise retrieval over broad context
- A clean separation between an administrative console API and a stable knowledge API with its own key
Where it falls short
- Ships with no model providers at all — every one is a marketplace plugin, so a self-hosted install has a hard dependency on reaching an external service before it can use any model
- Installing a provider plugin does not invalidate the cached provider list, so every layer reports success while the console keeps returning nothing until the cache is dropped
- The compose file is not self-contained; downloading it alone produces containers that crash-loop on missing mounts
- `docker compose down --volumes` does not reset it — state lives in host-mounted directories, so a 'clean' re-run silently inherits the previous database
- Account setup accepts a plaintext password while login requires the same password base64-encoded, and neither endpoint documents the difference
Choose it when
- Teams that want agent and workflow orchestration alongside a knowledge base
- Deployments with reliable outbound internet access
Choose something else when
- Air-gapped environments — without marketplace access it cannot reach a model at all
- Anyone relying on `compose down -v` to reset state between runs
Deployment notes
Fifteen containers in the default profile, more than any other platform measured — which is worth stating because the common impression is the reverse. Memory sits close to FastGPT’s despite the higher count.
The cache that hides a successful install
The most expensive thing to diagnose here is not a failure but a success that does not show up. After installing a provider plugin, the daemon logs the install as finished, both database tables carry the records, and the daemon’s own API returns the model declarations — while the console API returns an empty list. The provider list is cached and the cache is not invalidated on install. Anyone automating this will conclude the install failed and try again.