Dify puts workflows, retrieval, and model access in one product
A Dify application starts on a visual canvas. Teams can connect language-model calls, tools, branches, loops, human input, and retrieval steps, then publish the result behind an API or a user-facing app. Prompt editing, model selection, knowledge bases, logs, and annotations live in the same system. That shared surface is the reason to consider Dify instead of stitching together an orchestration library, admin console, and observability service.
The scope is wide enough to create its own gravity. The checkout at commit e18310e contained 13,460 files, about 2,126,431 lines of source, and 125.1 MB of code. A team adopting Dify is selecting an application platform, not adding a small SDK. That can reduce product work when most requirements match its model, while custom behavior has to fit workflow nodes, plugins, APIs, and the platform's release cycle.
The visual editor is useful only if the team accepts the platform boundary
Dify supports hosted and self-managed model endpoints, visual RAG pipelines, agent tools, app APIs, and production run inspection. Nondevelopers can read a graph and adjust prompts without editing the application repository. Engineers still control credentials, datasets, model settings, and deployment. This division works well when product specialists need daily access but infrastructure staff retain responsibility for data and execution.
Release 1.17.0 adds workspace-level skills with draft, publish, and version states, reusable LLM environment variables, and human input inside loops. It also adds a local or E2B agent runtime, home snapshots for published agents, and opt-in unified tracing. Those are substantive platform features, but each introduces state or configuration that must survive an upgrade. The release notes list new migrations and a renamed DEPLOYMENT_EDITION variable, plus changed Compose files.
What happened when we ran it
Our sandbox installed the pnpm workspace in 61 seconds. It pulled 1,342 packages and occupied 1,408 MB on disk, which is already a large developer footprint before containers, databases, model weights, or indexed documents. The install succeeded at commit e18310e in an unprivileged Debian container with 3 CPUs and 8 GB of RAM.
The root workspace exposed no build script or target, so the build step was skipped. It also exposed no test script or target, so tests were skipped. That is not a failed build or a passing suite. It means the generic root commands used by our lab could verify dependency resolution but could not produce evidence about compiled output or application tests. Dify's 35 CI workflow files suggest more specific checks exist across the monorepo.
Our scan found no Dockerfile and no tests directory at the measured root, while the README directs users to docker/docker-compose.yaml. That distinction matters: the published product is assembled from multiple service definitions rather than proved by one root package command. The 61-second install says the JavaScript workspace resolves on our box. It says nothing about Python services, a database migration, vector retrieval, model calls, or sandbox isolation.
The 4 GiB quick start is a floor, not a production design
The README requires at least 2 CPU cores, 4 GiB of RAM, Docker, and Docker Compose 2.24.0 or later. After copying the example environment file, docker compose up -d brings up the stack and the browser completes initialization. This is a reasonable evaluation route because it avoids manual source setup across the web and API layers. It also hides the number of services until an operator reads the Compose file.
A useful installation needs model credentials or reachable self-hosted inference. Knowledge bases need an embedding model, document storage, and a vector-store decision. Production also has application secrets, user authentication, worker queues, outbound network rules, backups, and observability. Agent shell execution raises the stakes: version 1.17.0 can use a local sandbox or E2B, with backend selection, authentication tokens, file download limits, and several timeout controls.
Version 1.17.0 makes upgrades a planned operation
The August 25, 2026 release explicitly instructs operators to run database migrations. It renames EDITION to DEPLOYMENT_EDITION, adds several environment variables, changes defaults, and modifies Docker Compose. The notes warn that an index on an existing conversations table may take longer when that table is large. Customized Compose users must back up their files and reapply local edits rather than replacing the stack blindly.
That release discipline is reassuring, but the amount of change argues for a staging environment and tested rollback. Dify has 153,602 stars, 958 combined issues and pull requests, and a last push on August 27, 2026. Activity is plainly current. The queue is not a defect count, and fast movement still means operators must read release notes instead of treating a minor version as routine package maintenance.
The license needs review before platform commitment
GitHub reports no standard SPDX identifier because Dify uses its own Open Source License, based on Apache 2.0 with additional conditions. The README also separates Community Edition, cloud service, and enterprise offerings. Teams with rules that require an OSI-approved license or unmodified Apache-2.0 terms should have counsel read the repository license before building internal dependencies around Dify.
For teams that clear the license and need its whole product layer, Dify can replace months of internal interface work. The price is operational: 1,342 installed packages in our limited run, multiple persistent services, model and storage credentials, migrations, and a release stream that changes configuration. Langflow or Flowise is easier to justify for a narrower visual builder. A direct SDK is cheaper when the application needs one model call and ordinary product code can own the rest.