Windmill Review: Open Source Workflow Engine That Replaces Zapier, Airflow, and Retool

Windmill is one of those tools that's hard to categorize. The homepage says it replaces Zapier, Airflow, and Retool simultaneously. That sounds like marketing hyperbole, but after spending several weeks with it, I think they're mostly right — with caveats.

Here's an honest assessment.

What Windmill Actually Is

Windmill is an open-source developer platform for building internal tools, automation scripts, and data workflows. The core product is a script editor and workflow engine where you write Python, TypeScript, Go, or Bash, and Windmill handles:

• Scheduling and triggering (cron, webhooks, manual)
• Dependency management (auto-resolves Python/npm packages)
• A web UI editor with LSP-powered autocomplete
• Secret management with a built-in variable store
• A drag-and-drop flow builder for chaining scripts
• Auto-generated UIs for running scripts with form inputs
• An app builder (like Retool) for internal dashboards

The pitch: instead of having Zapier for automations, Airflow for data pipelines, and Retool for internal tools, you have one platform. For small to medium engineering teams, this consolidation is genuinely valuable.

Installation

Self-hosted via Docker Compose:

version: "3.7"
services:
  db:
    image: postgres:16
    environment:
      POSTGRES_DB: windmill
      POSTGRES_USER: windmill
      POSTGRES_PASSWORD: windmill_password
    volumes:
      - db_data:/var/lib/postgresql/data
 
  windmill_server:
    image: ghcr.io/windmill-labs/windmill:main
    environment:
      DATABASE_URL: postgres://windmill:windmill_password@db/windmill
      MODE: server
    ports:
      - "8000:8000"
    depends_on:
      - db
 
  windmill_worker:
    image: ghcr.io/windmill-labs/windmill:main
    environment:
      DATABASE_URL: postgres://windmill:windmill_password@db/windmill
      MODE: worker
      WORKER_GROUP: default
    depends_on:
      - db
 
volumes:
  db_data:

docker-compose up -d

That's it. Windmill is running on port 8000 within minutes. There's also a Helm chart for Kubernetes:

helm repo add windmill https://windmilllabs.github.io/windmill-helm-charts
helm install windmill windmill/windmill

The Script Editor

This is Windmill's strongest feature. You write a function in Python or TypeScript, and Windmill automatically:

• Generates a web form UI from your function parameters
• Handles dependency installation from your imports
• Runs the script in an isolated sandbox
• Provides a built-in secrets store for API keys

A simple example — a Python script to restart a Kubernetes deployment:

import wmill
from kubernetes import client, config
 
 
def main(namespace: str, deployment_name: str, reason: str = "Manual restart"):
    """
    Restart a Kubernetes deployment.
    Accessible via auto-generated UI form.
    """
    # Load kubeconfig from Windmill secret
    kubeconfig_b64 = wmill.get_variable("f/kubernetes/kubeconfig")
    # ... setup client
 
    apps_v1 = client.AppsV1Api()
    
    # Patch annotation to trigger rolling restart
    patch = {
        "spec": {
            "template": {
                "metadata": {
                    "annotations": {
                        "windmill.dev/restart": datetime.now().isoformat(),
                        "windmill.dev/reason": reason
                    }
                }
            }
        }
    }
    
    apps_v1.patch_namespaced_deployment(
        name=deployment_name,
        namespace=namespace,
        body=patch
    )
    
    return f"Restarted {namespace}/{deployment_name} — reason: {reason}"

Once you save this, Windmill auto-generates a form where non-technical team members can fill in namespace, deployment name, and reason, then click Run. The audit log records who ran it and what parameters they used.

This pattern — wrapping kubectl operations in Windmill scripts with auto-generated UIs — is genuinely useful for reducing the number of people who need raw cluster access.

The Flow Builder

Windmill's flow builder lets you chain scripts visually. It's similar to GitHub Actions workflow syntax but visual.

You can create flows like:

1. Trigger: webhook from GitHub PR merge
2. Step 1: Run build script → get image tag
3. Step 2: Update Kubernetes deployment with new image
4. Step 3: Wait for rollout to complete (loop until healthy)
5. Step 4: Run smoke tests
6. Step 5: Send Slack notification with result

Each step can use the output of previous steps. Branching, error handling, and for-each loops are all supported visually. It's less code than Airflow DAGs for simple workflows, though less powerful for complex data engineering.

What's Genuinely Good

Developer experience is excellent. The web editor with LSP, the auto-generated UIs, the secret management — these are polished and work well.

Self-hostable and truly open source. Unlike some "open source" tools that lock key features behind enterprise plans, Windmill's core is fully functional in the free version. The paid cloud and EE versions add SSO, audit logs, and some performance features, but the self-hosted version is usable.

The audit trail is surprisingly complete. Every script run, every parameter used, who triggered it, the output — all logged. For internal tool compliance requirements, this is valuable.

Multi-language support works. Python, TypeScript, Go, and Bash run natively in isolated workers. You're not forced into a single language for your automation.

Where It Falls Short

The flow builder hits complexity walls. For simple automation flows it's great. For complex data engineering — branching logic based on data conditions, dynamic task generation, sensor-based triggers — Airflow or Prefect handle it better. Windmill isn't trying to be a full Airflow replacement for serious data engineering.

App builder is limited vs. Retool. If you're building complex internal tools with sophisticated filtering, joins, and real-time updates, Retool or Appsmith are more capable. Windmill's app builder covers simple CRUD dashboards well but struggles with complex layouts.

Documentation gaps. The concepts are well-documented, but there are gaps when you get into production scenarios — managing secrets rotation, scaling workers for high-throughput jobs, configuring worker groups for resource isolation.

Cold starts on workers. Python scripts with heavy dependencies (pandas, kubernetes client, etc.) have noticeable cold start times as Windmill installs packages in a fresh environment. In practice you work around this by pre-warming scripts or using TypeScript for lightweight operations.

Windmill vs. Alternatives

The sweet spot for Windmill is internal developer tooling — scripts that DevOps teams run manually but want to expose safely to other teams without giving them cluster access. It's better at this than any alternative I've tested.

Verdict

Windmill is not a silver bullet that replaces Zapier + Airflow + Retool for everyone. But for engineering teams that want a single self-hosted platform for internal automation, developer runbooks, and simple internal tools, it's one of the most compelling open source options available.

The developer experience is genuinely good, the open source version is fully featured enough to be production-worthy, and the auto-generated UIs for scripts solve a real problem: letting non-engineers run operations scripts safely without cluster access.

If your team is managing more than a few internal scripts and feeling the pain of "only engineers can run this," Windmill is worth evaluating.

Score: 7.8/10 — Solid, polished, and genuinely useful for DevOps teams. Limited by flow complexity ceiling and app builder maturity.

Interested in more DevOps platform reviews? See our Kargo GitOps promotion tool review and Dagger CI/CD as code review.