Dify: self-hosted LLM app platform with a visual workflow canvas

The gap Dify fills between a model API and a shipped app

Calling a model is easy. What surrounds the call is not: chunking and embedding documents, retrieving the right passages, giving the model tools, logging what happened, and exposing the result as an endpoint another service can call. Teams usually rebuild that shell for each new application, and each rebuild drifts.

Dify's answer is to make that shell a product. The README describes it as an open-source LLM app development platform whose interface combines AI workflow, a RAG pipeline, agent capabilities, model management and observability. The intended user is a team that wants to iterate on prompts and retrieval in a browser, then call the same application over HTTP from its own backend. The README's Backend-as-a-Service point states that all of Dify's offerings come with corresponding APIs.

The repository is not archived, and the last push was on 2026-08-25, the same day as release 1.17.0. That is recent enough that the project is being worked on, but the README does not describe a support window or a long-term release channel, so plan your own upgrade cadence.

How the pieces fit: web canvas, API, workers, plugin daemon

The top-level layout tells you more about the architecture than the README does. There is web/ for the frontend, api/ for the Python backend, packages/ for shared TypeScript code, sdks/ for client libraries, cli/, and two directories named dify-agent/ and dify-agent-runtime/. The Makefile lists image variables for dify-web, dify-api and dify-agent-local-sandbox, which confirms that the agent sandbox runs as its own container rather than inside the API process.

The data flow follows from that split. You build a workflow or a chat application on the canvas in web/; the definition is stored by api/; when the application runs, api/ orchestrates the model calls and the retrieval steps, and tool execution that needs isolation is handed to the sandbox image. Documents you upload go through the RAG pipeline described in the README, which covers ingestion through retrieval with text extraction from PDFs, PPTs and other common formats. Model access is not hardcoded: the README says Dify integrates with proprietary and open-source models from dozens of inference providers plus self-hosted solutions, including anything that speaks the OpenAI API shape.

This is a multi-service system by design. That choice buys isolation and independent scaling, and it is the reason a plain single-process deployment is not on the table.

Installing Dify with Docker Compose and reaching the dashboard

The README's quick start is the shortest path. It states the minimum machine requirements as 2 CPU cores and 4 GiB of RAM, and requires Docker plus Docker Compose v2.24.0 or later. From the repository root, you enter the docker directory, copy the example environment file, and bring the stack up detached.

cd dify
cd docker
cp .env.example .env
docker compose up -d

After the containers start, the README says the dashboard is reachable at http://localhost/install, where you complete the initialization process. If the stack does not come up, the README points to the self-hosting FAQ in the documentation rather than listing failure modes inline.

If you intend to change Dify itself rather than just run it, the README directs you to a separate guide for deploying from source code. That path is heavier: the Makefile shows a dev-setup target that copies docker/envs/middleware.env.example to docker/middleware.env, starts docker-compose.middleware.yaml under the project name dify-middlewares-dev, copies web/.env.example to web/.env.local, runs pnpm install, copies api/.env.example to api/.env, then runs uv sync --dev and uv run flask db upgrade inside api/. The database migration step is part of setup, not an afterthought.

make dev-setup

That target prepares the environment; the Makefile comments note that the web and API environments are prepared but not started.

Where Dify is the wrong tool

The first limitation is operational weight. A Dify deployment is a set of containers with their own datastore and middleware, not a library you import. If your application is a single prompt against a single model, you are paying for orchestration you will not use. The README gives no lightweight mode, and the repository layout offers no single-binary path.

The second is the licence. The repository has a LICENSE file at the top level, but the metadata I have does not identify which licence it is, and the README does not restate the terms. Dify also sells cloud and enterprise editions, so the boundary between the community edition and the paid editions matters for anyone embedding it in a commercial product. Read LICENSE yourself; do not assume it is a permissive licence because the source is public.

The third is upgrade cost. Releases 1.16.0, 1.16.1 and 1.17.0 landed between 2026-07-17 and 2026-08-25. That pace is good for fixes and awkward for operators, because the README does not document rollback, and the Makefile's migration step implies schema changes are part of upgrades. Pin an image version rather than tracking latest.

Finally, the abstraction has edges. Anything the canvas cannot express has to be pushed into a tool or into your own service, and at that point you are maintaining two systems instead of one.

Dify compared with LangChain and LlamaIndex

LangChain and LlamaIndex are libraries. You write Python or TypeScript, and the orchestration lives in your repository, versioned with your application code. Dify is the opposite arrangement: the orchestration lives in the platform's datastore, and you interact with it through a browser canvas or its HTTP API.

That difference decides most adoption questions. A library gives you reviewable diffs for every prompt change and no runtime to operate beyond your own process. Dify gives you a shared workspace where a non-author can edit a prompt or a retrieval setting without opening an editor, plus logs and annotations for production data, which the README lists under LLMOps. The cost is that prompt changes become data changes, so your review process has to move to the platform.

There is a middle path worth knowing about. Because Dify exposes APIs, a library-based service can call a Dify application as one step, keeping the code-heavy parts in your repository and the prompt-heavy parts on the canvas. The README's Backend-as-a-Service section is the basis for that pattern.

Observability, the plugin daemon, and what the README leaves out

The README names three observability integrations: Opik, Langfuse and Arize Phoenix. That is a useful signal, because it means traces and logs can leave Dify for a tool your team already runs instead of staying in the built-in log view. The README does not describe how to configure any of them, so treat the integration list as a starting point and check the documentation before you plan around it.

Related searches around this project include the plugin daemon. The repository has no top-level directory with that name, so plugin execution is not something the layout makes obvious; the plugin system appears to be documented rather than described in the README. If your plan depends on custom plugins, verify the plugin path in the documentation first.

Two other gaps are worth naming. The README does not document backup or restore, and it does not document rollback. Both matter more here than in a library, because application definitions, uploaded documents and run history all live in the platform's storage. Decide how you will back that up before you put anything real into it.

Editorial conclusion

Adopt Dify if you want a visual canvas, a document ingestion pipeline and agent tools behind one HTTP API without assembling those pieces yourself, and if you can operate a multi-container deployment. Do not adopt it if you need a single static binary, if your workflow logic is mostly custom code, or if you cannot accept the licence terms as they stand. Before committing, read LICENSE at the repository root, run the Compose stack in a staging host and check that the containers come up clean, and confirm from the documentation how you would upgrade and roll back across a version boundary.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes