Windmill vs Ansible Automation Platform
Windmill is not an alternative to Ansible: it runs your playbooks. The comparison is with the layer above them. Eight questions teams ask during a bake-off, with an honest answer on each one.
- 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, performance
- 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, with Ansible as one of its native script languages. Made for engineers who want full code flexibility and a local dev experience, both to build internal software and to manage the underlying infrastructure.
Ansible Automation Platform in one sentenceRed Hat's commercial platform for running Ansible at enterprise scale: automation controller (formerly Ansible Tower) as the control plane for job templates, inventories, credentials, RBAC and scheduling, plus certified Content Collections, automation hub, Event-Driven Ansible, automation mesh and an automation coding assistant. Sold as a Red Hat subscription with Standard or Premium support.
Which internal software can you build and orchestrate?
Ansible Automation Platform is built around one execution model: a playbook, run against an inventory by a job template, with workflows and Event-Driven Ansible on top. Windmill runs the same playbooks and adds the rest of the internal software around them on one runtime: scripts in other languages, flows with approval steps, data pipelines, AI agents, low-code and full-code apps, with shared resources, auth and observability.
| Primitive | Windmill | AAP |
|---|---|---|
Run a playbook with inventories, Galaxy collections, vault files and typed inputs | ||
Python, TypeScript, Go, Bash, PowerShell and SQL with their own inputs, API endpoint and schedule | Inside playbooks | |
Chain playbooks and scripts, pause for an approver, retry what is safe to retry | ||
Cron jobs with retries, error handling and alerting | ||
Start automation from HTTP, Kafka, NATS, SQS, MQTT, AMQP, Postgres or email | ||
A request form built from the declared inputs, with enums, defaults and patterns | ||
ETL, syncs and scheduled data jobs with parallel branches | ||
Agents that call tools, branch on outputs and run as workflows | ||
Drag-and-drop dashboards and admin tools with built-in components | ||
Custom dashboards and admin tools built in React or Svelte | ||
Vendor-supported certified content Collections built, supported and maintained by a vendor and its partners | Community Hub |
Who is each platform built for?
Ansible Automation Platform is built for teams whose automation is Ansible, and it is deep in that ecosystem. Windmill is built for developer-led teams whose automation is Ansible plus a lot of other code, and who want one platform for all of it.
WindmillAnsible Automation PlatformPrimary audience
WindmillDeveloper-led infrastructure and platform teams. Engineers own the platform end-to-end: code, Git, local dev, code review, CI/CD, AI coding tools, infrastructure as code. Ansible is one language among the twenty the same workers run.
Ansible Automation PlatformAnsible-centric operations teams, often in Red Hat shops. Red Hat positions the platform as "the trusted execution layer for mission-critical IT operations in the AI era", and the value is concentrated in the Ansible ecosystem: certified collections, automation hub, Event-Driven Ansible, automation mesh.
Who writes the automation
WindmillPeople comfortable with code. Playbooks stay YAML, and everything else is a script in Python, TypeScript, Go, Bash, PowerShell or SQL. The script editor infers inputs from the code, so the form is a side effect of writing the script.
Ansible Automation PlatformPeople who write Ansible. Automation outside the Ansible model means a playbook that shells out, or a custom module or collection. The automation coding assistant generates YAML from natural language prompts inside the Ansible VS Code extension.
Who runs it
WindmillAnsible Automation PlatformOperators launch job templates from the controller web UI or its API, with surveys collecting the inputs and RBAC deciding who may launch what. Red Hat also lists a self-service automation portal as a component of the platform.
How do you build on each platform?
The same playbook runs on both. The difference is what surrounds it: Ansible Automation Platform keeps the playbook in a project and the runtime wiring in controller objects, with a prebuilt container image as the execution environment. Windmill puts the inputs, inventories, files and dependencies in a header above the playbook, so one reviewable file is the whole unit, and the rest of the platform is code in Git too.
WindmillThe playbook is the script. A first YAML document in the same file declares the inventory, the typed inputs, the files written before the run, the Galaxy collections and the vault password, and Windmill generates the form, installs the dependencies and passes the inputs as --extra-vars. Writing result.json returns a structured result to the next flow step. A second mode runs a playbook that stays in your own repository.
- baseline.playbook.yml
- from a git repo
---
inventory:
- resource_type: ansible_inventory
extra_vars:
hostname:
type: string
files:
- variable: f/infra/ssh_private_key
target: ./ssh_key
mode: '0600'
dependencies:
galaxy:
collections:
- name: community.general
vault_password: f/infra/ansible_vault_password
---
- name: Configure baseline
hosts: all
become: true
tasks:
- name: Apply the baseline role
ansible.builtin.include_role:
name: baseline
- name: Return a result to the next flow step
delegate_to: localhost
ansible.builtin.copy:
content: "{{ { 'host': hostname } | to_json }}"
dest: result.json
---
# The playbook, roles and inventories stay in your existing repository.
# Windmill clones it, installs its requirements.yml and runs the playbook.
delegate_to_git_repo:
resource: f/infra/playbooks_repo
playbook: playbooks/site.yml
inventories_location: inventories/prod.ini
install_requirements: true
extra_vars:
hostname:
type: string
---
The playbook lives in a project, and everything around it is a separate controller object: inventory, credentials, execution environment, survey, schedule. A job template ties them together, and an approval step is a node in a workflow job template rather than a step in the playbook. These objects are created in the web UI, through the API, or declaratively with the modules of the AWX collection shown here.
- job_template.yml
- approval_node.yml
- name: Create Ping job template
job_template:
name: "Ping"
job_type: "run"
organization: "Default"
inventory: "Local"
project: "Demo"
playbook: "ping.yml"
credentials:
- "Local"
- "2nd credential"
state: "present"
survey_enabled: true
survey_spec: "{{ lookup('file', 'my_survey.json') }}"
- name: Create a workflow approval node
workflow_job_template_node:
identifier: approval_test
approval_node:
name: approval_jt_name
timeout: 900
workflow: "Test Workflow"
Examples from the job_template and workflow_approval modules in the AWX repository.
WindmillAnsible Automation PlatformAuthoring
WindmillA playbook is a script. The Ansible quickstart documents the header: extra_vars for typed inputs, inventory and additional_inventories, files for templates and SSH keys with a file mode, dependencies.galaxy for collections and roles, dependencies.python for pip packages, vault_password and vault_id, git_repos to clone roles, and options for ansible-playbook flags such as forks and limit. Everything else on the platform is a script in one of 20+ languages.
Ansible Automation PlatformA playbook is a playbook, written with the Ansible development tools, and the runtime wiring is controller objects: project, inventory, credentials, execution environment, survey, schedule, job template. Red Hat describes a job template as combining playbooks with execution environments, projects, inventories and credentials, and the workflow visualizer sequences jobs in parallel or conditionally depending on earlier results.
Where the playbook lives
WindmillEither in Windmill, as a script versioned in the workspace and in Git, or in your own repository. Setting delegate_to_git_repo makes Windmill clone the repo, pin the commit in the script lockfile, install its requirements.yml and use an inventory and an ansible.cfg from inside it. The git repo mode depends on instance-wide blob storage, which is Enterprise only.
Ansible Automation PlatformIn a project, the controller object that syncs playbooks and roles from source control, with options such as scm_update_on_launch to refresh it on every run. This is a strong point of the model: the playbooks and roles stay in the repository the team already reviews.
Dependencies and runtime
WindmillGalaxy collections, roles and pip packages are declared in the playbook header and installed locally with the same mechanism used for Python dependencies, so no extra container is built. The image that supports Ansible runs the full ansible distribution rather than ansible-core, with its collections preinstalled, and playbooks need a worker on the windmill-full or windmill-ee-full image.
Ansible Automation PlatformAutomation execution environments are the unit of runtime: packaged container images carrying a Red Hat Enterprise Linux base image, ansible-core, Python and the dependencies, built with ansible-builder and a container engine, then pushed to private automation hub or a registry. The upside is a reproducible, portable runtime; the cost is an image build and a push in the loop whenever a dependency changes.
Local dev & IDE
WindmillRun and deploy scripts from the Windmill CLI, with a VS Code extension, native language tooling and AI coding tools working on real source files. An Ansible script is two files on disk, <path>.playbook.yml and <path>.script.yaml.
Ansible Automation PlatformAnsible development tools, the Ansible VS Code extension and the automation coding assistant, which Red Hat says "uses natural language prompts to generate trusted, reliable YAML code" and is included with the subscription, with model provider usage charged separately.
Credentials and secrets
WindmillResources (typed JSON for inventories, connection info and configs) and variables (individual secrets) are reusable across scripts, flows and apps, encrypted at rest and scoped by folders and groups. A secret can be written to a file with a mode for SSH, and a vault password is read from a secret. External secret backends (Vault, Azure Key Vault, AWS Secrets Manager) are Enterprise only.
Ansible Automation PlatformCredentials are first-class controller objects. Red Hat says users can use them through RBAC without seeing the underlying secret, and the controller stores them securely. Partner integrations include HashiCorp Vault and CyberArk.
Git & CI
WindmillFull infrastructure as code: scripts, flows, apps, resources, variables, schedules, folders, groups and permissions are files in Git, deployed with the CLI and Git sync, so internal tooling ships like application code with PRs, reviews and rollbacks. Git sync is free for up to 2 users; beyond that is Enterprise only.
Ansible Automation PlatformPlaybooks and roles come from source control through projects. The controller objects around them (job templates, inventories, credentials, schedules, roles) live in the controller, and are reproducible from Git only if you choose to define them with the collection modules and run them from a pipeline.
How does the platform integrate with your existing stack?
Ansible Automation Platform integrates through collections, and the certified, vendor-supported ones are a genuine advantage for network, cloud and security vendors. Windmill integrates through collections too, and also through any package in the npm, PyPI, Go or Maven ecosystems and through typed resources, so an integration nobody has packaged is a script with an import.
WindmillAnsible Automation PlatformConnecting out
WindmillThree routes, and they compose in one flow. Galaxy collections in a playbook, any npm, PyPI, Go or Maven package as a normal import in a script, and 50+ pre-built resource types for databases, SaaS and infrastructure, filled in a typed form and shared across scripts, flows and apps. Tools with only a CLI, such as OpenTofu, PowerCLI or govc, are called from a script on a worker that has the binary.
Ansible Automation PlatformAnsible Content Collections, which Red Hat calls the "essential building blocks of automation". Certified content is built, supported and maintained by Red Hat and its technology partners, with listed partner integrations including Cisco, F5, AWS, Microsoft Azure, Google Cloud, Splunk, HashiCorp Vault and CyberArk. Validated content ships guidance Red Hat curates and tests but does not support, and both are distributed through automation hub.
Receiving events
WindmillNative triggers for HTTP routes and webhooks, cron, Kafka, NATS, SQS, MQTT, AMQP, Postgres, WebSocket, email, and Google Cloud and Azure queues. Each is a typed primitive in the UI, attached to a script or flow, and every script also gets a webhook URL and an HTTP endpoint for free.
Ansible Automation PlatformEvent-Driven Ansible is a named component of the platform. Event sources feed rulebooks, and the ansible.eda collection ships event source plugins, event filters and example rulebooks for ansible-rulebook. The controller also exposes an API that can be driven from monitoring, SOAR or CI/CD tools.
Extending
WindmillA new integration is a script with a new import, or a playbook with another collection in its header: save and run, with no image rebuild and no restart. Custom logic can be published as a typed resource type or shared on the workspace Hub for the team.
Ansible Automation PlatformWrite a module or a collection against the Ansible plugin interfaces and distribute it through private automation hub, then rebuild the execution environment image that carries it. Red Hat states that only Red Hat Ansible Certified Content is supported, with community content from Galaxy supported by the community.
How hard to get in, and how hard to get out?
Both platforms are kind on the way out for the part that matters most, because a playbook is portable by construction. Windmill also keeps the layer above the playbook as files: forms come from declared inputs, and flows, permissions and schedules are in Git. Ansible Automation Platform keeps that layer in the controller, where it is reproducible from Git only if you choose to define it with the collection modules.
WindmillAnsible Automation PlatformGetting in
WindmillThe playbook body does not change. You add the header that declares inputs, inventories, files and dependencies, or point the script at the repository the playbooks already live in. Inventories become resources, vault passwords and SSH keys become secrets, surveys become the generated form, and the job template is replaced by the script or flow itself. Teams usually start with the workflows that need a non-Ansible step anyway.
Ansible Automation PlatformIf your automation is already Ansible, the path in is short: a project pointed at the repository, an inventory, a credential, a job template. The work is in the controller objects and the execution environment images rather than in the playbooks.
Getting out
WindmillThe playbooks are still playbooks and run under plain ansible-playbook once the header is dropped. Scripts are standard Python, TypeScript, Go, Bash or SQL. The CLI exports the whole workspace as plain files, so what you lose on the way out is the runtime, not the automation.
Ansible Automation PlatformSame answer for the playbooks, which is the strength of the Ansible model. The platform-specific parts are the controller objects: job templates, surveys, workflow nodes and approval nodes, credential types, execution environment definitions. Defining them with the collection modules at least keeps them in Git, which makes them readable on the way out even though they have no equivalent elsewhere.
Audit logs, observability, security, performance
Both cover the enterprise basics. Ansible Automation Platform includes RBAC, SSO and activity streams in the subscription, and automation mesh is a strong answer for segmented networks. Windmill ships RBAC, capped SSO, encrypted secrets and audit-ready run history in the open-source core, and gates uncapped SSO, external secret backends, unlimited workspaces and dedicated workers behind Enterprise.
WindmillAnsible Automation PlatformObservability
WindmillReal-time streaming logs, per-run inputs, outputs and duration, worker queue metrics and a Prometheus exporter, with a trace ID on every job. A flow run page shows the per-step status and result, including the playbook's result.json.
Ansible Automation PlatformCentralized logging to track job execution from one location, built-in activity streams for auditing and reporting, and an automation dashboard with automation analytics as platform components.
Audit logs
WindmillA full trail of who ran, edited and deployed what. Audit logs are included on Cloud and Enterprise only on self-hosted, where the Enterprise retention is unlimited.
Ansible Automation PlatformActivity streams are part of the controller and come with the subscription, so there is no separate tier to buy for them. There is also no free tier to run them on.
Security
WindmillSOC 2 Type II compliant. RBAC, SSO for up to 10 users, encrypted secrets at rest and sandboxed execution in the open-source core. Uncapped SSO, custom workspace roles and external secret backends are Enterprise only.
Ansible Automation PlatformRBAC is in the controller, with granular permissions for users and teams on projects, job templates and inventories, and credentials usable without revealing the secret. None of it is a paid add-on, because the whole platform is paid.
Isolation & segmentation
WindmillMultiple isolated workspaces on one instance, each with its own users, resources, secrets and access controls, and worker groups placed inside the network segment that owns the infrastructure. Self-hosted Community Edition is capped at 3 workspaces; unlimited is Enterprise only.
Ansible Automation PlatformOrganizations and teams scope controller objects, and automation mesh is "an overlay network intended to ease the distribution of automation across a collection of execution nodes", with hop nodes routing traffic so automation reaches segmented networks. That is one of the platform's strongest pieces for segmented estates.
Performance
WindmillRoughly 20 ms of overhead between flow steps, and dedicated-worker mode Enterprise only keeps runtimes and dependencies warm. For playbooks the run time is dominated by Ansible itself, so the orchestration overhead is a rounding error.
Ansible Automation PlatformExecution happens in execution environment containers, scheduled by the controller and distributed by automation mesh. Playbook run time is again dominated by Ansible, with container startup and project sync added per job.
Open source, pricing, and self-hosting?
Windmill publishes its Enterprise pricing and leaves the engine free to self-host. Ansible Automation Platform is bought, not downloaded: the subscription is what buys certified content and Red Hat support, and the upstream AWX project is Apache 2.0 but has paused releases since July 2024.
WindmillAnsible Automation PlatformOpen source
WindmillAGPLv3 core, free and unlimited to self-host, with Ansible support, triggers, RBAC and the flow and app editors in it. Enterprise features (uncapped SSO, dedicated workers, external secret backends, unlimited workspaces) ship in a separate proprietary codebase. Managed cloud available.
Ansible Automation PlatformThe platform is a Red Hat subscription product. Its upstream projects are open source: ansible-core is GPLv3, and AWX, the Apache 2.0 web UI, REST API and task engine that is "one of the upstream projects for Red Hat Ansible Automation Platform", is self-hostable. The AWX README notes that the last release was on 2 July 2024 and that "releases of this project are now paused during a large scale refactoring", so AWX is not a like-for-like substitute for the product today.
Pricing
WindmillPublic per-seat and per-worker Enterprise pricing on the pricing page, and the open-source core costs nothing to run.
Ansible Automation PlatformNot public. Red Hat says pricing "varies based on your sizing and subscription choices" and points buyers to a Red Hatter or a partner for a customized quote. Two tiers are listed, Standard with 9 AM to 5 PM support and Premium with 24x7 support, across managed service, managed application and self-managed deployments.
What the money buys
WindmillSupport, the Enterprise feature set and managed cloud if you want it. The engine, the languages and the editors are in the free core, so a proof of concept needs no contract.
Ansible Automation PlatformRed Hat support on the automation layer, certified content with a documented release strategy, automation hub, and the automation coding assistant, which is included with the subscription while model provider usage is charged separately. For regulated estates that need a vendor on the hook, that is the product.
The verdict
This is not a comparison of two ways to run a playbook, because both run the same playbook. It is a comparison of the layer above it. Ansible Automation Platform models that layer as controller objects around a project in source control: job templates, inventories, credentials, surveys, workflow nodes, execution environment images. Windmill models it as code: the playbook carries its own inputs, inventories and dependencies in a header, and the platform around it is scripts, flows, apps and permissions that live in Git.
Ansible Automation Platform can be the right call if your automation is Ansible and will stay Ansible, you want certified collections and a vendor supporting the automation layer, you need the Ansible-specific depth of Event-Driven Ansible rulebooks, automation hub and automation mesh, or a Red Hat subscription is simply how your organization buys software.
Windmill is the better fit when the automation is not only Ansible. Playbooks run natively, and the steps around them run on the same platform: a Python or PowerShell step, an OpenTofu plan, a ServiceNow ticket, a database write, an approval, a form for a requester, a dashboard for the team. One set of credentials, one permission model, one run history, and one place to answer who changed a host and who approved it. For the specific case of replacing a vRealize or Aria Automation workflow engine, there is a dedicated page on how that migration goes.
One more thing is changing the weighting. As AI coding tools write more of the automation, the bottleneck moves from writing it to reviewing it. Automation that is files in a repository, playbooks, scripts and flow definitions, can be read in a pull request, diffed, tested and rolled back by commit. Automation that is form state in a control plane cannot, however good the UI is. That is an argument for keeping the layer above the playbook in code, and it is independent of which vendor you pick.
If you are deciding between the two, the fastest way to judge is to spend an afternoon in each: take one playbook you already run, wire it up on both sides, and see what the work around it looks like.
Frequently asked questions
Build your internal platform on Windmill
Scripts, flows, apps, and infrastructure in one place.