Windmill vs Power Automate
Eight questions teams ask during a bake-off, with an honest answer on each one for where Windmill or Power Automate is the better pick.
- 01What you can buildWhich solution fits for your specific use case
- 02TargetWho the platform is built for
- 03Build experienceHow you build on each platform
- 04IntegrationsHow the platform integrates with your existing stack
- 05Migration & lock-inHow hard to get in, how hard to get out
- 06Enterprise requirementsAudit logs, observability, security, limits
- 07Licensing & pricingOpen source, pricing, self-hosting
- 08VerdictThe verdict
Windmill in one sentenceAn open-source workflow engine and developer platform to build and orchestrate all your internal software: scripts, workflows, data pipelines, AI agents and internal apps. Made for engineers who want full code flexibility and local dev experience, both to build internal software and to manage the underlying infrastructure.
Power Automate in one sentenceMicrosoft's automation service inside the Power Platform, built so that an intuitive interface and many connectors let people create workflows with little to no knowledge of coding. It offers three types of flows: cloud flows for API-driven automation, desktop flows for robotic process automation against application UIs, and generative actions in preview. It runs in Microsoft's cloud and is licensed per user and per bot.
Which internal software can you build and orchestrate?
Windmill is built to centralize and orchestrate all your internal software in one place. Scripts, workflows, data pipelines, full-code apps, AI agents and operator UIs run on a single runtime, with shared resources, auth and observability. Power Automate covers two shapes of automation very well: API-driven cloud flows across the Microsoft 365 surface, and UI-level RPA through desktop flows, which is the one category Windmill does not cover at all.
| Primitive | Windmill | Power Automate |
|---|---|---|
Chain steps with branching, retries and error handlers | ||
Recurring jobs with retries, error handling and alerting | ||
Pause a run until a human approves, with a form and a resume link | ||
Recorded UI automation Record clicks and keystrokes against desktop, legacy and browser UIs, including by image | ||
Standalone functions exposed as APIs, webhooks or cron jobs without a wrapping workflow | ||
ETL, syncs and scheduled data jobs with parallel branches and a managed lakehouse | Partial | |
Agents that call your own code as tools and branch on model output | Preview | |
Isolated environments with persistent volumes for running agents | ||
Admin tools and dashboards over the same scripts, resources and permissions | Power Apps |
Power Automate approvals are a standard-connector action with several approval types, and they require a Microsoft Dataverse database; approvers respond from an Outlook email, a Teams adaptive card or the action center. Apps are Power Apps, a separate product in the Power Platform for building cross-platform business apps with minimal code; a Power Automate license gives rights to create and manage flows in Power Apps, not to build the apps themselves. Generative actions, where you specify only the intent and AI chooses the actions, are listed as preview.
On the Windmill side, running jobs natively on Windows hosts (PowerShell, C# and MSSQL with Kerberos, no Docker and no WSL) requires a Self-Hosted Enterprise license Enterprise only. See Windows automation for what that covers.
Who is each platform built for?
Power Automate is designed for people who should not have to write code, and it is good at that: a template, a designer or a Copilot prompt gets a working flow quickly. Windmill is designed for engineers who want automation to behave like the rest of their codebase, which is also what makes AI-written automation practical to review.
WindmillPower AutomatePrimary audience
WindmillDeveloper-led teams. Engineers own the platform end-to-end: code, Git, local dev, workspace forks, code review, CI/CD, AI coding tools, infrastructure as code. Operations, support and finance teams are consumers of what engineers ship.
Power AutomateBusiness users and makers inside a Microsoft tenant. Microsoft's own framing is that the interface and connectors "allow you to create workflows with little to no knowledge of coding", and desktop flows are described as being "for everyone who performs simple or complex rule-based tasks on their workstations", from home users to large enterprises. A Free license is included for work or school accounts in a Microsoft Entra tenant, so adoption usually starts without a purchase.
Reviewing and editing automations
WindmillEvery script, flow, app, resource and permission is a file. Review is a pull request diff, with the same tooling the team already uses for application code. Non-developers run and monitor through auto-generated UIs and run-only roles, and can assemble existing scripts in the flow editor, but writing a new step means writing code.
Power AutomateReading a flow means opening it in the designer. The underlying definition is Workflow Definition Language, but it is not the authoring surface: a flow exports as a .zip package, and Microsoft directs lifecycle management to Dataverse solutions instead. Reviewing what changed between two versions of a flow is a platform feature, not a diff in your repository.
Where AI changes the calculation
WindmillAgents that write automation produce source files: a script in a branch, a flow in YAML, a pull request a human reads. The reviewable artifact and the executable artifact are the same thing, which matters more as the volume of generated automation grows.
Power AutomateCopilot generates flows from a natural-language prompt, and in Power Automate for desktop a preview feature generates the body of a scripting action from a description. The output lands in the designer or in an action parameter, so the review step is a person clicking through the generated flow rather than reading a diff.
How do you build on each platform?
Windmill gives you full code flexibility with a local dev loop and whole-workspace Git sync, including PowerShell and C# running natively on domain-joined Windows hosts. Power Automate puts a designer first: code is available inside desktop-flow scripting actions, and Git sits beside the platform through Dataverse solutions rather than under it.
WindmillThe PowerShell script is a normal script with a param block. Windmill reads that block to generate the input form and the JSON schema, and the script runs on its own from a URL, a schedule or a webhook. The flow file references it by path, maps arguments onto it and adds the approval step. Both files sit in Git and are editable in any editor.
- disable_user.ps1
- flow.yaml
# f/windows/disable_user.ps1
param(
[string]$samAccountName,
[string]$reason = "offboarding"
)
Import-Module ActiveDirectory
Disable-ADAccount -Identity $samAccountName
Set-ADUser -Identity $samAccountName -Description "Disabled: $reason"
Get-ADUser -Identity $samAccountName -Properties Enabled, Description |
Select-Object SamAccountName, Enabled, Description |
ConvertTo-Json
summary: Offboard a user
value:
modules:
- id: a
summary: Disable the AD account
value:
type: script
path: f/windows/disable_user
input_transforms:
samAccountName:
type: javascript
expr: flow_input.sam_account_name
reason:
type: static
value: offboarding
- id: b
summary: Confirm in Teams before archiving the mailbox
suspend:
required_events: 1
timeout: 86400
value:
type: script
path: f/windows/archive_mailbox
input_transforms:
account:
type: javascript
expr: results.a.SamAccountName
Logic lives in the designer. Anything the form cannot express goes into a Workflow Definition Language expression typed into a field, capped at 8,192 characters. Real code is possible in a desktop flow through the scripting actions, where the script body is a text parameter of the action and results come back through Write-Output as a single text value.
- Condition (advanced mode)
- Run PowerShell script action
@and(greater(item()?['Due'], item()?['Paid']), less(item()?['dueDate'], addDays(utcNow(),1)))
$variableName = "variableValue"
Write-Output $variableName
Authoring
WindmillBuild scripts in 20+ languages in a dedicated script editor. Windmill parses the function signature to auto-generate the input UI, JSON schema and argument types. Dependencies resolve automatically with a per-script lockfile. Arguments pass between flow steps as direct return values, and any public or private package is a first-class import.
Power AutomateCloud flows are built in a designer, from scratch, from a template or from a Copilot prompt, by picking a trigger and chaining connector actions configured through forms. Expressions fill the gaps the forms leave. Desktop flows are built in the Power Automate for desktop designer from prebuilt drag-and-drop actions, or recorded.
Writing real code
WindmillCode is the default, not the escape hatch. TypeScript (Bun, Deno, Node.js), Python, Go, Bash, SQL, PowerShell, C#, PHP, Rust, Java, Ruby, R and more, each with automatic dependency resolution. A step can be a 200-line module with its own imports, tests and types.
Power AutomateDesktop flows have scripting actions for PowerShell, Python, VBScript, JavaScript and .NET (C# v5.0 or VB.NET v11.0). The script is a text parameter of the action, Power Automate variables are interpolated with % notation before the script runs, and output comes back as a text value. Worth knowing: the Run Python script action offers Python 2.7 or Python 3.4, with 2.7 as the default, and the PowerShell, JavaScript and VBScript actions default to a 10-second timeout. VBScript is deprecated in Windows.
Windows execution
WindmillWorkers install as a native Windows service with sc.exe or NSSM and run PowerShell, C# and SQL directly on domain-joined hosts, so Active Directory, Kerberos, the certificate store and private Azure Artifacts feeds keep working. One instance mixes Windows and Linux workers and routes each step by tag. See Windows workers. Native Windows workers are Enterprise only.
Power AutomateDesktop flows run on a registered machine through a bot. An attended bot runs on the machine the person is already using; an unattended bot "securely signs into the machine on user's behalf, executes the desktop flow actions on the target applications, and then signs out of the device". Attended RPA comes with the Premium user license Premium; unattended RPA needs a Process license allocated to a machine Process, and one bot runs one desktop flow at a time.
Local dev & IDE
WindmillRun scripts locally with the Windmill CLI, with a VS Code extension, native language tooling (LSP, type-checking, linting) and AI coding tools working against the real source files.
Power AutomateThe Power Platform CLI covers environment lifecycle, authentication, Dataverse and solution packages, and installs on Windows, Linux and macOS. It is a deployment and packaging tool: authoring and running a flow still happen in the service.
Resources & secrets
WindmillResources (typed JSON for credentials, connection info, configs) and variables (individual secrets) are first-class and reusable across scripts, flows and apps, encrypted at rest, scoped by folders and groups, and versioned in Git. External secret backends (Vault, AWS Secrets Manager) are Enterprise only.
Power AutomateCredentials live in connections, created per user and per connector and reused across flows. Desktop flows add secret variables and a CyberArk action group. On-premises systems are reached through the on-premises data gateway, which "acts as a bridge" between on-premises data and the cloud services.
Git & CI
WindmillFull infrastructure as code: scripts, flows, apps, resources, variables, secrets, schedules, folders, groups and permissions are all files in Git, deployed via the CLI and Git sync. Internal tooling ships like application code: PRs, reviews, rollbacks, CI/CD. Git sync is free for up to 2 users; beyond that is Enterprise only.
Power AutomateDataverse Git integration syncs unmanaged solutions to Azure DevOps or GitHub, with Microsoft's guidance to "use Git integration with developer environments, not in your test or production environments". Promotion to test and production happens through managed solutions and pipelines, and Dataverse "stores all the artifacts". Source control is one view of the solution rather than the thing the runtime reads.
How does the platform integrate with your existing stack?
Power Automate wins on breadth of ready-made connections, especially across Microsoft 365, where a trigger and an action are configuration rather than code. Windmill treats the package ecosystems as the catalog: you import the vendor's own SDK, so the integration surface is whatever npm, PyPI, NuGet or Maven ships, and a new one is a script rather than a connector project.
WindmillPower AutomateConnecting out
WindmillAny npm, PyPI, Go, NuGet or Maven package is a first-class import with automatic per-script dependency resolution and lockfiles, and no plugin layer in between: you call the vendor's real SDK with full type inference in the editor. 50+ pre-built resource types cover databases (Postgres, Snowflake, BigQuery, MSSQL), SaaS (Slack, Teams, Stripe, GitHub, OpenAI) and infrastructure (S3, Azure Blob, Redis, Kafka): paste credentials into a typed form and the resource is shared across scripts, flows and apps.
Power AutomateA large catalog of prebuilt connectors, each exposing triggers and actions for a service, split into standard and premium tiers plus custom connectors you build yourself. Coverage of the Microsoft 365 and Dynamics 365 surface is the deepest of any automation platform, and that is the main reason teams pick it. Premium and custom connectors need the matching license entitlement Premium.
Receiving events
WindmillNative triggers for HTTP, cron, Kafka, NATS, Postgres CDC, SQS, MQTT, SMTP and WebSocket. Each one is a typed primitive in the UI, and Windmill handles the connection, replay and consumer-group state. Every script also gets an HTTP endpoint and a webhook URL for free, so most receive paths need no glue code.
Power AutomateCloud flows come in three shapes: automated (triggered by an event such as the arrival of an email), instant (started by a button) and scheduled. The trigger is whatever the connector exposes, which is how a new SharePoint list item or an Outlook mail becomes a run with no code. Desktop flows add their own triggers and can be started from a cloud flow.
Extending
WindmillA new integration is a script with a new import: save and run, no restart and no image rebuild. The loop is hot-reload through the web editor, the CLI and Git sync. Custom logic can be exposed as a typed script, packaged as a resource type, or published to the private workspace Hub for the team.
Power AutomateThree routes. Build a custom connector, described as a function-based connector "you build to support your tailored scenarios", when a service has an API but no prebuilt connector. Drop into a scripting action for one-off logic. Or, for desktop flows, add a custom actions module. Desktop flows also have action groups for Active Directory, Azure, AWS, Exchange Server, SAP, terminal emulation and Windows services, which is a lot of ground covered without writing anything.
How hard to get in, and how hard to get out?
Power Automate is the quicker on-ramp, particularly for Microsoft 365 work and for automating an application that exposes no API at all. Windmill keeps the switching cost low at the other end: the step code is ordinary code in ordinary files, so it keeps running wherever you take it.
WindmillPower AutomateGetting in
WindmillPaste a function body into the script editor: Windmill infers the arguments, generates a UI and resolves dependencies. Existing PowerShell runbooks and Python jobs usually run with a small change to the parameter block. Triggers, schedules, variables and apps migrate one by one.
Power AutomateThe fastest start of the two if your systems are Microsoft ones. Pick a template, describe the flow to Copilot, or record a desktop task. The recorder is explicitly positioned as a starting point: Microsoft notes that conditionals and loops cannot be recorded and that most recorded tasks should be modified afterwards.
Getting out
WindmillStep logic is already standard code (PowerShell, TypeScript, Python, Go, C#, Bash, SQL) that runs anywhere, and the CLI exports the whole workspace as plain files. What you lose when leaving Windmill is the runtime, not the step code.
Power AutomateA single cloud flow exports as a .zip flow package, and sets of flows move through Dataverse solutions. What transfers is the shape of the automation, not something another platform can run: connector actions become API or SDK calls you write yourself, Workflow Definition Language expressions become code, approvals depend on Dataverse, and desktop flows built on UI selectors, images or coordinates have no equivalent off the platform.
Audit logs, observability, security, limits
Power Automate inherits Microsoft tenant identity, compliance and central administration, which is hard to match if your organization already lives there. Windmill runs on your own infrastructure, so retention, isolation and throughput are yours to set: no per-action day quotas, no 30-day cap on run history, and no flow switched off for being too busy.
WindmillPower AutomateObservability
WindmillReal-time streaming logs, per-run inputs, outputs and duration, worker queue metrics and a Prometheus exporter. A trace ID on every job, and job retention you configure on your own database.
Power AutomatePer-run history in the portal with the inputs and outputs of each action. Run retention in storage is 30 days, calculated from a run's start time, so longer-lived history has to be exported somewhere else.
Audit logs
WindmillA full trail of who ran, edited and deployed what, in your own instance. Extended retention is Enterprise only.
Power AutomatePower Automate activity (flow creations, permissions, runs, failures and connector calls) is surfaced through Power Platform activity logging in Microsoft Purview. Getting there takes a few moving parts: the option to turn on audit logging "is only visible when the minimum Office licensing requirements are met", Purview captures user activity logs for production environments only, and viewers need the Audit Logs or View-Only Audit Logs role Purview.
Security
WindmillSOC 2 Type II compliant. RBAC, SSO (up to 10 users), encrypted secrets at rest and sandboxed script execution in open source. Uncapped SSO, audit logs and advanced access controls (SCIM, SAML) are Enterprise only.
Power AutomateIdentity, conditional access and compliance come from the Microsoft tenant, which is a real advantage if you already run Entra ID: the automation platform inherits the controls you have already configured. Governance is administered centrally in the Power Platform admin center rather than per project.
Isolation & multi-tenancy
WindmillMultiple isolated workspaces on the same instance, each with their own users, resources, secrets and access controls. The free tier is capped at 3 workspaces; unlimited is Enterprise only.
Power AutomatePower Platform environments are the isolation boundary, and environments that take part in lifecycle management must include a Dataverse database. Each Premium license carries 250 MB of Dataverse database and 2 GB of file storage, pooled at tenant level; Process and Hosted Process licenses carry 50 MB and 200 MB.
Limits & throughput
WindmillAround 10ms cold starts, and throughput is a function of how many workers you run. Dedicated-worker mode Enterprise only keeps runtimes and dependencies pre-warmed. There is no per-action quota: the ceiling is your own hardware, and published benchmarks cover the comparable orchestrators.
Power AutomateThe documented cloud-flow limits are worth reading before committing a high-volume workload: 500 actions per workflow, 8 levels of action nesting, 250 variables per workflow, 8,192 characters per expression, a 30-day maximum run duration and 30-day run retention. Action quotas are per license: 40k actions per day for a Premium user license, 250k per Process license. A flow that stays above the throttling limits for 14 days is turned off, as is one with continuously failing actions, and a flow with no trigger activity for 90 days may be turned off unless its owner holds a premium or capacity license.
Open source, pricing, and self-hosting?
Windmill's core is AGPLv3 and free to self-host with no action quotas, and its paid pricing is published per seat and per compute unit. Power Automate publishes list prices too, but the model is per user and per bot with separate entitlements for premium connectors, attended RPA, unattended RPA and process mining, so the real cost depends on which entitlements each person and each automation needs.
WindmillPower AutomateOpen source & self-hosting
WindmillAGPLv3 core, free and unlimited to self-host, with no cap on runs or actions. Enterprise features (SSO beyond 10 users, dedicated workers, native Windows workers, audit log retention, external secret backends) ship in a separate proprietary codebase. Managed cloud is available but optional: the same build runs in your own VPC or data center.
Power AutomateProprietary and cloud-hosted. There is no self-hosted Power Automate: flows run in Microsoft's service, desktop flows run on machines you register with it, and on-premises systems are reached through the on-premises data gateway. The code is not available.
Pricing
WindmillThe free Community Edition is unlimited for self-hosting. Paid plans are priced per seat and per compute unit, published with a calculator on the pricing page, so you can size a deployment without talking to anyone.
Power AutomateList prices are published, and the structure is the thing to read carefully rather than any single number. Microsoft lists Power Automate Premium at "$15.00" per "user/month, paid yearly" for cloud flows plus "Desktop flows (RPA) in attended mode"; Power Automate Process at "$150.00" per "bot/month, paid yearly" for unattended mode; Power Automate Hosted Process at "$215.00" per "bot/month, paid yearly"; and a Process Mining add-on at "$5,000.00" per "tenant/month, paid yearly". Microsoft adds that "Prices shown are for marketing purposes only". Unattended parallelism is bought in bots: "Assigned to a machine, a bot can execute one unattended desktop flow run at a time. Multiple bots are required to execute concurrent desktop flow runs on a machine."
What the free tier gets you
WindmillEverything in the AGPLv3 core, self-hosted, with no run limits: scripts, flows, apps, agents, triggers, RBAC, SSO for up to 10 users and Git sync for up to 2 users. Capped at 3 workspaces.
Power AutomateThe Power Automate Free license, included for work or school accounts in a Microsoft Entra tenant, covers "creating and running cloud flows (without sharing), as well as authoring and running desktop flows locally (attended)", with "standard connectors only". Sharing a flow, premium connectors and unattended runs all need a paid license.
The verdict
These two tools answer different questions. Power Automate asks how someone can automate a task without writing code, and answers it with a designer, a connector catalog, a Copilot prompt and, for applications that expose no API at all, a recorder that drives the UI. Windmill asks how a team can run all of its internal software as code it owns, and answers it with scripts, flows, apps and agents on one self-hostable runtime.
Power Automate is the better pick if your automation is mostly Microsoft 365, the people building it are not developers, or the work involves clicking through a legacy or vendor application that has no API. Windmill has no answer to desktop-flow RPA: no recorder, no UI element picker, no image or OCR based clicking. Scripted browser automation with Playwright or Puppeteer covers web work, and nothing covers a terminal emulator or a thick-client ERP screen.
Windmill is the better pick if engineers own the automation. The step logic is real code in real files: PowerShell and C# running natively on domain-joined Windows hosts without Docker or WSL, Python and TypeScript next to them on the same instance, all of it in Git with PRs, reviews and rollbacks. The scope is wider than workflows, since the same runtime carries data pipelines, AI agents and internal apps with shared auth, secrets and observability. It self-hosts on an AGPLv3 core with no per-action day quotas and no 30-day cap on run history, and the paid pricing is published per seat and per compute unit.
One trend is worth naming without overstating it. As more automation gets drafted by AI rather than typed by hand, the review step becomes the bottleneck, and a diff is easier to review than a generated flow in a designer. That does not make low-code wrong, but it does shift where code-first pays off.
Plenty of teams run both: Power Automate for the Microsoft 365 and RPA edges, Windmill for the automation that engineers own and that has to be reviewed, versioned and self-hosted. If you are deciding between the two, the fastest way to judge is to spend an afternoon in each.
Frequently asked questions
Build your internal platform on Windmill
Scripts, flows, apps, and infrastructure in one place.