Windmill Review (2026): Open-Source Platform for Scripts, Flows, and Apps
Best for: Developers and infrastructure teams who need a self-hostable Retool alternative that orchestrates Python, TypeScript, and Go scripts with Temporal-like reliability.
* Affiliate disclosure: we may earn a commission at no cost to you.
Decision summary
Who it’s for, what it costs, and the catch — answered up top.
Bottom line
Windmill is a developer platform that lets teams turn scripts into internal tools, workflows, and dashboards. High performance self-hosted option, open-source under AGPL v3, with a Temporal-style execution engine and built-in UI builder.
Windmill (windmill.dev) is an open-source developer platform for running scripts, building workflows (flows), and creating internal apps — all in one cohesive system. Founded in 2022 by Ruben Fiszel, it has become one of the most compelling alternatives to Retool, Airplane, n8n, and Temporal for teams that need to build internal tools, automate workflows, and run scheduled scripts without commissioning a full custom application. The platform is released under the AGPLv3 license, runs on the cloud at windmill.dev, and can be fully self-hosted on your own infrastructure.
The pitch is straightforward: write a Python, TypeScript, Go, Rust, or Bash script, push it to Windmill, and the platform wraps it in a generated web UI, a scheduling engine, a secret store, and an audit trail — all without writing additional glue code. For developer teams who have accumulated a sprawling collection of “just SSH in and run it” scripts, Windmill turns that mess into a governed, reproducible, shareable workspace.
What Is Windmill?
Windmill is best understood as three products in one: a script runner, a workflow orchestrator, and an internal app builder. Each layer builds on the one below it, and you can adopt them incrementally.
Scripts
The atomic unit in Windmill is the script. You write a function in Python, TypeScript, Go, Bash, PHP, or SQL — Windmill inspects the function signature and automatically generates a web form for the inputs. Team members can run the script through the browser without touching the terminal, credentials stay locked in the platform’s resource store, and every execution is logged with its inputs, outputs, duration, and exit status. Add a cron expression and the script becomes a scheduled job. Expose it via webhook and external systems can trigger it over HTTP. Version the script in git and your CI/CD pipeline can deploy updates without touching the Windmill UI.
Flows
Flows are visual workflows that chain multiple scripts together. The flow editor gives you a canvas with nodes — each node is a script step, a loop, a branch, an approval gate, or an error handler. Branching is real code logic (if/else on step outputs), loops iterate over arrays with automatic parallelism controls, and approval steps pause execution and send an email or Slack message asking a human to approve before the flow continues. Unlike low-code automation tools where “flow logic” means picking from a dropdown of pre-built conditions, Windmill’s branching is just code — you write a TypeScript or Python expression and the result routes the execution.
Flows use OpenFlow, an open JSON format, which means flows are portable, diff-able in git, and importable from the Windmill Hub community library without vendor lock-in.
Apps
The app builder is a low-code UI layer on top of scripts and flows. Drag-and-drop components — tables, charts, forms, buttons, text areas, select dropdowns — and bind each component to a script or query. A button click triggers a flow. A table reads from a SQL query. A select dropdown filters the inputs to a Python data fetch. The result is an internal dashboard or admin tool that non-engineers can use safely, because all the logic lives in versioned, permissioned scripts rather than inline SQL pasted into a config field.
Key Features in Depth
Multi-Language Execution Engine
Windmill’s execution engine is written in Rust and uses a worker pool architecture backed by PostgreSQL. TypeScript and JavaScript scripts run on Deno, which provides fast cold-start times (sub-10ms overhead) and native TypeScript support without a compilation step. Python scripts run in isolated virtual environments with automatic dependency installation from import statements — you write import pandas and Windmill installs it. Go scripts are compiled on first execution and cached. Bash scripts run in a sandboxed shell. SQL scripts execute against a named database resource you configure once and reference by name in any script.
The polyglot runtime means teams are not forced to rewrite working code to fit a single supported language. A data science team with Python ETL scripts, a backend team with TypeScript utilities, and a DevOps team with Bash automation can all coexist in the same Windmill workspace.
Resource and Secret Management
Windmill’s resource system is one of its most practically valuable features. You define typed resources — PostgreSQL connections, S3 credentials, Slack webhooks, API keys, OAuth tokens — in a central store. Scripts reference resources by name (e.g., u/admin/prod_db) rather than by value. The raw secret is never exposed in script code, never visible in run logs, and access is controlled by workspace-level permissions. When a credential rotates, you update it in one place and every script that references it picks up the new value automatically.
This is categorically different from environment variables in a CI/CD pipeline: Windmill resources are typed (Windmill knows a PostgreSQL resource has host/port/user/password/database fields and validates them), versioned, and audited. Every resource access is logged.
Scheduling and Cron
Any script or flow in Windmill can be given a cron schedule through the UI or the API. Schedules support standard cron syntax plus timezone specification, so you can run a report “every weekday at 08:00 Europe/Warsaw” without a shell crontab or an external scheduler. Missed executions are tracked, and you can configure Windmill to skip or catch up on missed runs. The schedule history shows every triggered execution with its result, making cron debugging much less painful than parsing system logs.
Webhooks and Triggers
Each script and flow gets a unique webhook URL. POST to the URL with a JSON body and Windmill runs the script, mapping the JSON keys to the function parameters. Webhooks support synchronous execution (response includes the script output) and asynchronous execution (response includes a job ID you can poll). This makes Windmill a practical event processing layer: GitHub webhooks trigger deployment scripts, Stripe webhooks trigger customer provisioning flows, PagerDuty alerts trigger incident response automation.
Git Sync and Version Control
Windmill can sync an entire workspace to a git repository. Scripts, flows, app definitions, schedules, and resource type schemas are serialized to files and committed on every change. Pull requests become the change management process for your internal tools. CI/CD pipelines can deploy changes to Windmill by pushing to the repository. This is the feature that makes Windmill feel like infrastructure rather than a SaaS subscription: your automations live in git, not in a vendor’s database.
Approval Flows and Human-in-the-Loop
Windmill flows can include suspension steps that pause execution and wait for a human action. The platform sends a notification (email, Slack, or a custom webhook) with an approve/reject link. The flow resumes only when a designated approver clicks approve. This is the correct architecture for processes like: “run a database migration, but only after a senior engineer has reviewed the migration plan” or “provision a cloud resource, but only after the budget owner approves the estimated cost.” The approval link is stateless and works without the approver having a Windmill account.
Error Handling and Alerting
Each flow can define error handlers — scripts that execute when any step fails. Error handlers receive the error details, the inputs that caused the failure, and the execution trace. You can write an error handler that posts to Slack, creates a Jira ticket, or triggers a rollback flow. Individual scripts can be configured with retry policies (retry N times with exponential backoff before marking as failed). This makes Windmill suitable for production automation where silent failures are unacceptable.
Concurrency Controls
Scripts and flows can have concurrency limits — a maximum number of simultaneous executions. If the limit is reached, additional executions are queued. This prevents a burst of webhook triggers from overwhelming a downstream API or database. Combined with the worker pool sizing controls in self-hosted deployments, you have fine-grained control over how much work Windmill performs in parallel.
The Windmill Hub
Hub (hub.windmill.dev) is a community library of scripts, flows, and resource type definitions. It covers integrations with common services: Stripe, GitHub, Notion, Airtable, PostgreSQL, MySQL, OpenAI, Slack, SendGrid, and hundreds more. Scripts from the hub can be imported into your workspace with one click and used as flow steps immediately. The resource type definitions in the hub define the expected schema for credentials (so Windmill knows what fields a Stripe API key resource should have), and they’re maintained by the community alongside the official Windmill team.
Windmill and AI: The MCP Integration
Windmill ships an MCP (Model Context Protocol) server that allows AI coding assistants — Claude, Cursor, and others — to discover and trigger Windmill scripts and flows directly from a conversation. This makes Windmill a natural orchestration layer for AI-augmented engineering workflows.
The architecture is worth understanding: an AI assistant receives a request (“run the weekly database backup”), finds the corresponding Windmill script via the MCP server, triggers it with the appropriate parameters, and streams back the execution logs. The script runs in Windmill’s sandboxed, credentialed, audited environment — not in an ad-hoc shell with environment variables pasted from a notes file. The AI gets the output; the engineer gets an audit trail and reproducibility.
For teams building AI agent workflows, Windmill provides the execution substrate: the AI decides what to do, Windmill handles how to do it safely. Scripts can be written to wrap LLM API calls, process outputs, store results, and trigger downstream actions — and all of that is versioned, scheduled, and observable in Windmill’s standard tooling. The combination pairs naturally with a cost-aware approach to AI API usage; our LLM API pricing reference covers the cost landscape for those inference steps.
Pricing
Windmill’s pricing structure reflects its open-source roots: the self-hosted Community Edition is free with no execution limits and no user caps beyond 10 users for advanced SSO features, making it the default choice for teams with execution volume or data sovereignty requirements.
| Plan | Cost | Executions | Key Features |
|---|---|---|---|
| Cloud Free | $0/month | 1,000/month | 1 developer, community support, all core features |
| Cloud Team | $100/month | 10,000/month | Up to 20 users, SSO, team permissions, priority support |
| Cloud Enterprise | Custom | Custom | Unlimited executions, dedicated support, SLA, SAML/SCIM |
| Self-Hosted CE | Free | Unlimited | AGPLv3, Docker/K8s, all features, up to 10 SSO users |
| Self-Hosted Enterprise | Per worker | Unlimited | Audit logs, resource groups, multi-node, SAML/SCIM, support SLA |
For most developer teams evaluating Windmill, the self-hosted Community Edition on a $6–20/month VPS eliminates the execution math entirely. A Windmill instance on a single 2-core/4GB server handles hundreds of concurrent script executions for typical internal tooling workloads.
Self-Hosting Windmill
Windmill’s self-hosted deployment is genuinely straightforward. The official path is Docker Compose with a provided docker-compose.yml that brings up the Windmill server, one or more workers, and a PostgreSQL database. For teams already running Kubernetes, Helm charts are available. The entire stack runs on commodity hardware — a 2-core VPS is sufficient for a small team’s internal tooling load.
The deployment includes: the Windmill server (API and web UI), one or more worker processes (execute scripts and flows), a PostgreSQL database (state, logs, audit trail), and optionally a separate native worker for high-performance TypeScript/Python execution. Workers are stateless and scale horizontally — add workers to increase throughput without touching the server configuration.
Upgrades are a Docker image pull and a docker compose up -d. Windmill handles database migrations automatically on startup. There is no proprietary migration tooling to manage and no platform downtime required for most upgrades. For teams accustomed to the operational overhead of self-hosted workflow tools, this simplicity is notable. It pairs well with the kind of lean infrastructure stack described in our best AI stack for a WordPress affiliate site — Windmill fills the automation orchestration slot without demanding dedicated ops resources.
Windmill vs. The Alternatives
Windmill vs. Retool
Retool is the established market leader for internal tools, with a polished drag-and-drop interface that non-developers can use to build database-backed admin panels. Retool’s strength is accessibility: a product manager or operations lead can build a useful tool without writing code. Its weakness is the pricing model — per-user seat licensing adds up quickly for larger teams, and the proprietary format makes migration painful.
Windmill is code-first: better for teams where developers are building and maintaining the scripts, and where the automation logic is complex enough to warrant real code rather than configuration. Windmill’s self-hosted unlimited-execution model is economically superior for high-volume automation. Retool’s UI builder is more polished for non-developer audiences. The decision comes down to who will be using and maintaining the tools and what the execution volume looks like.
Windmill vs. n8n
n8n is a visual workflow automation tool — closer to Zapier or Make in its node-based interface, but self-hostable and open-source (fair-code license). n8n is optimized for connecting SaaS apps with pre-built integrations: it has hundreds of connector nodes for common services, and building a workflow is largely a configuration exercise of picking nodes and mapping fields.
Windmill requires code at each step — you write a TypeScript or Python function rather than configuring a pre-built node. This is more work for simple integrations (Windmill doesn’t have a “Gmail node” that hides the API calls), but it’s more flexible for complex logic, data transformation, or workflows that touch APIs n8n doesn’t have pre-built connectors for. Teams that want to connect standard SaaS tools without writing code should evaluate n8n. Teams that want to run real code in their workflows should evaluate Windmill.
Windmill vs. Temporal
Temporal is a workflow orchestration engine for distributed systems — designed to run durable, long-running workflows inside application code using language SDKs (Go, TypeScript, Python, Java). It excels at production-level workflow reliability: automatic retries, activity timeouts, saga compensation patterns, and workflow replay from checkpoints. Temporal is the right tool for billing pipelines, order processing systems, and other core application workflows that must be correct under distributed failure conditions.
Windmill is not a replacement for Temporal in those scenarios. It lacks Temporal’s event-sourcing guarantees and is not designed for workflows embedded in application code. But Windmill covers the large space of internal tools, admin automation, and developer scripts that don’t need Temporal’s heavy machinery. Getting started with Temporal requires running a Temporal cluster, writing application code with the SDK, and managing workflow versioning — Windmill requires writing a function and clicking run.
Windmill vs. Zapier / Make
Zapier and Make are no-code automation platforms with 5,000+ pre-built app integrations. They are the right choice for automations that connect standard SaaS apps without custom logic: “when a new row appears in Google Sheets, create a HubSpot contact and send a Slack message.” The integration breadth is unmatched, and non-technical users can build workflows independently.
Windmill requires code and is appropriate when the automation logic exceeds what Zapier/Make can express: complex data transformations, custom API calls, multi-step logic with real branching, or processing volumes that would be cost-prohibitive at per-task pricing. Windmill is the developer alternative to Zapier — more work to build, more power when you need it.
Feature Comparison Table
| Feature | Windmill | Retool | n8n | Temporal | Zapier |
|---|---|---|---|---|---|
| Primary interface | Code (scripts) | Visual drag-drop | Visual nodes | SDK in app code | Visual no-code |
| Code languages | Python, TS, Go, Bash, Rust, SQL | JavaScript (limited) | JavaScript (custom nodes) | Multiple SDKs | None |
| Open source | Yes (AGPLv3) | No | Yes (fair-code) | Yes (MIT) | No |
| Self-hostable | Yes, free | Limited | Yes, free | Yes, free | No |
| App builder | Yes (built-in) | Yes (market leader) | No | No | No |
| Git sync | Yes, native | Limited | Limited | N/A | No |
| MCP / AI integration | Yes (native MCP server) | Partial | No | No | No |
| Best for | Developer teams | Mixed teams (ops + dev) | SaaS integrations | Core app workflows | No-code automations |
Real-World Use Cases
Teams reach for Windmill across a consistent set of use-case patterns:
Database Operations and Administration
Database backups, schema migrations, data audits, row-level cleanup jobs, and reporting queries all fit naturally as Windmill scripts. A TypeScript script connects to a PostgreSQL resource (credentials managed by Windmill, not hardcoded), runs a backup, uploads the result to S3, and sends a Slack confirmation. The script is scheduled to run nightly. Any engineer can trigger it manually through the browser. Every execution is logged. This replaces a cron job on a single server that nobody remembers the password for.
Data Pipelines and ETL
Python scripts running in Windmill can use pandas, SQLAlchemy, requests, and any other PyPI package. A common pattern is: fetch data from an external API, transform and validate it, upsert into a database, and emit metrics. Windmill’s flow engine adds branching (skip if no new data), error handling (alert if row counts drop unexpectedly), and scheduling (run hourly). Data engineering teams that used to maintain a Prefect or Airflow deployment for simple pipelines often find Windmill sufficient and significantly simpler to operate.
Internal Admin Tools
An operations team needs to manage user accounts: search users, update subscription tiers, send one-off emails, flag accounts for review. In Windmill, each of those is a script. The app builder wraps them in a dashboard with a search input and action buttons. The operations team uses the dashboard without touching the database or asking engineering for a query. Engineering maintains the scripts in git. Permissions control which users can run which scripts. Audit logs record who did what and when. This is the Retool use case, implemented on code-first infrastructure.
Webhook Processing
Stripe payment webhooks, GitHub PR event webhooks, and inbound Slack slash commands all fit the Windmill webhook pattern. A Windmill script receives the webhook payload, validates the signature, extracts the relevant fields, and runs business logic (provision a customer, notify a channel, update a database record). The webhook URL is generated by Windmill, concurrency is controlled, failed executions are retried automatically, and every event is logged for debugging.
Scheduled Reporting
A Python script fetches data from a database, generates a formatted report (CSV, HTML, or PDF), and emails it to a distribution list. Scheduled daily or weekly. Windmill’s output capture stores the report alongside the execution log. If the report fails (data anomaly, API timeout), the error handler sends an alert and the engineer can inspect the full execution trace — inputs, intermediate outputs, error details — from the Windmill UI without SSH access to any server.
AI Agent Orchestration
Teams building AI-augmented workflows use Windmill as the execution layer: the AI model decides which script to run and with what parameters; Windmill executes it in a sandboxed, credentialed environment; the AI receives the output. Windmill scripts can wrap OpenAI, Anthropic Claude, or other LLM API calls, and the flow engine handles sequencing, branching on model outputs, and error recovery. The MCP integration makes this architecture available directly from AI coding assistants without additional middleware. For teams tracking API costs across multiple models, our LLM API pricing reference covers the current rate landscape.
Pros and Cons
Strengths
- Code-first with real language support — Python, TypeScript, Go, Bash, and SQL in the same platform; no proprietary scripting dialect to learn.
- Self-hostable with no execution limits — AGPLv3 Community Edition covers the full feature set on your own infrastructure. High-volume teams are not penalized by per-execution pricing.
- Git sync is native — automations live in version control like the rest of your code, not in a vendor’s database.
- Resource management is correct — typed, permissioned, audited credential storage replaces environment variables and hardcoded secrets.
- Three products in one — scripts, flows, and an app builder cover the full internal-tooling lifecycle without additional platforms.
- MCP integration — native AI assistant integration makes Windmill a first-class option for AI-augmented engineering workflows.
- Fast execution — sub-10ms overhead for TypeScript scripts; Python with dependency caching restarts in under a second after the first run.
Limitations
- Code-first is also a floor — for non-developer users, the auto-generated forms are functional but basic. Retool’s drag-and-drop app builder produces more polished results for complex dashboard requirements.
- Self-hosting is ownership — the simplicity of Docker Compose deployment does not eliminate the responsibility of running infrastructure. Upgrades, backups, and incident response are on you.
- Pre-built integrations are community-maintained — the Windmill Hub has hundreds of scripts, but it is not the same as Zapier’s 5,000+ certified app connectors. Connecting to a niche SaaS API means writing the integration yourself.
- Not a Temporal replacement — Windmill does not provide Temporal’s durable execution guarantees or event-sourcing workflow history. For mission-critical production application workflows, Temporal remains the correct tool.
- App builder is behind Retool — the component library in Windmill’s app builder is functional but smaller than Retool’s. Complex internal dashboards with rich visualizations may require more custom work.
Who Windmill Is For
Windmill is the right choice for engineering teams who treat their internal tools and automations as software: versioned in git, reviewed in pull requests, deployed through CI/CD, observed with logs. If your team already has accumulated Python ETL scripts, TypeScript utilities, and Bash automation that lives on someone’s laptop or in a shared server’s crontab, Windmill is the natural next step: a governed, collaborative, observable environment for that work.
It suits data engineering teams building ETL pipelines who want Python’s full ecosystem without the operational overhead of Airflow or Prefect. DevOps teams who have outgrown bash scripts in CI/CD and want scheduled, triggered, human-approved operations tooling. Backend engineering teams who need to build internal admin tools without commissioning a full Rails admin application. Organizations prioritizing open-source and self-hosting for cost control, compliance, or data sovereignty. And engineering teams exploring AI-augmented workflows where an AI agent needs a secure, audited execution layer for the scripts it decides to run.
It is a less natural fit for teams where the primary tool builders are non-technical (Retool or n8n serve them better), for simple SaaS-to-SaaS automation without custom logic (Zapier is faster to configure), or for production application workflows requiring Temporal’s durability guarantees.
Frequently Asked Questions
Is Windmill free?
The self-hosted Community Edition is free and open-source under AGPLv3, with no execution limits and no expiry. The cloud-hosted free plan includes 1,000 executions per month. For most teams evaluating Windmill, the self-hosted path on a low-cost VPS is the practical choice.
How hard is it to self-host Windmill?
Straightforward. The official Docker Compose setup brings up the server, workers, and database with a single command. Most teams with basic Docker experience can have a working Windmill instance running in under an hour. Kubernetes Helm charts are available for teams that want production-grade orchestration.
Can Windmill replace Zapier?
For automations that require code, yes — Windmill is more flexible and powerful. For no-code SaaS app integrations, Zapier’s pre-built connectors are faster to configure. Many teams run both: Zapier for simple webhook-to-action flows between standard SaaS tools, Windmill for custom scripts and complex automations.
Which languages does Windmill support?
Python, TypeScript, JavaScript (Deno), Go, Rust, Bash, and SQL. The same workspace can contain scripts in different languages, and a flow can chain a Python data-fetch step into a TypeScript transformation into a SQL write.
Does Windmill work with AI coding assistants?
Yes. Windmill ships a native MCP server that lets Claude, Cursor, and other MCP-compatible assistants discover and trigger scripts and flows. This makes Windmill a natural execution layer for AI agent workflows — the AI decides what to run, Windmill handles execution in a secure, credentialed, audited environment.
How does Windmill handle secrets?
Secrets are stored in Windmill’s resource system — typed, permissioned objects that scripts reference by name. The raw secret value is never exposed in script code, run logs, or the UI after creation. Access to resources is controlled by workspace-level permissions, and every resource access is recorded in the audit log.
Is Windmill suitable for production workflows?
Yes, for internal tools and developer automation. For application-level production workflows requiring distributed transaction guarantees or event-sourcing replay — Temporal is more appropriate. Windmill is production-grade for its designed use cases: scheduled scripts, internal tools, automation pipelines, and developer operations workflows.
Verdict
Windmill earns a 4.4 out of 5 for developer teams evaluating open-source platforms for internal tools and workflow automation. The combination of real multi-language code execution, a capable flow orchestrator, an app builder, and a native MCP integration for AI workflows covers the full internal-tooling spectrum in a single platform. The self-hosted deployment model eliminates execution-based pricing at the tier where teams actually need it.
The honest caveats are that it is code-first (a strength for developers, a friction point for non-technical tool builders), that self-hosting is an operational commitment even when deployment is simple, and that the app builder has not reached Retool’s level of polish for complex dashboard requirements. None of these are reasons to avoid Windmill — they are the shape of the trade-off. Teams choosing Windmill over Retool are choosing code ownership and self-hosted economics over polished UI and managed infrastructure.
For engineering teams that treat automations as software — versioned, reviewed, deployed, observed — Windmill is the cleanest implementation of that philosophy available today. The MCP integration is a genuine differentiator in the AI-augmented engineering workflow space. And the open-source model means the tool will stay accessible regardless of what the SaaS pricing landscape does next quarter. We recommend it without reservation for its target audience. For a deeper look at how Windmill fits into a broader developer stack, see our best AI stack for a WordPress affiliate site and our Supabase backend platform review.
Pros & cons
Pros
- Open-source & self-hostable – AGPL v3 allows running it on your own infrastructure (e.g. Hostinger VPS) without vendor lock-in
- Performance – ultra-fast execution loop built on Rust, SQL database, and lightweight worker threads
- Multi-language support – run Python, TypeScript, Go, and Bash scripts in the same unified workflow seamlessly
Cons
- Steeper learning curve – requires coding scripts rather than using a pure drag-and-drop visual editor (like Retool)
- Enterprise licensing – self-hosted premium features (like multi-node clusters and SAML) require enterprise commercial license
- Ecosystem size – community templates and pre-built integration nodes are smaller than Retool’s legacy ecosystem
Who it’s for
Ideal for: Developers and infrastructure teams who need a self-hostable Retool alternative that orchestrates Python, TypeScript, and Go scripts with Temporal-like reliability.