Does Windmill replace Terraform or Ansible?

No. Windmill orchestrates them. OpenTofu or Terraform keeps managing state and resources, Ansible keeps configuring hosts. Windmill adds what sits around them: typed inputs and forms, approvals, secrets, retries, schedules, triggers, run history and audit logs, and the steps before and after (tickets, IPAM, notifications).

How do I run Terraform or OpenTofu in Windmill?

There is no proprietary Terraform step. Install the tofu or terraform binary on a worker group, through a custom image or preinstalled binaries, and call the CLI from a Python or Bash script. Pass credentials from Windmill resources as environment variables and keep state in a remote backend such as Postgres or S3. Route the script to that worker group with a tag.

Can Windmill run Ansible playbooks?

Yes. Ansible is a native script language in Windmill. A header in the playbook declares inputs, inventories, file resources and Galaxy or Python dependencies, and Windmill generates the input form and runs ansible-playbook. Playbooks need the windmill-full or windmill-ee-full worker image.

Can requests from ServiceNow start a Windmill flow?

Yes. A ServiceNow business rule or Flow Designer REST step calls the flow's webhook or HTTP route. A preprocessor maps the request payload to the flow inputs, and a step at the end of the flow updates the request item. Windmill ships a servicenow resource type that supports basic auth and OAuth.

How do jobs reach infrastructure in isolated networks?

Run workers inside the network segment and route jobs to them with worker tags. On Enterprise, agent workers connect out to Windmill over HTTP only, with no inbound port and no database access, and SSH execution can run Bash scripts on a jump host reachable only over SSH.

Is Windmill open source?

The Community Edition is open source under AGPLv3 and can be self-hosted for free, including for infrastructure automation. The Enterprise Edition adds features such as agent workers, approval forms, external secret backends, longer audit log retention and native Windows workers.

Can Windmill run in an air-gapped data center?

Yes. Windmill is self-hosted with Docker Compose, Kubernetes or binaries and runs scripts on your own workers. Air-gapped Enterprise instances report license usage with a signed file uploaded to the customer portal instead of telemetry.

Windmill

Windmill cloud

OSS

Infrastructure automation on one open source orchestrator

Wrap the Terraform or OpenTofu modules, Ansible playbooks and scripts you already have in flows with approvals, retries and audit logs. Provision on vSphere, Kubernetes or cloud, then run the Day 2 jobs from the same place.

Try Windmill cloud Self-host in 3 mins

✓OpenTofu, Terraform, Ansible, PowerShell, Python and Bash in one flow

✓Approval steps and self-service forms generated from the inputs

✓ServiceNow requests start flows, flows close the tickets

✓Workers inside the network segment that owns the infrastructure

flow · f/infra/provision_vminfra worker

Plan the request

size + OS → spec

queuedrunningdone

Approval

prod or large only

queuedrunningdone

Clone the VM

OpenTofu · vSphere

queuedrunningdone

Apply the baseline

Ansible over SSH

queuedrunningdone

Close the request

ServiceNow RITM

queuedrunningdone

Infrastructure automation ends up in five places

Terraform runs from a CI pipeline, playbooks from AWX, the catalog lives in vRA or ServiceNow, patching is a cron job on a jump host, and the cleanup scripts sit in someone's home directory. Each tool has its own credentials, its own logs and its own idea of who is allowed to run what. Answering "who changed this VM, and who approved it" means opening four of them.

Windmill does not replace Terraform, OpenTofu or Ansible: it runs them. A flow takes typed inputs, calls each tool as a step, pauses for approval where policy says so, retries what is safe to retry, and keeps the inputs, logs and approver of every run. The same platform runs the schedules, the event-driven remediation and the self-service forms, so there is one place to look.

OpenTofu and Terraform runs with shared inputs and secrets

Windmill has no proprietary Terraform step: a script calls the tofu or terraform CLI on a worker where the binary is installed, through a custom image or preinstalled binaries. Credentials come from resources as typed arguments and reach the CLI as environment variables. State stays in the backend you choose, and the plan and apply output stream to the run log.

See the full script

f/infra/tofu_vm.py

def main(
    action: Literal["apply", "destroy"],
    vm_name: str,
    vsphere: c_vsphere,      # resource, picked in the form
    tf_state: postgresql,    # pg backend, one workspace per VM
    cpus: int = 2,
    memory_mb: int = 4096,
    dry_run: bool = False,
):
    env = {
        "PG_CONN_STR": _pg_conn_str(tf_state),
        "TF_VAR_vsphere_password": vsphere["password"],
        ...
    }
    _run("tofu", ["init", "-input=false"], env)
    _run("tofu", ["workspace", "select", "-or-create", vm_name], env)
    _run("tofu", ["apply", "-auto-approve"], env)

