Windmill: script-first workflows with TypeScript, Python, Go, and Bash under AGPLv3

What is Windmill?

Windmill is an open-source platform for script-first workflow automation, founded 2022 in Paris by Ruben Fiszel. Its market position is clear: Windmill treats code (TypeScript, Python, Go, Bash) as first-class and wraps that code core with typical workflow-platform features – scheduling, UI generation, secrets management, version control, approval flows. The comparison with Zapier or n8n is misleading; Windmill is closer to a "self-hosted Vercel for backend scripts" than to a visual workflow tool.

As of May 2026 Windmill supports four languages first-class: TypeScript (Deno and Bun runtime), Python 3.11+, Go 1.21+, and Bash. Additionally a built-in SQL editor (Postgres, MySQL, MS SQL, BigQuery, Snowflake) and PowerShell support. Every script is a function with typed parameters; from these parameters Windmill automatically generates a web UI for manual triggers.

Flows combine several scripts in a directed graph. Branching, iteration, suspends (wait-for-event), approval steps, and sub-flows are all native. Trigger sources: cron, webhook, manual execution, external events via polling.

Commercially Windmill is dual-licensed: AGPLv3 for the core (self-hosting with AGPL compliance obligations) and a commercial license for enterprise features (SSO, audit log, advanced RBAC). Cloud tier starts at USD 0/month (Free, 1,000 executions, 5 members), Team from USD 30/month for 50,000 executions, Enterprise on request. Self-host is the more usual choice – AGPL compliance is no problem for internal use, only resale in own products needs to account for the copyleft duty.

The self-host architecture is its own: Docker-Compose with Postgres as DB, Windmill server, Windmill worker (scalable), and optionally a Caddy container as reverse proxy. Resource consumption is higher than Activepieces because every script run spawns a container – a 4-vCPU machine typically covers 50-100k executions/month.

Why it matters

Windmill solves a concrete problem for engineering teams: combining the discipline of Git-versioned code with the convenience of a workflow platform. Anyone in an SME or fiduciary setup with engineering capacity (internal developer, external contractor) can hold workflows as TypeScript or Python code in the Git repo – code review, tests, CI/CD like normal software.

For a Swiss fiduciary with engineering capacity three concrete levers. First: ELT pipelines for bookkeeping. Pull data from Bexio, Abacus, or Lexoffice, transform, load into a data warehouse (Postgres or Snowflake) – such pipelines can be written as Python scripts in Windmill, scheduled by cron, with Slack alert on failure. Functionally similar to Airflow but with better UI and easier onboarding.

Second: approval flows with human-in-the-loop. Windmill has a native "approval step": a flow pauses, sends a message to a user, waits for confirmation (via email link or UI click), and continues. For client onboarding with AML check or for invoice approvals above a threshold, that is the right architecture – AI proposes, human decides, then the operation flows to the ERP.

Third: custom logic with full language freedom. Anyone needing to implement a specific algorithm (e.g. VAT plausibility check with pandas DataFrames, lead-scoring logic with scikit-learn, billing logic with numpy) can do it directly in Windmill Python scripts. No Code-Action limits like Zapier, no whitelist like Activepieces.

The AGPL license is no obstacle for internal use. Anyone wanting to embed Windmill in a SaaS product must either honour the copyleft duty (own code under AGPL) or buy the commercial license. For fiduciary-internal use that does not apply.

How it works

A Windmill workspace organises content into four categories: scripts (individual functions in a language), flows (graphs of scripts), apps (custom UIs from script outputs), and resources (typed secrets for DB connections, API keys, cloud credentials). Every resource has a schema against which inputs are validated.

A script is edited via a web IDE – Monaco editor with auto-completion, integrated test execution, version history. The function accepts typed parameters; Windmill auto-generates a UI form for manual triggers. Saving creates a new version, every version is diffable against the previous. Optionally a workspace can sync with Git – pull/push against an own repo, so code review and CI integrate.

A Flow is a graph of steps. Each step is either a script call, a branch (if-then), a for-loop, a while-loop, an approval step (waits for confirmation), a suspend step (waits for external event), or a subflow (call to another flow). Data between steps flows via explicit variable bindings – Windmill is strictly typed, in contrast to the loose connection in n8n.

