IronFlow / Dify
RAG is not a checkbox. Decide who owns the pipeline.
Dify is an AI application platform with visual Studio, portable YAML DSL and CLI surfaces. IronFlow is a standalone workflow runtime. Both support code-managed definitions; the difference is whether execution belongs to a platform instance or directly to the workflow source and binary.
Code-managed does not always mean runtime-only.
- 01Studio + knowledge
- 02Portable YAML DSL
- 03Published app runtime
THE SHORT ANSWER
Choose by operating model, not logo.
Both products can be the right answer. The decisive question is how your team wants to author, own and evolve the workflow.
CHOOSE IRONFLOW
Choose IronFlow when the pipeline is bespoke.
- Ingestion logic must handle unusual formats and transformations.
- Every dependency, retry and cleanup step belongs in source control.
- The reviewed Lua file must run directly with one standalone Rust binary.
- The ingestion graph must also run from CI, batch jobs or an externally scheduled CLI.
CHOOSE DIFY
Choose Dify when the AI workspace is the product.
- Teams need a visual knowledge-base and AI application experience.
- Prompt orchestration, model configuration and app publishing should share one UI.
- YAML DSL and difyctl should manage workflows against the Dify platform.
- Cloud or a self-hosted Dify instance should own credentials, state and execution.
SIDE BY SIDE
IronFlow and Dify optimize for different work.
This is a product-model comparison—not an unbenchmarked claim about speed, scale or safety.
| Decision | IronFlow | Dify |
|---|---|---|
| Primary interface | Lua workflow definitions with CLI/API execution | Studio UI, portable YAML DSL and difyctl |
| Product center | General workflow and ETL execution | AI applications, agents and knowledge bases |
| Code authoring | Native Lua workflow; validate and run the source file directly | DSL YAML imported and exported through difyctl |
| Execution artifact | Lua file passed directly to the standalone runtime | Imported draft in a Dify instance; standard CLI runs the published app by ID |
| RAG approach | Composable primitives for processing, ingesting, querying and cleanup | Knowledge Pipeline and Knowledge Base workflows |
| Customization | Explicit graph steps, Lua and code nodes | Visual nodes, DSL, extensions and platform APIs |
| Deployment unit | Standalone Rust binary; no workflow import or control-plane service required; run history uses local JSON by default | Dify Cloud or a self-hosted multi-service platform instance |
| Execution placement | CI or batch CLI, self-hosted API and named webhooks; timed runs use an external scheduler | Dify Cloud or self-hosted platform execution for applications and APIs |
| Script boundary | Sandboxed flow Lua; filesystem, network and shell access require explicit nodes | Code and extension behavior follows Dify’s platform and deployment controls |
| Source license | MIT | Dify Open Source License based on Apache 2.0 with additional conditions |
RAG / CONTROL PLANE
IronFlow was built for the pipelines that did not fit.
Dify has a serious Knowledge Pipeline; the distinction is control. IronFlow offers document and media extraction, fixed and semantic chunking, embeddings, metadata transforms, vector operations and teardown as ordinary workflow steps.
TRUST BOUNDARY
Lua computes. Rust nodes perform effects.
Reviewed flows can run without an always-on editor service. The VM keeps direct system I/O out of Lua; named Rust nodes keep intended side effects visible in the graph.
01 / RESTRICTED VM
No ambient I/O APIs.
Flow and code Lua cannot directly open files, start processes, reach the network, load packages or load dynamic code.
- No os / io / debug
- No package / require
- No load / loadfile / dofile
- Instruction, time and memory budgets
02 / EXPLICIT CAPABILITIES
Effects stay visible in the graph.
Filesystem, network, shell, database, model and object-store access happen through named Rust nodes.
- Reviewable in source control
- Run beside the data
- No editor service required
- Process-level least privilege
THE BOUNDARY
Neither product wins “RAG” by default.
Dify supports code-managed DSL and headless CLI invocation, so a browser is not required on the CI runner. Its standard difyctl path still targets a Dify server: imports update the draft, while run app invokes the published version. That is portable workflow configuration plus platform execution, not direct execution of the YAML file by a standalone Dify runtime. IronFlow’s distinction is not code versus no code; direct source-file execution with a standalone production runtime is its primary path. Flow Lua is sandboxed, but explicit filesystem, network, model and storage nodes can still move or persist data; IronFlow does not automatically identify or redact arbitrary PII.
No visual workflow builder and no hosted knowledge-base UI. Its native vector lifecycle currently targets Amazon S3 Vectors. The proposition is a source-controlled graph and a self-hosted execution runtime.
VERIFY THE DECISION
Read the primary sources.
Competitor capabilities and license terms can change. Check Dify’s own current material before committing to an architecture.
TRY THE RUNTIME
Move from matrix to executable graph.
IronFlow v1.15.0 documents 101 built-in nodes. Start with the engine manual or run the RAG flow end to end.