Windmill combines scripts, workflows, and internal apps
Our checkout contained about 1,182,155 source lines, fitting a platform that turns one function into several operational building blocks. A typed Python or TypeScript entry point can become a form, an API, a scheduled job, or one step in a larger flow. The same workspace can hold credentials, state, logs, approval steps, and a custom internal application. That suits engineering teams whose automation has spread across cron, serverless handlers, notebooks, and admin pages.
Language choice is unusually broad for one system. Workers can run TypeScript through Bun or Deno, Python through uv, and code in Go, Bash, PowerShell, PHP, Rust, C#, Java, SQL, and other supported runtimes. Our checkout at commit 74af4ed contained 9,671 files and about 1,182,155 source lines, which matches the product's wide surface. Windmill is closer to an internal developer platform than a visual wrapper around shell commands.
Generated interfaces reduce routine frontend work
Across 9,671 repository files, Windmill includes both script execution and an interface builder. It parses script parameters and generates a runnable form, then lets teams compose those scripts in a flow editor. The app builder is there when the generated form is too plain. This makes sense for invoice tools, data repair jobs, support consoles, and controlled operations where a developer owns the code but another employee needs a safe button.
The platform supports triggers through schedules, webhooks, HTTP routes, Kafka, WebSockets, and email. That breadth also increases the number of paths an operator must test. The repository carries 50 CI workflow files and a tests directory, yet current reports describe edge cases in email size handling, schedule cadence, and error handlers. A workflow that matters financially needs a failure path and monitoring outside the happy-path editor preview.
What happened when we ran it
We cloned commit 74af4ed into an unprivileged Node 22 Debian container with 3 CPUs, 8 GB of RAM, and no secrets. The 103.3 MB checkout held 9,671 files and roughly 1,182,155 source lines. Our harness targeted the Bun-based CLI under ./cli/, so this result covers contributor tooling rather than a complete Windmill server. No Dockerfile was present at the repository root.
Installation succeeded in 58 seconds. Bun installed 125 packages that occupied 103 MB, and the build completed in 22 seconds. Tests then failed in 8 seconds with 0 passing and 111 failing out of 111. Every test file reported an error because the setup attempted to launch cargo and the executable was not in PATH. The log establishes the missing executable and nothing more.
That failure is useful setup evidence. The README presents the CLI as one part of a system whose backend is written in Rust. A fresh Node 22 image was enough to install and build the measured CLI, but it was not enough to execute its test setup. Contributors should follow the repository's multi-language development instructions instead of assuming the CLI directory is isolated from Rust tooling.
Self-hosting starts with Postgres and workers
The README suggests roughly 1 worker per 1 vCPU and 1 to 2 GB of RAM for hosting. Its shortest server path downloads a Compose file, a Caddy configuration, and an environment file, then starts the stack. Windmill stores its queue and application state in Postgres. Stateless API servers and workers pull jobs from that queue, while optional nsjail and PID namespaces isolate execution.
Production work begins after that first login. Teams need database backups, worker capacity, a public base URL, TLS, secret governance, and credentials for enabled integrations. The README suggests roughly 1 worker per 1 vCPU and 1 to 2 GB of RAM as a hosting rule. Runtime images must also contain the languages used by actual jobs. A Python-only automation shop has a simpler worker estate than one accepting every advertised runtime.
Sync and scheduling deserve preproduction tests
All 111 CLI test files failed in our container, and deployment semantics need their own checks too. Windmill supports local files, a CLI, a VS Code extension, and Git synchronization. Issue 10842 says wmill sync push archived missing scripts while hard-deleting missing variables and resources. The reporter found the dangerous object types included by default and confirmed that skip flags protected them. Use dry runs and treat every deletion line as a deployment decision.
Scheduling also has semantics worth testing with real job durations. Issue 10844 describes a 20-second schedule running a 50-second job, with starts effectively landing 60 seconds apart while the original expression remained displayed. The report does not describe overlapping work or duplicate processing. It describes silent cadence drift, which can matter for polling, billing, and service-level expectations. Monitor actual starts and completions instead of inferring run counts from cron text.
The project is active, and the license needs reading
Release v1.796.0 was published on August 24, 2026, two days before GitHub recorded another push. Its notes cover AI evaluation data, token-cost tracking, database migration handling, and several fixes. The repository showed 830 open issues and pull requests combined. Fresh code and same-week reports show an active project, though the queue is large enough that buyers should search for their exact trigger and deployment model.
Windmill's source build is under AGPLv3, while the README describes separate terms for the distributed Community Edition and commercial use. Internal use is explicitly allowed. Redistribution, selling a managed service, wrapping Windmill, or exposing parts directly to customers can require AGPL compliance or an agreement with Windmill Labs. For an internal engineering platform, the feature mix is convincing. For an embedded product feature, license review belongs before implementation.