A typical ELT flow for bookkeeping: cron trigger (daily 02:00) -> Python script "bexio_export" (pull Bexio API into DataFrame) -> Python script "transform" (clean, aggregate) -> SQL step "load_warehouse" (INSERT into Postgres data warehouse) -> Slack step (success/failure notification). On failure in step 2 or 3, step 4 is not executed, an error-handler flow is triggered instead.

The Apps functionality is a particular strength: from a script's outputs a custom UI can be built (forms, tables, charts, buttons). That lets internal tools be created very quickly – e.g. a "client lookup tool" as an app calling a Python script and displaying the result as a table. This app can be permission-controlled and granted to individual staff.

The worker architecture scales horizontally: every worker pulls jobs from the queue, runs the script in an isolated container, writes the result back. With 4 workers parallel on an 8-vCPU machine, Windmill runs stably at several hundred executions per minute.

Windmill self-hosted in 5 steps

1. 01Prepare the Docker-Compose stack: Windmill server, Windmill workers (2-4 containers), Postgres as DB, Caddy as reverse proxy with TLS.
2. 02Create the workspace: create the admin user, define first resources (Postgres connection, OpenAI API key, SMTP credentials).
3. 03Write the first scripts: hello-world function in TypeScript or Python, test the auto UI, set permissions.
4. 04Assemble a flow: connect 3-4 scripts in a graph, error-handler branch for the failure case, approval step for critical operations.
5. 05Activate Git sync: connect the workspace to an own Git repo, pull/push for code-review workflow, CI integration optional.

When to use Windmill

Windmill is the right pick when (a) the team has code skills (at least one person with TypeScript or Python experience), (b) workflows should be kept as code in the Git repo, (c) approval flows or human-in-the-loop logic are required, and (d) self-hosting under EU law matters.

Concrete cases: ELT pipelines for bookkeeping data (Bexio/Abacus/Lexoffice -> data warehouse), custom back-office tools (internal apps for staff), approval workflows (invoice approvals, client onboarding with AML check), data processing with pandas/Pydantic/Pillow, AI pipelines with full SDK freedom (own LangChain logic, custom embedding strategies), internal reporting generators (PDF reports from Python with ReportLab).

For engineering teams in mid-sized SMEs or fiduciary offices from 20 staff up, Windmill is often the more productive choice than n8n: less UI overhead, more code discipline, better integration with existing software development. Anyone already using Git, CI/CD, and code review fits Windmill in more easily than a visual tool.

For standard RAG and agent workflows, Windmill is at least as good as n8n – full Python freedom allows complex LangChain setups, custom retrievers, hybrid embedding strategies. Vector-store wiring (Qdrant, Pinecone, pgvector) as regular Python imports.

For self-hosting in EU/CH, Windmill is a technically clean choice: Docker-Compose stack, Postgres as DB, clear reverse-proxy wiring. AGPL compliance for internal use is not an issue.

When not to use

Windmill is the wrong choice when the team has no code skills. Unlike n8n or Activepieces, there is no productive path for no-code users – the UI helps with editing, but every step requires at least basic programming concepts. For marketing or sales teams without engineering support, Make or Zapier is the right choice.

Unsuited for pure no-code SaaS integrations. Anyone building "Slack message on new HubSpot deal" has 90% of the setup in Zapier or Make in 5 minutes – in Windmill you call the HubSpot and Slack API yourself against an HTTP module or write a small script. For simple 1-to-1 wirings that is overcomplicated.

Does not fit very high event volume with real-time constraints (millions of events/hour). The worker architecture scales into thousands of executions/minute, but for real streaming, Kafka, Apache Flink, or dedicated streaming platforms are the right choice.

For embedded use cases inside own SaaS products, AGPL is a hurdle: either own code is placed under AGPL (rarely wanted) or the commercial license is bought. Anyone wanting to embed workflow automation in an own product should deliberately compare Activepieces (MIT) or n8n Embedded (commercial license).

For mission-critical workflows with hours or days of runtime, complex state, and guaranteed exactly-once semantics, Temporal is the more robust choice. Windmill can model durable execution via suspends, but state management is not as well thought-out as Temporal.

Trade-offs

FAQ

Related topics

Sources

1. Windmill documentation – scripts, flows, apps, resources · 2026-05
2. Windmill pricing page (cloud and enterprise) · 2026-05
3. Windmill on GitHub – AGPLv3 core · 2026-05
4. Windmill flows, approval steps, and durable execution · 2026-04