Make vs Windmill

The core difference

Make and Windmill automate workflows from opposite ends of the spectrum. Make treats a workflow as a visual scenario: modules connected on a flowchart canvas, configured through dropdowns and field mappers, running in Make’s cloud. The whole product optimises for a non-technical operator who wants to see the data flow as bubbles and never touch code.

Windmill treats a script as the unit of work: you write a function in TypeScript, Python, Go, or Bash, and Windmill turns it into a runnable step, auto-generates an input form from its parameters, and lets you chain steps into flows. It is closer to a self-hostable developer platform — part job runner, part internal-tools builder — than to a no-code connector tool.

That difference decides most comparisons. Make better fits non-coders who want a managed visual canvas; Windmill better fits engineers who want scripts and runtime ownership. Cost still depends on the current plans, workload trace, infrastructure, and operator labour.

Visual canvas vs code-first

Make’s strength is the canvas. Scenarios are drawn as a flowchart with modules connected by visible data paths; modules animate as they run, errors appear on the module that failed, and the data inspector on each connection exposes historical runs. Routers, iterators, and aggregators provide branching and array handling without a line of code.

Windmill is code-first by design. Every step can be a full script with dependencies, and the platform handles secrets, scheduling, retries, parallelism, and an auto-generated UI on top. For an engineer this removes the ceiling no-code hits the moment a workflow needs a transform the built-in modules do not support — there is no escape hatch to reach for because code is the default surface. The trade is that a non-coder cannot build on Windmill unsupervised the way they can on Make.

Integrations

Make listed 3,000+ apps when verified 2026-09-20. Its HTTP module and Custom Apps SDK can cover gaps, though those paths add implementation work. Verify connector depth for the actual workflow rather than relying on the directory total.

Windmill does not compete on a pre-built connector count. Instead, any API is reachable because any step is code: an HTTP call plus a few lines in your language of choice hits any REST endpoint, and Windmill Hub hosts shareable scripts and flows the community has already written. For an engineer this is often faster than hunting for a module; for a non-coder it is a wall. The read: Make for breadth of ready-made modules, Windmill when you would rather write the integration than wait for one.

Pricing

The meters differ. Make bills in credits, and most non-AI module operations consume one credit while some AI and advanced features use different rules. Compare current quotes and run a representative scenario because bundles, retries, and AI usage affect the total.

Windmill is open source and self-hostable, so a self-hosted deployment replaces a workflow subscription with infrastructure and operating costs. Windmill Cloud and enterprise pricing use different meters from Make credits. Compare current quotes with a representative workload and include backups, upgrades, monitoring, support, and on-call labour.

Self-hosting and ownership

Windmill ships an open-source platform with Docker Compose and Helm deployment paths, horizontally scalable workers, and Postgres. Scripts and flows can live in version control. Self-hosting gives more control over runtime and storage location, while actual data flow still depends on connectors, telemetry, backups, and external services.

Make has no self-hosted edition. There is no community release, no on-prem enterprise package, and no public roadmap commitment to add one. Every scenario run goes through Make’s cloud, which is fine for the majority of workloads and a hard stop for teams that need data residency in a specific jurisdiction or an air-gapped environment. The upside of the same decision is zero operations: Make owns the runtime, secrets, retries, and alerting.

Internal UIs and performance

Windmill doubles as an internal-tools builder. Because every script has typed inputs, Windmill can auto-generate a form or a full app UI on top of a workflow, so a script becomes a button-and-form tool your team can run without touching code. Combined with fast parallel workers and low per-run overhead, it fits teams that want both automation and lightweight internal apps on one self-hosted platform — something Make does not attempt.

Make’s managed cloud abstracts the runtime, while self-hosted Windmill workers expose more infrastructure control. The filter is familiar: Make optimises the building experience for non-coders, while Windmill optimises runtime control and extensibility for engineers.

Who should choose Make

Make is a fit for teams that want a managed visual canvas, run mostly business-SaaS automation, and would rather not operate infrastructure. Current plans use credits, with consumption depending on the module and feature; test a representative scenario before comparing cost. For an operations-led team that needs automations built by non-engineers, its visual editor may reduce the implementation burden.

Who should choose Windmill

Windmill is a fit for engineering teams that want scripts as workflows, self-hosting, and an open-source core. If your automations are naturally expressed as functions or need generated internal tools, its authoring model and runtime ownership are meaningful advantages. Compare its deployment and compute costs with Make credits using a representative workload; the trade is that self-hosting adds upkeep and non-coders may need engineering support.