The Problem

Building production-grade agentic workflows requires orchestrating LLMs, retrieval, tool execution, and observability across a distributed system. Most teams hand-roll this glue code, which fragments into inconsistent patterns across frontend, backend, and evaluation layers.

What This Does

This is a fork of langgenius/dify (153k stars upstream), a full platform for agentic workflow development. It's not a single codebase but a collection of 9 self-contained projects. The two substantial ones are web/ (7,414 files, React/Next.js frontend) and api/ (3,001 files, Python backend). The api/ side handles workflow orchestration, dataset management, plugin systems, and tracing integrations (Langfuse, MLflow, Arize Phoenix). The web/ side is the console UI.

Supporting projects include packages/ (shared components), sdks/ (client libraries), e2e/ (Playwright/Cucumber tests), and .agents/ (31 files of agent skill definitions for code review and testing workflows).

How It Is Wired

Execution starts at api/app.py, which calls create_flask_app_with_configs and initialize_extensions. From there, requests route through Flask controllers under api/controllers/console/. The two highest-traffic files are workspace/tool_providers.py (50 functions, 64 classes) and core/app/entities/task_entities.py (65 classes defining task state). The app/workflow.py controller (33 functions, 43 classes) is the main workflow execution path — it validates UUIDs, parses uploaded files, and dispatches to the workflow engine.

The blast radius is concentrated in api/configs/feature/__init__.py (9 functions, 41 classes) — it defines global feature flags and CORS policies that every controller reads. Changing it affects all routes. The core/app/entities/queue_entities.py (39 classes) defines the queue event model that every async workflow run depends on.

A notable pattern: the repo ships .agents/skills/ with structured skill definitions (backend-code-review, frontend-testing, e2e-cucumber-playwright) — these are agent instructions, not runtime code, but they show the team's testing discipline.

How To Use It

# Clone and run with Docker Compose
git clone https://github.com/moses-y/dify
cd dify
cp .env.example .env
docker compose up -d

Configuration lives in api/.env.example — set SECRET_KEY, database credentials, and LLM provider keys there. The Makefile and .devcontainer/Dockerfile support local development. For production, the docker/ directory contains the compose orchestration. The API entry point is api/app.py; the web UI builds from web/.

Real-World Use

A team deploys this as their internal AI operations platform. They define agentic workflows in the console UI, which persists to PostgreSQL. The api/controllers/console/datasets/ endpoints handle document ingestion and RAG pipeline configuration. Trace data flows to Langfuse via api/providers/trace/trace-langfuse/pyproject.toml. The e2e/ suite (Playwright + Cucumber) validates the full workflow before each release.

Code Health & Issues

Static analysis found no structural red flags: 3,777 test files, GitHub Actions CI, Dockerfile, license, lockfile present, no committed secrets.

  • Low — Fork drift risk — This is a fork with 0 stars; upstream langgenius/dify moves fast. Merging upstream changes will be ongoing work, especially in api/controllers/ where upstream refactors frequently.
  • Low — Large surface area — 11,246 files across 9 projects means onboarding requires understanding which project owns what. The .agents/skills/ files partially mitigate this by codifying review rules.

The Bottom Line

This is a serious, production-grade platform with real engineering discipline — tests, CI, structured agent skills, and clean separation between web, API, and SDKs. The trade-off is operational complexity: 9 projects to maintain and a fork that must track upstream. Use it if you need a self-hosted agentic workflow platform and can commit to upstream merge maintenance.