Windmill: The Rust-Powered Engine That Turns Scripts Into Production Infrastructure
Hook
What if every Python script you wrote automatically became a web API with a generated UI, could be chained into complex workflows, and executed in a sandboxed environment—all without leaving your editor?
Context
The infrastructure tooling landscape has a fragmentation problem. Data engineers use Airflow for orchestration. Frontend developers use Retool for internal tools. Backend teams use Temporal for durable workflows. DevOps writes Bash scripts that live in cron jobs. Each tool requires different deployment infrastructure, authentication systems, and mental models.
Windmill emerged as a unified developer platform that collapses these categories. Instead of maintaining separate systems for scripts, workflows, APIs, and internal UIs, Windmill treats everything as code that can be composed, scheduled, and exposed through automatically generated interfaces. It’s positioned as a self-hostable alternative to commercial platforms like Retool and Pipedream, but with the workflow orchestration capabilities of Temporal and the scheduler functionality of Airflow—all in a single AGPLv3-licensed platform built on Postgres and Rust.
Technical Insight
Windmill’s architecture centers on Postgres as a transactional queue, with Rust-based workers pulling jobs and executing them in isolated environments. This isn’t just a design choice—it’s the foundation for their performance claims. By leveraging Postgres’s SKIP LOCKED feature for queue operations and Rust’s zero-cost abstractions, they’ve built a system that handles both rapid-fire lightweight tasks and long-running workflows without the overhead of traditional workflow engines.
The script-to-API transformation happens through parameter introspection. Here’s actual TypeScript from their documentation:
import * as wmill from "windmill-client";
import * as cowsay from "cowsay@1.5.0";
type Postgresql = {
host: string;
port: number;
user: string;
dbname: string;
sslmode: string;
password: string;
};
export async function main(
a: number,
b: "my" | "enum",
c: Postgresql,
d = "inferred type string from default arg",
e = { nested: "object" }
) {
const email = process.env["WM_EMAIL"];
let variable = await wmill.getVariable("f/company-folder/my_secret");
const lastTimeRun = await wmill.getState();
console.log(cowsay.say({ text: "hello " + email + " " + lastTimeRun }));
await wmill.setState(Date.now());
return { message: "Success" };
}
Windmill parses this function signature and generates a web form where a becomes a number input, b becomes a dropdown with two options, c becomes a resource selector for Postgres connections, and d and e get appropriate UI controls based on their default values. The wmill client provides state management across runs and access to Windmill’s permission system for secrets. Critically, you can import any npm package inline (cowsay@1.5.0)—Windmill handles dependency resolution using Bun or Deno at runtime.
The polyglot support extends beyond TypeScript. Python scripts use uv for dependency management, Go scripts are compiled on-the-fly, and Bash scripts run in controlled environments. All execution happens in sandboxed containers using nsjail and PID namespace isolation on Linux, preventing scripts from interfering with each other or the host system.
Flows (Windmill’s term for workflows) compose these scripts into directed acyclic graphs with branching logic, error handling, and retries. The flow editor is visual, but everything compiles down to JSON definitions that can be version-controlled through their CLI or VS Code extension. Flows can be triggered by schedules, webhooks, Kafka messages, WebSockets, emails, or HTTP routes—making them suitable for everything from data pipelines to event-driven microservices.
The low-code app builder sits on top of this foundation. You drag components onto a canvas, bind them to script outputs, and wire up interactivity without writing React boilerplate. But unlike pure low-code platforms, you can always drop down to custom TypeScript components when the visual builder hits its limits. This escape hatch matters—it’s the difference between a toy and a production tool.
Gotcha
The AGPLv3 license is the first wall you’ll hit. If you modify Windmill’s core and offer it as a service, you must open-source your changes. For internal use this is fine, but SaaS companies building on top of Windmill need to evaluate whether this fits their business model or budget for a commercial license from Windmill Labs. The license isn’t inherently bad—it’s the same as GitLab and n8n—but it requires careful legal review for commercial deployments.
The sandboxing story is Linux-specific. Windmill uses nsjail for isolation, which doesn’t exist on macOS or Windows. Local development on non-Linux systems requires Docker, adding friction to the inner development loop. The VS Code extension helps, but you’re still running containers locally, which means slower iteration compared to native execution. The README acknowledges this implicitly by focusing on Docker Compose and Kubernetes deployment paths.
The ecosystem is young. With 16,000+ GitHub stars, Windmill has momentum, but compare that to Airflow’s 250,000+ stars or Temporal’s 50,000+. The community Hub has shared scripts and flows, but you won’t find the deep library of integrations and operators that mature platforms offer. You’ll be writing more connectors yourself. The documentation is solid for core features but thins out quickly when you venture into advanced use cases or edge cases around multi-tenancy, complex permission models, or scaling beyond a few hundred concurrent jobs.
Verdict
Use Windmill if you’re building internal tooling for a team that writes scripts in multiple languages, wants those scripts to become APIs and UIs without boilerplate, and can self-host on Linux infrastructure. It excels when you need fast workflow orchestration (the 13x vs Airflow claim is specific to their benchmark scenarios), want Git-based version control for all automation, and prefer AGPLv3 open-source over vendor lock-in. Teams migrating from sprawling collections of cron jobs, Lambda functions, and one-off Retool apps will find Windmill’s unified model compelling. Skip it if you need battle-tested enterprise features like multi-region active-active deployment, have compliance requirements that conflict with AGPLv3, require native Windows/macOS execution without containers, or already have deep investment in Airflow DAGs or Temporal workflows that would be expensive to migrate. The platform is production-ready but not yet boring technology—expect to contribute fixes and features yourself as you push the boundaries.