n8n vs Windmill in 2026: Visual Open-Source vs Code-First Automation

n8n and Windmill both compete in the self-hostable workflow automation space, both run on a single Docker host, and both have free open-source editions. The marketing collateral makes them sound similar; in practice they pull in opposite directions. n8n is a visual workflow builder with a large connector library and a JavaScript code node. Windmill is a code-first runtime that treats TypeScript, Python, and Go scripts as the primary unit and generates UIs for them. The right pick for a given team usually drops out of one question: who writes the workflow definition?

This guide compares the two across pricing, architecture, language and DSL, integrations, observability, and team fit. Sources include the n8n pricing page, the Windmill pricing page, and the projects' GitHub repositories (n8n, Windmill).

At-a-glance comparison

Pricing

n8n self-hosted Community Edition is free with unlimited executions; the practical floor is the cost of a small VPS, around $3-7 per month. n8n Cloud Starter starts at $24 per month for 2,500 monthly executions; Pro at $60 per month covers 10,000; Business and Enterprise are custom-priced. The fair-code Sustainable Use License permits commercial internal use but restricts hosting n8n as a service to others.

Windmill self-hosted Community Edition is free under AGPLv3 with generous compute. Windmill Cloud Team starts at roughly $10 per user per month with included compute credits; Enterprise is per-worker. The AGPL license is stricter than n8n's fair-code: any modifications served over a network must be open-sourced.

For a 5-engineer team running internal automations on their own infrastructure, both products land at the cost of a small server. For a team picking a managed cloud, the per-execution model (n8n) and per-user model (Windmill) cross over at different volumes; the Pinggy comparison flags Windmill cloud as cheaper above ~10K executions per month if user count is small.

Architecture

n8n runs as a single Node.js process plus an optional queue mode (Redis + Bull for parallel execution). State lives in PostgreSQL, MySQL, or SQLite. Each workflow is a JSON document of connected nodes; execution walks the graph, evaluating each node and passing data forward.

Windmill runs as a Rust monolith plus a worker pool. State lives in PostgreSQL. Each script is a typed function (TypeScript, Python, Go, Bash, SQL, GraphQL); flows compose scripts into DAGs. Auto-generated UIs introspect the function signature and produce a form, which is the feature most teams cite as the differentiator.

The runtime difference matters at scale. Windmill's worker pool isolates each script execution and benchmarks the project publishes show sub-100ms cold-start overhead for hot workers. n8n's queue mode parallelises across workers but each node still runs in a Node.js context.

Editor's Note: Across 3 client deployments in 2025-26, we picked Windmill for a 14-engineer fintech ops team that wanted typed Python scripts under Git review, and n8n for a 5-person growth team at a B2B SaaS vendor who needed Slack -> HubSpot -> Notion glue without writing code. The Windmill rollout took 9 days end-to-end including SSO; the n8n rollout took 3 days because we copied 6 community templates and changed credentials. Caveat: small sample, both clients UK-based; Windmill's curve is steeper but the artifact is reusable in CI. — Rafal Fila, ShadowGen

Language and DSL

n8n's primary surface is its visual node graph. The Code node supports JavaScript or Python for cases where a built-in node doesn't cover the logic. Most workflows are configured rather than written.

Windmill's primary surface is the script. TypeScript, Python, Go, Bash, SQL, and GraphQL are first-class. Scripts have typed inputs and outputs; flows wire scripts into DAGs visually but the unit of work is code in a file. Git-based versioning is built in: the Windmill GitHub sync treats workspaces as repos.

The contrast: an n8n workflow is rarely reviewed in a pull request; a Windmill script almost always is.

Integrations

n8n ships 400+ pre-built integration nodes covering the SaaS catalogue most ops teams care about: Slack, Notion, HubSpot, Stripe, Shopify, Airtable, Google Workspace, Microsoft 365, the major databases, and a long tail of niche tools. The HTTP Request node covers anything not yet wrapped.

Windmill ships 100+ integrations and a Hub plus generic HTTP. The integration catalogue is smaller and closer to developer-leaning targets (Stripe, Slack, Linear, Postgres, Resend). For SaaS-heavy ops glue, n8n is the bigger library; for engineering-focused script work, Windmill is sufficient because raw HTTP plus typed scripts handle long-tail cases easily.

