Windmill vs Azure Automation

Azure Automation is, in Microsoft's words, "a cloud-based automation service that helps you automate processes and supports consistent management across Azure and non-Azure environments". Its process automation runs PowerShell, Python and graphical runbooks, in Azure or on machines you register as Hybrid Runbook Workers. Windmill is an open-source platform for scripts, workflows and internal apps that you self-host, for example on AKS, or use on Windmill Cloud.

This page is written by Windmill. Statements about Azure Automation come from Microsoft's documentation and link to it. Feel free to contact us for any correction.

Who each tool is for

Azure Automation is for teams that run Azure and want runbooks as a managed Azure resource. Runbooks can authenticate with the Automation account's managed identity, which Microsoft calls "the recommended way to authenticate in your runbooks", and Azure alerts can start them through action groups.

Windmill is for teams whose automation spans Azure, other clouds and on-premises systems, in more than one language, and who want workflows, approvals and user-facing apps on the same platform. It runs where you deploy it, and its workers run wherever you start them.

Comparison

	Azure Automation	Windmill
Hosting	Cloud-based Azure service.	Self-hosted with Docker Compose or Kubernetes, including AKS with Azure Database for PostgreSQL, or Windmill Cloud.
Languages	PowerShell 7.6, 7.4 and 5.1; Python 3.10; graphical runbooks, which are created and edited only in the Azure portal.	TypeScript, Python, Go, PHP, Bash, PowerShell, Nu, C#, SQL, Java, Ruby, R, Rust and more.
Where jobs run	In an Azure sandbox, or on Hybrid Runbook Workers (Windows and Linux) for on-premises and other-cloud resources.	On Windmill workers that you deploy: Linux workers, native Windows workers (Self-Hosted Enterprise), and agent workers (Enterprise) that connect over HTTP from remote networks.
Long-running jobs	In Azure sandboxes, fair share stops or unloads any job that has run for more than three hours. Hybrid Runbook Workers are not limited by fair share.	Self-hosted: jobs run for up to 7 days by default (the worker `TIMEOUT`), and the default job timeout and custom timeouts per flow step are capped by it. On Windmill Cloud, a job runs for at most 15 minutes in a free workspace and 90 minutes in a paid workspace, by default.
Schedules	Hourly, daily, weekly or monthly recurrences, with time zones and Daylight Saving Time handling. A schedule runs at most once an hour.	CRON schedules with error and recovery handlers.
Webhooks	A webhook starts a runbook through a single HTTP request; starting a Python runbook through a webhook is not supported, and with PowerShell 7 runbooks the webhook input is converted to invalid JSON, so Microsoft recommends PowerShell 5 runbooks for webhooks.	Every script and flow gets webhooks, whatever its language.
Azure events	Azure alert action groups can start a runbook.	Azure Event Grid triggers, a self-hosted Enterprise feature.
Multi-step workflows	Child runbooks; PowerShell Workflow runbooks, which PowerShell 7 does not support.	Flows with branches, for loops, retries, error handlers and approval steps, mixing languages.
Source control	One-way sync from GitHub or Azure DevOps (Git or TFVC) into the Automation account, supported for PowerShell 5.1 runbooks only.	Git sync commits each deployment to the repository; deploying commits back into the workspace is Enterprise Edition. Azure DevOps through an Entra service principal.
Secrets and identity	Credentials, certificates, variables and connections stored in the Automation account; managed identities.	Variables and secrets and resources; Azure Key Vault as the secret backend on Enterprise Edition; Azure workload identity for Azure SQL from AKS workers.
Job history	Job logs are stored for a maximum of 30 days.	60 days on Cloud Free and Team; 30 days maximum on self-hosted Community Edition; unlimited on Enterprise (Cloud and self-hosted), with a configurable retention period.
Pricing	Process automation is billed per minute of job run time, with 500 minutes a month included free per subscription (Azure Automation pricing).	Community Edition is free to self-host. Paid plans are priced by seats and compute units (pricing).

Where Azure Automation is the better choice

Nothing to operate. Microsoft recommends the Azure sandbox to minimize operational costs: "There's no compute overhead and no need for a VM." Self-hosted Windmill is a server, workers and a PostgreSQL database that you run.
Azure-native identity and alerts. Runbooks can use the Automation account's managed identity, and Azure alert action groups can start them directly.
Runbooks that manage Azure resources. For integrating with Azure resources, Microsoft recommends the Azure sandbox: "Hosted in Azure, authentication is simpler." Runbooks in the sandbox cannot call executables or subprocesses; Microsoft points to Hybrid Runbook Workers for that.
Windows PowerShell 5.1 and graphical runbooks. Azure Automation supports PowerShell 5.1 runbooks and a graphical editor in the Azure portal. Windmill's Windows worker setup uses PowerShell 7 (pwsh.exe).

Where Windmill is the better choice

Jobs longer than three hours without a separate worker type, on a self-hosted instance. Jobs run on your workers for up to 7 days by default, and the timeout is configurable. This does not apply to Windmill Cloud, where a job runs for at most 15 minutes in a free workspace and 90 minutes in a paid workspace, by default.
More than PowerShell and Python. Steps in TypeScript, SQL, C#, Bash or other languages sit in the same flow, with dependencies resolved from imports.
People in the loop. Approval steps pause a flow until someone approves. Auto-generated UIs and full-code apps in React or Svelte let colleagues run a job with their own inputs, and the Operator role is for people who run but do not author.
Git for everything in the workspace. Git sync can include scripts in any language, flows, apps, resources, schedules and triggers, not only one runbook type.
Portable across environments. The same Windmill instance can run workers on Azure, other clouds and on-premises machines, including Windows machines, and worker tags decide which jobs run where.

Using them together

Start a runbook from Windmill. An Azure Automation webhook starts a runbook "through a single HTTP request", so a Windmill flow can call it as one step, for example after an approval step.
Start Windmill from a runbook. Each Windmill script and flow has webhooks, so a runbook can start a Windmill flow with an HTTP request.
Run Windmill on Azure. Deploy Windmill on AKS with Azure Database for PostgreSQL, sign users in with Microsoft Entra ID, store secrets in Azure Key Vault (Enterprise) and connect to Azure SQL with workload identity.