Windmill

Windmill is an open-source developer platform that transforms scripts written in Python, TypeScript, Go, Bash, SQL, PowerShell, Rust, PHP, Java, C#, Ansible, and more into fully operational internal tools — without requiring a dedicated platform engineering team. Each script automatically gets a generated web UI, webhook endpoint, and HTTP route, so developers can share their work with non-technical colleagues immediately. Flows let you chain scripts into complex orchestrations with branching, iteration, error handling, and suspend/resume support, all expressed through a visual DAG editor.

The backend is built with Rust for maximum throughput — Windmill benchmarks show sub-50ms queue-to-execution latency, making it 13x faster than Airflow on equivalent workflows. PostgreSQL is the only required dependency and serves as both the job queue and the state store, eliminating complex infrastructure like Redis or dedicated brokers. Workers are stateless and horizontally scalable, with support for dedicated worker groups, nsjail sandboxing for security isolation, and Docker-in-Docker support for containerized jobs.

Windmill offers deep developer tooling that sets it apart from low-code competitors: a VS Code extension with full LSP support, two-way Git sync for code-as-infrastructure workflows, a CLI for local development and CI/CD pipelines, and Claude-integrated AI assistance for generating scripts and flows. The frontend is built with Svelte 5 and includes a rich app builder for composing scripts and flows into drag-and-drop dashboards with charts, tables, forms, and custom components.

Deployment is straightforward via Docker Compose (three files) or Helm charts for Kubernetes. Windmill supports every major cloud provider and managed PostgreSQL service. The community edition is free for internal use under AGPLv3, with enterprise features available under a commercial license for managed service providers and redistributors.

What You Get

• Auto-generated Script UIs - Every script’s parameters are automatically parsed and rendered as a web form with appropriate input types, validation, and run history — no frontend code needed to share scripts with non-technical users.
• Visual Flow Editor - Build DAG-based workflows in a drag-and-drop editor that supports sequential steps, branching (if/else), loops, parallel fan-out, error handlers, and suspend/resume for human-in-the-loop approval steps.
• App Builder - Compose scripts and flows into polished internal dashboards using a drag-and-drop UI builder with 60+ components including tables, charts, forms, modals, and custom Svelte or React components.
• Multi-Language Script Support - Run scripts in Python (with uv), TypeScript/JavaScript (with Bun or Deno), Go, Bash, PowerShell, SQL (Postgres, MySQL, BigQuery, Snowflake, DuckDB), Rust, PHP, Java, C#, R, and Ansible from a single platform.
• Git Sync & VS Code Extension - Two-way synchronization between Windmill workspaces and GitHub repositories, with a VS Code extension providing full LSP support, inline script testing, and one-click deployment from your editor.
• Rich Trigger System - Scripts and flows can be triggered via webhook, HTTP route, cron schedule, Kafka topic, WebSocket message, email, MQTT, NATS, SQS, GCP Pub/Sub, Postgres replication, or Azure Service Bus — covering every event-driven scenario.
• Worker Groups & Autoscaling - Assign scripts to dedicated worker groups for workload isolation (e.g., GPU jobs, high-memory tasks, multi-tenant isolation) with Kubernetes autoscaling support via the official Helm chart.
• Hub & Resource Types - Access 400+ community-contributed scripts and flows on WindmillHub, with typed resource definitions for 60+ integrations (Slack, GitHub, AWS, GCP, Stripe, Postgres, etc.) that generate secure credential forms.

Common Use Cases

• Internal data pipelines - A data engineer writes Python scripts that pull from Snowflake, transform with DuckDB, and push results to S3 or a dashboard; Windmill orchestrates these as a scheduled flow with retry logic and Slack alerts on failure — no Airflow setup required.
• Customer onboarding automation - A SaaS team builds a flow triggered by a webhook from their auth provider: provision a database, send a welcome email via SendGrid, create a Slack channel, and post a notification — all chained in a visual editor with error handling at each step.
• Admin dashboards for non-engineers - A product manager builds a Windmill app that lets support staff look up users, trigger refunds via Stripe API, and update database records — wrapping existing scripts in a polished UI with access controls and audit logging.
• High-throughput batch processing - A finance team runs 500+ daily reconciliation scripts against multiple payment processors using Windmill’s concurrent workers, with dedicated worker groups for different data sources and automatic retry on transient failures.
• AI agent orchestration - A developer uses Windmill’s MCP server integration and Claude AI assistance to build agentic workflows where LLMs generate and run scripts, inspect results, and chain follow-up actions — all observable and resumable through the Windmill UI.
• Infrastructure automation - A DevOps team uses Windmill to run Ansible playbooks, Bash scripts, and Terraform wrappers via scheduled flows, replacing fragile cron jobs with observable, auditable, and restartable automation with full execution history.

Under The Hood

