Dify
temaki.dify
A Docker Compose file for Dify alone, generated from the catalog and checked by the safety inspector. No account needed.
Platform for building language-model applications, combining a visual workflow canvas, prompt orchestration, retrieval datasets, tool-calling agents and observability in one interface.
Dify covers the path from prompt to deployed application: a visual canvas wires model calls, conditionals, retrieval steps and tool invocations into a workflow, and the finished application is published as a hosted chat interface, an embeddable widget or an API. Retrieval datasets handle document ingestion, chunking and indexing within the platform, so a knowledge-grounded assistant does not require a separately assembled pipeline. Model providers are configured centrally, letting the same application be repointed between hosted and local endpoints. Logging captures each run's inputs, outputs and cost for review.
You know it worked when
- The console loads and an administrator account is created.
- A model provider is configured and passes its connection test.
- An application built on the canvas returns a completion in the test panel.
- A document uploaded to a dataset is indexed and retrieved as context.
- The published application answers over its API endpoint.
Known sharp edges
- The licence forbids operating Dify as a multi-tenant service without written authorisation, where one tenant means one workspace — a limit that has nothing to do with the software's technical capability.
- Console logo and copyright notices may not be removed from the frontend, which rules out white-labelling under the free terms.
- Self-hosting is a multi-container stack requiring PostgreSQL, Redis and a vector store, and a failure in any of them surfaces as an unexplained error in the console.
- Model provider credentials are held centrally and inherited by every application in the workspace, so scoping happens through workspaces rather than per application.