Dify vs Langflow

Dify and Langflow both let you build LLM applications by wiring blocks together in a browser instead of writing the glue code yourself: a model, a prompt, a retrieval step over your documents, a tool call, an output. Both run in Docker, both connect to hosted and self-hosted models, and both can publish what you build as an API or an MCP server. They come at it from different ends. Dify is a platform with built-in building blocks extended through plugins, a team workspace and a document pipeline built in. Langflow is a canvas of Python components that you can open and edit, served from one container.

Two ideas of a visual builder

Dify describes itself as an "LLM app development platform" that combines "AI workflow, RAG pipeline, agent capabilities, model management, observability features" in one interface. You build a chatbot, an agent or a multi-step workflow on a visual canvas, tune prompts in its Prompt IDE, and watch logs and annotations from production traffic in the same UI. Agents can use function calling or ReAct, and the README lists "50+ built-in tools". Every app gets an API, so Dify can sit behind your own product as a backend.

Langflow calls itself a platform for "building and deploying AI-powered agents and workflows". Each block on the canvas is a component, and "source code access lets you customize any component using Python". You test a flow in the interactive playground, then deploy it as an API or export it as JSON. For tracing, the README lists LangSmith, LangFuse "and other integrations"; Dify lists Opik, Langfuse and Arize Phoenix.

Both can expose your work to MCP clients such as Cursor. Langflow serves each project's flows as MCP tools over streamable HTTP. Dify has an MCP Server option on each app's Access Point tab, off by default, and warns that the generated URL contains credentials and should be treated "like an API key".

The practical split: Dify gives a product team a place to build, publish and monitor LLM apps without touching code. Langflow gives a developer a visual editor over Python, where any block can be rewritten when the built-in one is not quite right.

Documents and retrieval

Dify's RAG pipeline covers "everything from document ingestion to retrieval", with text extraction from PDFs, PPTs and other formats out of the box. The default Compose stack starts a Weaviate vector database for it (VECTOR_STORE=weaviate in .env.example), and the same Compose file carries profiles for Qdrant, pgvector, Chroma, OceanBase and others if you would rather use one of those.

Langflow does retrieval with components. Its built-in knowledge bases store embeddings in local Chroma by default, but its docs say they support only structured data, standard similarity search and a set of built-in embedding models. For anything else you place an embedding model and a vector store component on the canvas yourself, and as of 1.12 most vector store bundles are not in the default install. That is more wiring, but each step is visible and replaceable.

Running other people's code

This is the difference to settle before you give anyone else an account.

Langflow is, in its own docs' words, "an IDE and code execution platform". The code editor lets users "author and execute arbitrary Python with full access to the host Langflow backend process, filesystem, and network", and "Langflow neither enforces isolation between users within a single Langflow process, nor restricts access to the local disk or network resources". In multi-user mode, the docs say, "every regular user effectively has code execution on the host" unless you restrict it. The fixes are two environment variables: LANGFLOW_CUSTOM_COMPONENT_ADMIN_ONLY=true limits component code to superusers, and LANGFLOW_ALLOW_CUSTOM_COMPONENTS=false runs only the server's built-in code. Langflow also ships role tables, but the open-source build "registers a pass-through service that always allows every action for every authenticated user". Enforcing roles needs an authorization plugin that Langflow OSS does not include.

Dify sends code execution to a separate sandbox container (CODE_EXECUTION_ENDPOINT=http://sandbox:8194), and that sandbox's outbound HTTP goes through a Squid SSRF proxy. Workspace members get one of four roles: Owner, Admin, Editor, or Normal, which can "use published apps only". That makes Dify the easier one to hand to a team where not everyone should be able to change the apps.

Licences

Langflow is MIT.

Dify uses the Dify Open Source License, a modified Apache 2.0. It is source-available, not an OSI-approved licence. Commercial use is allowed, including "as a backend service for other applications", but two cases need a commercial licence: operating "a multi-tenant environment", where one tenant is one workspace, and removing or changing "the LOGO or copyright information in the Dify console or applications". The logo rule applies only when you use Dify's frontend. A single workspace for your own company is covered; selling workspaces to customers needs written authorisation from Dify.

Footprint and setup

Dify is a Compose stack. With the default profiles, the pinned 1.17.1 file runs the API and a WebSocket API, a worker, a beat scheduler, the web frontend, PostgreSQL 15, Redis, the code sandbox, a plugin daemon, an agent backend with its own sandbox, two SSRF proxies, nginx and Weaviate. The README asks for at least 2 CPU cores and 4 GiB of RAM, plus Docker Compose v2.24.0 or later. You create the admin account at /install. .env.example ships fixed values for the sandbox API key (dify-sandbox) and the Weaviate API key, and the Compose file says to change the sandbox key "with a strong key" for a real deployment.

Langflow is one container. It keeps its data in SQLite by default. Its production guide recommends an external PostgreSQL database, and the repo ships docker_example/docker-compose.yml for that. Since 1.11.x the official images set LANGFLOW_AUTO_LOGIN=false, so you must set a superuser password before the first start. The installation docs list a minimum of 2 GB of RAM for the Python package and recommend at least 4 GB.

Both installs have been tested on this site (Ubuntu 26.04, 2026-09-29). Idle after first start on our GCP e2-standard-2 test box, Dify used ~1.8 GB of RAM and ~11.2 GB of disk; Langflow used ~1.2 GB of RAM and ~3.5 GB of disk. We rate both 2 out of 5 to deploy. Dify's stack is larger, but it comes as one Compose file. Langflow is one container, but multi-user use needs the lockdown settings above.

Which to choose

Choose Dify if a team will build and run LLM apps together: a document pipeline and vector database that work on day one, workspace roles, logs and annotations in the UI, and code execution kept in a sandbox container. Budget 4 GB of RAM or more, and read the licence if you plan to offer it to customers.

Choose Langflow if you are a developer who wants to see and change the code behind every block, serve flows as an API or an MCP server, and keep the footprint to one container under an MIT licence. Keep it single-user, or turn on LANGFLOW_CUSTOM_COMPONENT_ADMIN_ONLY before adding users.

Choosing between Langflow and Dify

Starting from Langflow, the usual reason to move is people. Once colleagues who should not run code on the server need to build or use apps, Dify's roles and sandbox fit better. Starting from Dify, the usual reason to move is a block that does not do what you need. In Langflow you edit that block's Python directly.

Related

Install snippets and specs are on the Dify and Langflow pages. To run models on the same server instead of calling a hosted API, start with the Ollama deploy guide. If you need general automation with an LLM step rather than an LLM app builder, n8n is the closer fit.