Architecture Windmill follows a clean server/worker split where stateless API servers handle HTTP routing, authentication, flow orchestration, and UI serving, while stateless workers pull jobs from a PostgreSQL-backed queue and execute them in isolated processes. This architecture means horizontal scaling is trivially achieved by adding worker replicas — no shared state, no coordinator bottleneck. The queue is implemented entirely in PostgreSQL using advisory locks and row-level locking, eliminating Redis or RabbitMQ as dependencies. Flow execution uses a declarative JSON schema (FlowValue/FlowModule) that encodes DAG structure, branching conditions, retry policies, and suspend semantics, allowing the flow engine to resume mid-flow after worker restarts. The modular Rust workspace is organized into purpose-specific crates (windmill-queue, windmill-worker, windmill-api-flows, windmill-trigger-kafka, etc.) with clear dependency boundaries, making it straightforward to understand, extend, and compile with or without enterprise features using Cargo feature flags.

Tech Stack The backend is written in Rust using Tokio for async execution, sqlx for compile-time-checked PostgreSQL queries, and Axum for the HTTP API layer. PostgreSQL 16 is the sole required external service, serving as queue, job store, secret store, and configuration database. Each language runtime is invoked via its native executor module: Python scripts run via uv for fast dependency resolution, TypeScript via Bun (with Deno as an alternative), Go scripts compile on first run and cache the binary, and SQL scripts execute directly against their target database. The frontend is built with Svelte 5 using its new runes-based reactivity system, with Monaco Editor embedded for a full IDE experience including LSP, type checking, and autocompletion for all supported languages. Job sandboxing uses Google’s nsjail for filesystem and resource isolation, with PID namespace isolation preventing jobs from accessing worker process memory.

Code Quality Windmill’s codebase shows extensive engineering investment across all layers. The Rust backend has strong type safety enforced through sqlx’s compile-time query validation, custom error types with explicit propagation via anyhow, and comprehensive test coverage across 49 distinct integration test files covering flow engine behavior, authentication, worker isolation, trigger systems, and edge cases like job cancellation and retry semantics. The frontend has unit tests for critical logic (AI store, debouncer, user draft migration) using Vitest. CI runs Docker-image builds on every push. Code organization is consistent — each language executor lives in its own module with the same interface contract, and the trigger system is similarly modular with one crate per trigger type. Comment density is moderate in business logic, high in the worker and queue modules where behavior is complex.

What Makes It Unique Windmill’s primary differentiator is treating the PostgreSQL job queue as a first-class architecture decision rather than a convenience: because all job state, flow position, and results live in Postgres, the system can survive complete worker restarts mid-flow, support fan-out to thousands of parallel branches, and provide a queryable audit trail without any additional infrastructure. The combination of sub-50ms queue-to-execution latency (benchmarked against Airflow, Prefect, and Temporal) with full script sandboxing via nsjail is unusual — most fast orchestrators sacrifice isolation, and most secure orchestrators sacrifice performance. The AI integration goes beyond autocomplete: Windmill’s MCP server exposes scripts and flows as tools that Claude can discover and invoke, enabling LLM-driven automation where the agent itself can compose and run Windmill workflows. The app builder’s tight integration with the script/flow layer — where UI components bind directly to script outputs and trigger flow inputs — creates a coherent platform rather than gluing together separate tools.

Self-Hosting

Windmill’s source code is split across multiple licenses. The AGPLv3 portions cover the core open-source components compilable from source without the enterprise feature flag, and these can be used freely for internal purposes, modified, and run in production. However, the binary distributed via Docker images (ghcr.io/windmill-labs/windmill) also includes proprietary enterprise features that are not open-source — you can use them internally for free, but you cannot sell, resell, serve Windmill as a managed service, or embed it in a commercial product without a commercial license from Windmill Labs. This is an important distinction: the project is not fully open-source in the traditional sense, despite the AGPLv3 badge. Developers evaluating self-hosting for internal use only are fully covered; those building products on top of Windmill need to contact sales.

Running Windmill yourself requires a PostgreSQL database (the only external dependency), Docker or Kubernetes for the server and worker processes, and sufficient compute for your workload. The rule of thumb is 1 worker per 1 vCPU and 1-2 GB RAM. The Docker Compose setup requires only three files to get started and is genuinely production-capable for small teams. Kubernetes deployment via the official Helm chart is well-documented and supports autoscaling worker groups. You are responsible for PostgreSQL backups, database maintenance, worker capacity planning, and upgrades — Windmill releases multiple versions per week (the project was at v1.730.0 as of mid-2026), so keeping up requires a process. The self-hosted setup has no built-in HA for the server component without additional tooling.

Windmill’s cloud offering (app.windmill.dev) and dedicated instances from Windmill Labs provide managed upgrades, infrastructure monitoring, SLAs, and enterprise support. Enterprise features gated behind a commercial license include audit log exports, SAML/SSO, secret management enhancements, priority support, and high-availability configurations. For teams who want the power of Windmill’s workflow engine without the operational overhead, the managed tier is a pragmatic choice — especially given the rapid release cadence that makes staying current a real effort at scale.