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. If the people building automations do not code and want the smoothest canvas, Make wins. If they write code and want to own the runtime, Windmill is the more powerful and cheaper platform.

Visual canvas vs code-first

Make’s strength is the canvas. Scenarios are drawn as a flowchart with modules connected by visible data paths, and the editor is the most polished in the category — modules animate as they run, errors light up on the exact bubble that failed, and the data inspector on each connection lets you scrub through historical runs. Routers, iterators, and aggregators give branching and array handling without a line of code, and the model holds up well at thirty or forty modules.

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 ships around 1,800 native apps, leaning into mainstream business SaaS — Slack, Google Workspace, Microsoft 365, HubSpot, Salesforce, Shopify, Notion, Airtable — and most modules expose more endpoints per app than simple one-trigger-one-action integrations. The HTTP module and a Custom Apps SDK cover anything outside the catalog, so for a no-code user the coverage is broad and ready to click.

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 prices by operation — one module firing inside a scenario is one operation — so a ten-module scenario running once burns ten operations. The Core plan begins around $9 a month for 10,000 operations, and the included-operations volume is generous for small scenarios, but multi-step scenarios consume the meter linearly with the number of modules that fire.

Windmill is open source and self-hostable, so the runtime layer is effectively free — you pay for the infrastructure you run it on. Windmill Cloud and enterprise tiers are priced around compute and workers rather than per operation, so cost does not scale linearly with how many steps a workflow has. For high-volume, multi-step workloads run by a team that can operate a server, Windmill is dramatically cheaper; the cost you take on instead is backups, upgrades, and on-call.

Self-hosting and ownership

This is the cleanest structural split. Windmill ships as an open-source platform with a Docker Compose stack and a Helm chart; the core is AGPL, workers scale horizontally, and Postgres is the backing store. Scripts and flows are plain code that lives in version control and can be synced from a Git repository, so the whole automation layer runs in your own jurisdiction and stays portable. For teams with data-residency, air-gap, or vendor-independence requirements, this is decisive.

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 performance is whatever its cloud tier provides, which is more than enough for the business-SaaS automation it targets, but the per-operation ceiling and cloud-only execution mean you cannot tune the runtime the way you can with self-hosted Windmill workers. The filter is familiar: Make optimises the building experience for non-coders, Windmill optimises the runtime and extensibility for engineers.

Who should choose Make

Make is the right call for teams who want the cleanest visual canvas in the category, run mostly business-SaaS automation, and would rather not think about infrastructure. The included-operations volume on the Core plan is generous for small workflows, the scenario editor is the easiest place to debug a branching flow, and there is no Dockerfile, no Postgres to back up, and no Redis to monitor. For an operations-led team that needs automations built by non-engineers, Make is the faster and friendlier home.

Who should choose Windmill

Windmill is the right call for engineering teams who want scripts as workflows, self-hosting, and open-source economics. If your automations are naturally expressed as functions, if you want auto-generated internal tools on top of them, and if predictable compute-based cost beats per-operation billing at your volume, Windmill is the more powerful and cheaper platform. Version-controlled scripts, AGPL self-hosting, and portable code make lock-in low. The cost is that you own the deployment and its upkeep, and non-coders cannot build on it unsupervised.