Observability

n8n ships per-execution logs, a workflow-history view, and basic error workflows that fire on failure. Self-hosted users typically wire n8n logs to their existing log stack (Loki, Datadog, ELK).

Windmill ships per-run logs, per-script metrics, and a built-in resource usage view. The platform exposes Prometheus metrics and OpenTelemetry traces directly. For an engineering team that already runs Grafana, the Windmill integration is closer to native.

Neither product replaces a serious APM; both expose enough surface to debug a single failed run.

Decision flow

flowchart TD
  A[New workflow platform] --> B{Workflow author<br/>writes code?}
  B -- No, click + configure --> C[n8n]
  B -- Yes, TS / Python / Go --> D{Need 100+<br/>SaaS connectors<br/>out of the box?}
  D -- Yes --> C
  D -- No, raw HTTP fine --> E[Windmill]
  C --> F{Self-host or<br/>managed cloud?}
  F -- Self-host --> G[n8n Community<br/>Docker]
  F -- Cloud --> H[n8n Starter $24/mo]
  E --> I{Strict OSS / AGPL<br/>requirement?}
  I -- Yes --> J[Windmill self-host]
  I -- No --> K[Windmill Cloud<br/>$10/user/mo]

When to choose n8n

Choose n8n when the workflow author is an ops, growth, or support operator rather than an engineer; when the integration catalogue (Slack, Notion, HubSpot, Stripe, etc.) covers most of the workload; when fast template reuse matters; and when the team values a visual canvas over Git-reviewable scripts. The 400+ pre-built nodes plus the Code node cover the long tail of SaaS glue work.

When to choose Windmill

Choose Windmill when the workflow author is an engineer who wants to commit typed TypeScript, Python, or Go to a Git-tracked workspace; when auto-generated UIs over scripts are a primary value (internal tools, on-call playbooks, ops dashboards); when AGPL is acceptable or preferred; and when the platform doubles as a script runner / cron / queue across the engineering team. Windmill behaves more like a backend platform than a workflow tool.

Self-hosting reality

Both projects publish a "single Docker command" install path; both need more than that for production. For n8n, the production checklist is: separate the Postgres instance from the n8n container, switch to queue mode with Redis once parallelism passes a few hundred concurrent executions, configure encrypted credentials with an external KMS, and put the editor behind SSO. The n8n self-hosting docs walk through each step, but small teams routinely skip the queue-mode and SSO pieces and run into them at 6-month mark.

Windmill's production checklist is similar: external Postgres, multiple worker pods, OAuth SSO (the Windmill OSS auth docs cover SAML on the Enterprise edition), and a backup strategy for workspace state. Worker resource sizing matters more on Windmill because each script runs in its own runtime; teams often end up with one worker pool per language to manage cold-start times.

For a 5-engineer self-hosted deployment, both products land at roughly half a day of platform-team setup and another half-day per quarter of maintenance. For 50+ users, the maintenance bill rises but stays well below a managed-cloud equivalent on either platform.

AI and LLM integrations

Both products added LLM nodes and credentials in 2024-25. n8n ships dedicated nodes for OpenAI, Anthropic, Cohere, Mistral, and a generic LangChain-compatible node, plus an AI Agents framework for tool-using agents. The visual canvas works well for chained prompt + retrieval steps where the operator wants to inspect each intermediate output.

Windmill's approach is to treat the LLM call as a script. The Windmill Hub ships starter scripts for the major providers, and engineers commit prompt templates and tool definitions as TypeScript or Python. Vector store integrations (pgvector, Pinecone, Qdrant) are handled the same way as any other integration.

For ops teams building "LLM glue" (Slack -> classify -> route -> notify), n8n is the lower-friction starting point. For engineering teams building agent backbones with structured outputs and pgvector retrieval, Windmill keeps the artifact in code where it belongs.

Bottom line

n8n and Windmill solve adjacent problems for different audiences. n8n optimises for the operator clicking nodes together; Windmill optimises for the engineer committing scripts. The fastest filter is to ask who in the team will own the workflow definition six months after launch; the answer almost always picks one of the two.