Skip to content
STACK IT FAST
Share

Dify vs Flowise

Architecture comparison 2 projects Built from source-audited deep dives

Dify is a multi-service LLM application platform (Flask API, Celery workers, separate agent services, pluggable vector stores) run with Docker Compose. Flowise is a lighter Express + React Flow builder over LangChain.js nodes that can run as one process, but its repository is archived.

Dify.ai Flowise
Dify.ai
TypeScript · NOASSERTION
Flowise
TypeScript · NOASSERTION
Updated
2026-09-25

Which one should you pick?

Pick Dify.ai if…
  • You need RAG pipelines, workflows and agents in one self-hosted platform
  • You want agent tool execution isolated in a sandbox and outbound calls behind an SSRF proxy
  • You are comfortable operating several containers (web, api, worker, Postgres, Redis, vector store)
Pick Flowise if…
  • You want a single Node.js process you can start with npx and SQLite
  • Your flows map well onto LangChain.js building blocks
  • You can accept an archived upstream or plan to follow a community fork

Side by side

Attribute Dify.ai Flowise
Written in TypeScriptPythonJavaScript TypeScriptJavaScriptHTML
License NOASSERTION NOASSERTION
Frontend Next.jsViteJotai + TanStack Formdify-ui (@base-ui/react + Tailwind) ReactReactFlow
Backend & APIs FlaskCeleryGunicorn + geventdify-agent (FastAPI + pydantic-ai)dify-agent-runtime (Go) ExpressTypeORM
Data & persistence PostgreSQLRedisPluggable vector stores SQLiteRedis
Infrastructure & deploy Docker ComposeNginxSSRF proxy DockerGitHub Actions
Key decisions
  • Agent execution is split into two services outside the main API
  • The web console can build with Next.js or an experimental Vite path
  • Vector store backends are pluggable provider packages, not a hard dependency
  • Turborepo splits the monorepo into six independently built packages
  • TypeORM abstracts SQLite, PostgreSQL, and MySQL behind one data layer
  • Optional queue mode offloads execution to a separate BullMQ worker image
Audited ad9a5be · 2026-09-17 9291856 · 2026-09-17

How they differ

Service layout

Dify splits into a Next.js console, a Flask REST API under Gunicorn, Celery workers for workflows and document indexing, and two agent services outside the main API: dify-agent (FastAPI + pydantic-ai) and dify-agent-runtime (Go, sandboxed with landlock). Flowise is an Express server distributed as a CLI (npx flowise start) with a React Flow canvas; an optional queue mode moves execution into a separate BullMQ worker image.

Data

Dify needs PostgreSQL and Redis, plus a vector store chosen from provider packages such as pgvector, Elasticsearch or TiDB. Flowise uses TypeORM over SQLite by default, with PostgreSQL or MySQL as alternatives, and Redis only in queue mode.

Safety and integrations

Dify routes outbound tool and plugin HTTP calls through a dedicated SSRF proxy container and can hand agent execution to e2b sandboxes. Flowise’s 100+ integration nodes are built on LangChain.js primitives and it supports MCP tools.

Architecture diagrams

Dify.ai Open SVG
Dify.ai architecture diagramStudio console → Reverse proxy (HTTPS); Apps & SDKs → Reverse proxy (API); Reverse proxy → API (/api); API → PostgreSQL (psycopg2); API → Redis (enqueue); Redis → Celery workers (tasks); Celery workers → Vector store (index docs); API → dify-agent (run agent); dify-agent → Agent runtime (sandbox exec); API → SSRF proxy (tool HTTP)CLIENTSSERVICESWORKERS & JOBSDATA & STORAGEEXTERNALStudio consoleNext.js · dify-uiApps & SDKsREST · Node/PHP SDKsReverse proxyNginxAPIFlask · Gunicorndify-agentFastAPI · pydantic-aiCelery workersworkflows · indexingAgent runtimeGo · landlockPostgreSQLRedisbroker · cacheVector storepgvector / ES / TiDBSSRF proxyoutbound HTTP/apirun agentHTTPSAPItasksindex docssandbox execpsycopg2enqueuetool HTTP
Flowise Open SVG
Flowise architecture diagramFlow builder → Server (REST); Embeds & API → Server (predictions); Server → Integration nodes (run flow); Server → Database (TypeORM); Server → Redis (enqueue); Redis → Queue worker (jobs); Queue worker → Integration nodes (run flow); Integration nodes → LLMs & tools (calls)CLIENTSSERVICESWORKERS & JOBSDATA & STORAGEEXTERNALFlow builderReact · ReactFlowEmbeds & APIflowise-embed · RESTServerExpress · oclif CLIIntegration nodesflowise-componentsQueue workerBullMQ (queue mode)DatabaseTypeORM · SQLite/PostgresRedisBullMQ queueLLMs & toolsLangChain · MCPrun flowRESTpredictionsjobsrun flowTypeORMenqueuecalls

Frequently asked questions

Is Flowise still maintained?

The audited Flowise repository has been archived on GitHub, with a community fork discussion linked. Dify is actively developed.

What language is Dify written in compared to Flowise?

Dify's API and workers are Python (Flask and Celery), its console is Next.js, and its agent runtime is Go. Flowise is TypeScript end to end: an Express server and a React/ReactFlow UI.

More architecture comparisons

View all

AFFiNE vs AppFlowy

AFFiNE vs AppFlowy compared on architecture: React + Yjs vs Flutter + Rust, local-first storage, sync servers, native code and local AI.

Appsmith vs ToolJet vs Budibase

Appsmith, ToolJet and Budibase compared on architecture: Java vs NestJS vs Koa, MongoDB vs PostgreSQL vs CouchDB, sandboxing, plugins and deployment.

Authelia vs authentik vs Logto

Authelia, authentik and Logto compared on architecture: Go vs Django vs Koa, storage, OIDC providers, protocol support and how each fits a self-hosted stack.

Axum vs Actix Web

Axum vs Actix Web compared on architecture: Hyper and Tower vs an own HTTP stack, routing, middleware, crates in the workspace and who uses each.