Your ops team lives in Python. Your sales lead wants a button that runs a script without learning Git. Your engineer wants review gates before anything touches production Postgres. One tool claiming to be "no-code" usually makes at least one of those people miserable.
Windmill (windmill-labs/windmill) tries to hold all three in the same workspace. ~18k GitHub stars, AGPLv3 community edition, Rust workers behind a Svelte UI. You write scripts in Python, TypeScript, Go, Bash, SQL, and a pile of other runtimes; Windmill turns them into forms, APIs, cron jobs, and visual flows. Business users can build with AI in the browser; engineers sync the same artifacts from VS Code, promote through dev/prod, and park risky jobs on isolated worker groups. It is not n8n with a paint job — it is closer to "Retool plus Airflow plus internal apps," self-hosted on Postgres.
What it actually does
Windmill's loop starts with a script: a plain function with typed parameters. The platform parses those types and auto-generates a runnable UI, webhook endpoint, and CLI entry. Chain scripts into flows (visual editor or code-defined workflows with approvals). Stack flows and scripts into apps — full internal tools without shipping a separate React repo for every spreadsheet replacement.
Triggers are broad: schedules, webhooks, HTTP routes, Kafka, WebSockets, email, and more. Data layer pieces matter for real teams: workspace data tables (managed Postgres you query without hand-wiring connection strings), DuckDB scripts over S3/Parquet, and pipeline-style SQL for lakehouse tables. If you have dbt, it can run as-is inside the platform.
The AI angle is governance-first: AI sessions fork a workspace preview, show a diff, and respect folders, roles, and protection rulesets so "the chatbot deployed to prod" is not the default horror story. MCP support lets Cursor-style agents call scripts in a controlled workspace — useful, scary, and why those permission models exist.
Why self-host Windmill?
Credentials and customer data stay on your metal. Slack tokens, Stripe keys, and CRM exports live in Windmill's secret store (encrypted per workspace) on your Postgres — not in a multi-tenant SaaS automation vendor. For Canadian teams thinking about PIPEDA, running workers in Beauharnois or Alberta is a design choice, not a support ticket.
Code-first beats diagram-only at scale. Visual flows are great until you need tests, Git history, and code review. Windmill's CLI and Git sync let engineers treat workflows like software while still handing sales a generated form.
Performance for serious job volume. Windmill's Rust queue and worker model target high-throughput orchestration (they benchmark against Airflow, Prefect, Temporal). Lightweight jobs add on the order of tens of milliseconds of overhead — relevant when you are firing hundreds of small tasks, not just a nightly cron.
License literacy. Internal use of the community edition is free within built-in quotas. Reselling Windmill as a managed platform or wrapping it in your product needs a commercial license from Windmill Labs. AGPL applies to the open build — read the license if you are an MSP productizing internal tools for clients.
What running it takes
Official path: Docker Compose (compose file + Caddy + .env), default UI on port 80, login admin@windmill.dev / changeme until you fix that on day one. Postgres is required — bundled in compose or point DATABASE_URL at managed RDS/Neon/Cloud SQL.
Sizing rule of thumb from upstream: about 1 vCPU and 1–2 GB RAM per worker, plus headroom for the API server and database. Sandboxing uses nsjail and namespace isolation; workers pull jobs by tag so prod workers can sit in a tighter network than dev.
Helm charts exist for Kubernetes shops. OAuth/SSO (Google, Microsoft, Okta) configures from the superadmin UI. Plan backups on Postgres — the queue, secrets metadata, and workspace definitions all live there.
Compared to our n8n post: choose n8n when integrators want a huge node catalog and fair-code SaaS-style automation. Choose Windmill when engineers want Git, multi-language scripts, internal apps, data pipelines, and explicit promotion between environments on one orchestrator.
Who it's for (and who should skip it)
Good fit: product and ops teams building internal tools, data teams wiring SQL/Python pipelines with approvals, agencies standardizing client automation on self-hosted infra, orgs rolling out AI-assisted builders but refusing to skip code review.
Maybe skip it: if you only need three Zapier-style integrations and nobody will maintain Postgres, a lighter tool wins. If you want zero ops and no AGPL homework, Windmill Cloud exists — this post is about self-hosting. If your team hates writing any code at all, the platform still expects someone technical to own workers, secrets, and deploy rules.
Hosting it in Canada
We deploy Windmill on Canadian Docker hosting and larger VPS stacks when clients want workflows, apps, and AI guardrails in-country — TLS, Postgres backups, separate worker groups for staging, and monitoring on the queue depth so a stuck job does not silently pile up.
Tell us your languages, trigger types, and who needs the AI builder if you want help sizing workers or drawing the line between Windmill and simpler automation in your stack.
