Windmill vs n8n
Windmill and n8n are both open-source, self-hostable automation platforms that developers compare directly, and both have MCP servers — but the servers solve subtly different problems, which mirrors how the two products differ. Windmill is a code-first developer platform: you turn scripts (Python, TypeScript, Go, Bash, SQL) into internal tools, APIs, scheduled jobs, and multi-step flows backed by a fast job queue. Its official MCP server exposes the Windmill API over a remote Streamable HTTP endpoint so an agent can run scripts and flows, inspect job results, and manage workspace building blocks — resources, variables, schedules, and apps — and even expose your own scripts as agent tools. n8n is a node-based, fair-code workflow platform whose biggest friction for AI assistants is that they don't know its 800+ nodes; the popular community n8n-mcp server fixes exactly that by exposing a pre-indexed database of node types, properties, and docs, plus validation and workflow-management tools so an agent can design, validate, and deploy working n8n workflows. So one server is about operating a code platform, the other about authoring node-graph workflows correctly. Here is the comparison.
How they compare
| Dimension | Windmill | n8n |
|---|---|---|
| Platform style | Code-first: scripts in Python/TS/Go/Bash/SQL become tools, APIs, jobs, and flows on a fast job queue. | Node-based visual workflows built from 800+ pre-built nodes connected in a graph. |
| What the server is for | Operating Windmill — run scripts and flows, read job results, and manage resources, variables, schedules, and apps from an agent. | Helping an agent author correct n8n workflows — it exposes node knowledge plus validation, then creates/updates/tests workflows. |
| Authoring vs running | Run-and-manage oriented: runScriptByPath, runFlowByPath, and CRUD over scripts, flows, resources, and schedules. | Authoring oriented: search_nodes/get_node/validate_node/validate_workflow to build valid graphs, then n8n_create_workflow and n8n_test_workflow. |
| Official vs community | Official Windmill server over a remote Streamable HTTP endpoint; can also expose your own scripts as agent tools. | A widely used community server (n8n-mcp) whose value is its pre-indexed node database (~99% property coverage) and validation layer. |
| Best-fit task | Teams that write code and want an agent to execute and manage scripts, flows, and scheduled jobs on a developer platform. | Teams that build n8n workflows and want an agent to design, validate, and deploy node graphs it would otherwise get wrong. |
Verdict
Pick Windmill's server when your automation is code-first and you want an agent to run scripts and flows, read results, and manage resources, variables, and schedules on a platform built for developers — it operates Windmill and can even surface your scripts as tools. Pick the n8n server when you build node-based workflows and want an agent that actually understands n8n's 800+ nodes well enough to design, validate, and deploy working automations rather than guessing at node types and properties. Both are open source and both fit self-hosting; the real difference is operating a code platform (Windmill) versus correctly authoring visual workflows (n8n). Choose by how your team builds automations today.
FAQ
- Is n8n's server official?
- The widely used n8n-mcp server is a community project, not an official n8n release. Its strength is a pre-indexed database of n8n's nodes plus validation, which dramatically improves an agent's ability to produce valid workflows. Windmill's server is official.
- Can either run a workflow on demand?
- Yes. Windmill runs scripts and flows directly (runFlowByPath/runScriptByPath). The n8n server can create and test workflows and trigger executions, but its center of gravity is authoring correct workflows in the first place.