Ansible playbooks as a native script language

A playbook is a script in Windmill. A short header declares its inputs, inventories, files and Galaxy collections; Windmill generates the form, installs the dependencies, writes SSH keys from secrets with the right mode, and passes the inputs as --extra-vars. Write result.json and the next step of the flow gets a structured result.

Ansible quickstart

f/infra/configure_baseline.playbook.yml

---
extra_vars:
  host_ip:   { type: string }
  hostname:  { type: string }
files:
  - variable: f/infra/ssh_private_key
    target: ./ssh_key
    mode: '0600'
dependencies:
  galaxy:
    collections:
      - name: community.general
---
- hosts: localhost
  tasks:
    - add_host:
        name: "{{ hostname }}"
        ansible_host: "{{ host_ip }}"
        groups: new_vm
- hosts: new_vm
  become: true
  tasks: ...

Approvals and self-service requests

A flow's input schema becomes a form with enums, patterns and defaults, which is the catalog item. An approval step suspends the run until someone approves from the run page, a resume link, Slack or Teams, and a condition decides when it applies: prod only, large sizes only. For a richer front end, build an app on top of the same flow. Approval forms and approver restrictions are Cloud and Enterprise features.

Learn more about generated forms

Windmill flow run detail with per-step status, logs and results

The ticket lifecycle, closed by the flow

Keep the catalog in ServiceNow if that is where requesters live. A business rule calls the flow's webhook or HTTP route, a preprocessor maps the request to typed inputs, and the last step writes the result back on the RITM. When a step fails, the flow's failure handler rolls back and puts the error on the ticket.

See the provisioning flow

provision_vm__flow/preprocessor.ts

export async function preprocessor(event: Event) {
  const body = event.body ?? {};
  const v = body.variables ?? body;
  return {
    vm_name: String(v.vm_name).toLowerCase(),
    size: v.size ?? "small",
    os: v.os ?? "ubuntu-24.04",
    environment: v.environment ?? "dev",
    ticket: body.number,   // RITM0010001
  };
}

Run the job next to the infrastructure

Tag a script vsphere-dc1 and only the workers in that data center pick it up. For segments that should not open inbound ports, agent workers connect out to Windmill over HTTP and never touch its database. When the only way in is a jump host, SSH execution reroutes a Bash script over SSH. Agent workers and SSH execution are Enterprise features; worker tags are in every edition.

Learn more about worker groups

vsphere-dc1

· Terraform / OpenTofu + vSphere
· pyvmomi
· Ansible to DC1 VMs

k8s-prod

· kubectl / Helm
· Cluster maintenance
· Namespace audits

ot-plant

· Agent worker
· Outbound HTTP only
· No DB access

windows

· PowerShell / PowerCLI
· Native Windows worker
· Active Directory

Day 2 operations

Provisioning is one request. Patching, cleanup and compliance run every night for years. Each of these is a script or flow on a schedule or a trigger, with its own run history and error handler.

Fleet patching

Ansible or PowerShell across hosts, a canary first, then batches. The first failed batch stops the run before the rest of the fleet.

Capacity hygiene

Nightly sweeps for old snapshots, orphaned disks and powered-off VMs, with a dry run until you trust them.

Compliance checks

Certificate expiry, drift against a source of truth, credential rotation. A failed check is a failed job, which reaches your error handler.

Auto-remediation

Point an Alertmanager, Datadog or PagerDuty webhook at a flow: restart the service, scale the pool, or open a ticket and page a human.

Start from working flows

The windmill-vmware-vra-replacement repository holds the flows on this page as files you push with wmill sync push: VM provisioning and decommissioning on vSphere, rolling patching, the snapshot sweeper and the certificate check. Each flow has a dry_run input, so you can walk it before pointing it at vCenter.

terminal

git clone https://github.com/windmill-labs/windmill-vmware-vra-replacement
cd windmill-vmware-vra-replacement
wmill workspace add infra <workspace_id> https://windmill.example.com/
wmill sync push
wmill flow preview f/infra/rolling_patch__flow \
  -d '{"hosts":["web-01","web-02","web-03"],"require_approval":false,"dry_run":true}'

Works with the tools you already run

Anything with a CLI, an SDK or an API is reachable from a script in Python, TypeScript, Go, Bash, PowerShell or another supported language.

VMware vSphere

OpenTofu or Terraform for lifecycle, pyvmomi or PowerCLI for everything else.

Ansible

Playbooks as a native script language, with Galaxy collections and inventories as resources.

OpenTofu / Terraform

Run the CLI from a script on workers where the binary is installed. State stays in your backend.

Kubernetes

kubectl, Helm and client libraries from Bash, Python or TypeScript. Windmill itself runs on Kubernetes.

