IronFlow / n8n
Choose the workflow surface you actually need.
n8n is a visual automation platform with code-authoring surfaces, including a TypeScript Workflow SDK. IronFlow is a code-defined standalone execution runtime. The decisive difference is how workflow source becomes a running deployment.
Same category. Different center of gravity.
- 01Visual canvas
- 02TypeScript → JSON
- 03Platform execution
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 graph is software.
- The Lua file itself belongs in source control, code review and the deployment.
- RAG and ETL need explicit extraction, transformation and lifecycle steps.
- You want to validate and run that file directly with a standalone Rust binary.
- The graph must fit CI, batch jobs and externally scheduled CLI runs.
CHOOSE N8N
Choose n8n when the canvas is the product.
- Operators need to compose and inspect automations visually.
- Engineers want to generate validated workflow JSON with n8n’s TypeScript SDK.
- A broad catalogue of ready-made app integrations is the main requirement.
- Managed cloud, platform triggers and visual credential setup are useful parts of the product.
SIDE BY SIDE
IronFlow and n8n optimize for different work.
This is a product-model comparison—not an unbenchmarked claim about speed, scale or safety.
| Decision | IronFlow | n8n |
|---|---|---|
| Primary interface | Lua files with CLI/API execution | Visual canvas, plus a TypeScript Workflow SDK |
| Code authoring | Native Lua workflow; validate and run the source file directly | TypeScript SDK generates validated workflow JSON |
| Execution artifact | Lua file passed directly to the standalone runtime | JSON imported into an n8n instance; server CLI executes a stored workflow by ID |
| Best authoring fit | Engineering teams treating the deployed workflow as source code | Visual automation teams, with SDK support for code-generated definitions |
| RAG approach | Explicit extraction, chunking, embedding and vector lifecycle nodes | AI workflow nodes, templates and integrations inside the visual editor |
| Integration strategy | Focused built-ins plus Lua/code composition | Large catalogue of application connectors |
| Deployment unit | Standalone Rust binary; no workflow import or control-plane service required; run history uses local JSON by default | n8n Cloud or self-hosted application; the standard server package includes the editor UI |
| Execution placement | CI or batch CLI, self-hosted API and named webhooks; timed runs use an external scheduler | n8n Cloud or self-hosted platform execution with configured triggers |
| Script boundary | Sandboxed flow Lua; filesystem, network and shell access require explicit nodes | Code and connector behavior follows n8n’s node and deployment controls |
| Source license | MIT | Sustainable Use License / Enterprise License |
RAG / CONTROL PLANE
For RAG, inspect the whole ingestion path.
n8n can build complete RAG systems, including ingestion, chunking, embeddings, vector stores, retrieval and evaluation. The distinction is the control surface: IronFlow expresses the lifecycle as a code-defined, reviewable graph.
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
This is not a drop-in migration pitch.
If your team succeeds with n8n’s visual model, Workflow SDK and connector ecosystem, keep it. n8n supports TypeScript-authored JSON and headless execution, but its standard deployment is not a runtime-only package: generated JSON is imported into an n8n instance, the current server CLI runs a stored workflow by ID, and the standard server package includes the editor UI. IronFlow runs the Lua file directly with the standalone Rust binary; CLI execution needs neither workflow import nor an editor control-plane service, while run history uses local JSON by default. Flow Lua is sandboxed, but explicit filesystem, network and shell nodes still have real side effects; arbitrary workflow data is not automatically redacted.
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 n8n’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.