Windmill

What is Windmill?

Windmill takes a script in Python, TypeScript, Go or Bash and turns it into a versioned job with a generated UI, an API endpoint and a schedule, without you writing any glue. It is designed for developers who already have scripts and want them to be self-service for the rest of the team rather than locked in someone's terminal.

Best for

Developers who want their existing scripts exposed as scheduled jobs and internal APIs

Why choose Windmill

Windmill is the missing link between a folder of scripts and something other people can use. It runs your Python, TypeScript, Go, Bash or SQL, and for each script automatically generates a web form, an API endpoint and a scheduled job. That means a data pipeline you wrote for yourself can be handed to a colleague as a real interface without building one, and operational scripts stop living on one person's laptop as things everybody is afraid to touch.

Replaces

• Zapier
• Retool
• Airflow

Key features

• Runs Python, TypeScript, Go, Bash and SQL
• Auto-generated UI and API for every script
• Cron schedules, webhooks and workflow chaining
• Version control and per-script permissions

What to watch out for

The auto-generated interfaces are genuinely useful and also generic — they present arguments as a form, which is not the same as a designed application. Once you need anything beyond that, you are back to writing front-end code. The platform is a full application with a database and workers, so it is infrastructure to run and upgrade, and its feature set at the self-hosted tier needs checking against the hosted product. Complex dependency environments also take some care to work reliably.

How to deploy

• Docker
• Kubernetes

Getting started

Deploy the Compose stack and check the worker processes are healthy before writing any scripts — worker problems produce confusing failures that look like script bugs. Start by running the same command-line tool you already use, so you learn argument handling and generated UI on something familiar. Store secrets through the platform's variable store rather than hard-coding them, and plan who can see which scripts, since permissions here are the difference between a shared tool and a shared liability. Put the database and workspace directories on backed-up storage.

Typical setup

It is deployed as a full application with a database and worker processes, typically on an internal server or a mid-sized VPS. Teams migrate command-line scripts and cron jobs into it so that they run somewhere other than an individual's machine, gain a generated form for non-technical colleagues, and get an API endpoint for free. Secrets are kept in the platform's variable store, and access is governed per script, which is what makes it safe to share operational tooling.

Who should look elsewhere

Overkill for someone running two cron jobs, and a mismatch for anyone without engineering capacity, because the scripts still need writing and maintaining. It is also not a data platform: if you need scheduling, lineage, data quality checks and backfills, a proper orchestrator will serve you better than a tool whose focus is turning scripts into interfaces.

Project health

• GitHub stars: 18,078
• Last code push: 2026-10-01
• Open issues: 840
• Status: actively developed

Figures pulled from the GitHub API and refreshed periodically.