AWS, Azure, GCP

SDKs in any language, OIDC tokens instead of long-lived keys.

ServiceNow

Resource type with basic auth or OAuth. Catalog requests start flows, flows close tickets.

NetBox and IPAM

NetBox resource type for IP allocation, device lookup and inventory reconciliation.

Secret managers

Vault, Azure Key Vault or AWS Secrets Manager as the secret backend on Enterprise.

Proxmox, Nutanix, bare metal

Any API or CLI the worker can reach, from code you already have.

Built for how infrastructure teams work

Git and CI/CD

Every script, flow, schedule and trigger is a file. Sync with the CLI or Git sync, review in pull requests, promote between workspaces.

Audit logs

Who ran what, with which inputs, who approved it. 365 days of retention on Enterprise, 14 on Community Edition.

Permissions

Folders, groups and per-resource permissions. Operators run the flow without ever reading the vCenter password.

Secrets

Encrypted per workspace and injected at run time. Vault, Azure Key Vault or AWS Secrets Manager as backends on Enterprise.

Retries and error handlers

Per-step retries with backoff, flow failure handlers for rollback, workspace and schedule error handlers for alerting.

Run history

Every run keeps its inputs, logs, per-step results and duration, searchable and replayable.

Self-hosted, offline capable

Docker Compose, Kubernetes or bare binaries in your data center, including air-gapped networks.

AI that knows your stack

Expose flows to AI agents and MCP clients, or let Claude Code write scripts with the Windmill CLI skills.

Moving off vRA, vRO, Rundeck or cron

Most infrastructure teams come to Windmill to replace a workflow engine, not their hypervisor. vRO workflows become flows, JavaScript actions become TypeScript scripts with few changes, configuration elements become resources, and packages become a Git repository. The guide covers what moves, what stays, and how to size the migration.

Read the vRA replacement guide

More you can build on Windmill

The same platform runs data pipelines, internal apps, AI agents and Windows automation.

Scripts

Write scripts in TypeScript, Python, Go, Bash, SQL and trigger them from webhooks, schedules, queues or the auto-generated UI.

Internal apps

Build production-grade internal apps with backend scripts, data tables and React, Vue or Svelte frontends.

Data pipelines

Orchestrate ETL jobs with parallel branches, DuckDB queries and connections to any database or S3 bucket.

AI agents

Build AI agents with tool-calling, DAG orchestration, sandboxes and direct access to your scripts and resources.

Workflows

Chain scripts into flows with approval steps, parallel branches, loops and conditional logic.

Scheduled tasks

Run cron jobs with a visual builder, execution history, error handlers, recovery handlers and alerting.

Windows automation

Run PowerShell, MSSQL with Kerberos and C# natively on domain-joined Windows servers, no Docker required.

Frequently asked questions

: No. Windmill orchestrates them. OpenTofu or Terraform keeps managing state and resources, Ansible keeps configuring hosts. Windmill adds what sits around them: typed inputs and forms, approvals, secrets, retries, schedules, triggers, run history and audit logs, and the steps before and after (tickets, IPAM, notifications).
: There is no proprietary Terraform step. Install the tofu or terraform binary on a worker group, through a custom image or preinstalled binaries, and call the CLI from a Python or Bash script. Pass credentials from Windmill resources as environment variables and keep state in a remote backend such as Postgres or S3. Route the script to that worker group with a tag.
: Yes. Ansible is a native script language in Windmill. A header in the playbook declares inputs, inventories, file resources and Galaxy or Python dependencies, and Windmill generates the input form and runs ansible-playbook. Playbooks need the windmill-full or windmill-ee-full worker image.
: Yes. A ServiceNow business rule or Flow Designer REST step calls the flow's webhook or HTTP route. A preprocessor maps the request payload to the flow inputs, and a step at the end of the flow updates the request item. Windmill ships a servicenow resource type that supports basic auth and OAuth.
: Run workers inside the network segment and route jobs to them with worker tags. On Enterprise, agent workers connect out to Windmill over HTTP only, with no inbound port and no database access, and SSH execution can run Bash scripts on a jump host reachable only over SSH.
: The Community Edition is open source under AGPLv3 and can be self-hosted for free, including for infrastructure automation. The Enterprise Edition adds features such as agent workers, approval forms, external secret backends, longer audit log retention and native Windows workers.
: Yes. Windmill is self-hosted with Docker Compose, Kubernetes or binaries and runs scripts on your own workers. Air-gapped Enterprise instances report license usage with a signed file uploaded to the customer portal instead of telemetry.

Put your infrastructure automation in one place

Self-host Windmill, push the example flows, and run the first provisioning request in dry run.

Self-host Windmill View pricing