Windmill vs n8n

Two credible self-hosted engines

Windmill and n8n are the two most credible self-hosted workflow tools for engineers, and the choice between them is really a choice about primary surface. Windmill is code-first: you write TypeScript, Python, Go, or Bash, and the platform turns each script into a runnable, schedulable, observable artifact. n8n is visual-first: you build on a canvas of nodes and drop into code only when a step needs it.

If n8n is the developer-friendly Zapier, Windmill is the workflow tool for engineers who think n8n still has too much GUI. Both self-host cleanly, both are actively maintained, and neither is a toy. The decision comes down to who maintains the workflows and whether the team thinks in scripts or in nodes.

Code-first vs visual-first

Windmill has no drop-into-code mode because code is the mode. Its three primitives are scripts (any Python, TypeScript, Go, or Bash), flows (DAGs of scripts), and apps (auto-generated UIs that call scripts). Every script becomes a webhook, a scheduled job, a CLI command, and a UI form input by default. For a backend team that already thinks in code, this removes the friction of translating logic into a visual builder.

n8n puts the visual canvas first and offers a Code node (JavaScript or Python) as an escape hatch. Branching, merging, looping over arrays, and sub-workflows are canvas primitives, and the editor is approachable enough that a non-developer can build a working flow. The trade is that expressing genuinely code-heavy logic on a canvas is more awkward than writing it as a script.

The practical filter: Windmill rewards teams whose instinct is to write a function; n8n rewards teams that want to wire boxes together and only occasionally write code. Neither is wrong, but they optimize for different hands on the keyboard.

Licensing

This is a real structural difference, not a footnote. Windmill is AGPLv3 - OSI-approved open source with copyleft obligations. Internal use, modification, distribution, and network service scenarios can carry different obligations. If you are an ISV or plan to embed, modify, or redistribute it, read the license and take legal advice before building on it.

n8n ships under the Sustainable Use License, which is fair-code rather than OSI open source. It is free to self-host and modify for internal use, with restrictions on running a competing hosted n8n service. For internal automation this license is invisible in practice. The two licenses point in opposite directions: AGPLv3 is more permissive for forking and modifying but stricter about redistribution, while the Sustainable Use License is looser on redistribution of your own workflows but not classic OSS.

Performance and integrations

Windmill uses a Rust backend and worker-based execution; n8n uses a node-graph runtime and can distribute executions across queue workers. Vendor-authored benchmarks do not establish a general winner. Throughput and latency depend on job shape, worker resources, database, queue, and external services, so benchmark the intended workload.

On integrations, n8n emphasizes packaged native and community nodes plus HTTP and code escape hatches. Windmill offers a hub and expects teams to write scripts or API calls when a packaged integration is unavailable. Verify the exact triggers and actions rather than relying on time-sensitive catalog counts.

Git workflow and AI

Windmill treats git as a first-class source of truth: workflows and scripts sync to a repository, so version control, review, and CI are native rather than bolted on. n8n exports workflows as JSON, which is version-controllable but less seamless - the round-trip is workable rather than designed-in. For teams that want their automation to live in the same repo and review process as the rest of their code, Windmill is the cleaner fit.

On AI, n8n has the deeper story. It ships native LangChain nodes, an AI Agent node, chat memory, and direct integrations with the major vector stores, so building a retrieval flow or a tool-using agent happens inside the same canvas as everything else. Windmill has no dedicated AI node layer - scripts call any model API directly, which is maximally flexible but more do-it-yourself. If the AI logic is the workflow and you want building blocks, n8n; if you would rather write the model calls as code, Windmill does not get in the way.

Who should choose Windmill

Windmill is the right choice for engineering teams who think in scripts and want git as the source of truth. Teams whose alternative was Airflow, Prefect, or a sprawl of cron and Bash get an observable engine that turns scripts into webhooks, schedules, and UIs. It fits backend and data teams orchestrating pipelines, and self-hosted shops that will not deploy a cloud SaaS. The things to evaluate are AGPLv3 obligations, packaged integration coverage, and a learning curve that assumes engineers.

Who should choose n8n

n8n is the right choice for mixed teams where non-developers also build flows. The visual canvas is friendlier, the catalog is far bigger with 400+ native nodes plus community contributions, and the AI node story is deeper for retrieval and agent workflows. It self-hosts as cleanly as Windmill on Docker or Helm, and the execution-priced cloud is available for teams that do not want to run infrastructure at all. Choose n8n when the people building workflows are not all engineers, when you want ready-made connectors over writing your own, or when native AI building blocks matter more than raw throughput and git-native scripts.