Ansible - Using Ansible on Windows

Refreshed June 2026: the original version of this post installed Ansible on Windows through Cygwin, with Python 2 and Ansible 1.9. That approach is long dead. Python 2 is end of life, pycrypto is gone, and Cygwin was always a workaround. This rewrite covers the two things people actually mean when they search for “Ansible on Windows,” and how each is done today.

Two Different Questions

When I wrote this in 2015, I lumped together two goals that are worth separating:

1. Running Ansible from a Windows machine. You are sitting at a Windows desktop and want Ansible as your control node.
2. Managing Windows machines with Ansible. Your control node is fine, you just need to automate Windows targets.

The Cygwin method was an attempt at the first. There is a much cleaner answer now, and the second question has first-class support that did not really exist back then.

Running Ansible From a Windows Machine

Ansible cannot run as a control node natively on Windows. The Ansible docs are explicit: “Ansible cannot run on Windows as the control node due to API limitations on the platform.” So you do not install Ansible onto Windows itself. You give it a Linux environment to run in.

WSL (for development and labs)

The Windows Subsystem for Linux gives you a real Linux distribution on your Windows machine. From an elevated PowerShell:

wsl --install -d Ubuntu

Reboot if prompted, open the Ubuntu shell, then install Ansible with pipx so it lands in an isolated environment:

sudo apt update && sudo apt install -y pipx
pipx install --include-deps ansible
ansible --version

That is the whole story now. No Cygwin packages, no pip2, no compiling pycrypto.

One honest caveat: Ansible’s documentation states that WSL “is not supported by Ansible and should not be used for production systems.” It is great for a laptop, a lab, or learning. For anything you depend on, use a real Linux control node or a container.

Containers and execution environments (for anything real)

If you want a reproducible control node that does not depend on your desktop, run Ansible in a container. The current packaging model is the Execution Environment: a container image with ansible-core, your collections, and their dependencies baked in. You build it with ansible-builder and run it with ansible-navigator, and it behaves identically on your Windows laptop (via the Docker or Podman engine), a Linux server, or CI. This is where I would point anyone past the tinkering stage.

Managing Windows Hosts With Ansible

This is what most people are actually after, and it has nothing to do with installing Ansible on Windows. The control node stays on Linux (or WSL). The Windows machines are just targets.

Ansible reaches Windows targets over WinRM, the newer PSRP plugin, or SSH. The Windows-specific modules live in the ansible.windows, community.windows, and microsoft.ad collections and are written in PowerShell to run on the target. Windows Server 2016 and later ship with PowerShell 5.1, which is enough to get started.

Install the collection on your control node:

ansible-galaxy collection install ansible.windows

A minimal inventory pointing at a Windows host over WinRM:

all:
  hosts:
    win01.example.internal:
      ansible_host: 10.0.10.20
  vars:
    ansible_connection: winrm
    ansible_user: automation
    ansible_password: "{{ vault_win_password }}"
    ansible_winrm_transport: ntlm
    ansible_port: 5986

And a quick connectivity check using win_ping, the Windows equivalent of the usual ping module:

ansible -i inventory.yml win01.example.internal -m ansible.windows.win_ping

From there the patterns are the same as any other Ansible work: ansible.windows.win_feature to manage roles and features, ansible.windows.win_package for installs, ansible.windows.win_updates for patching, and so on. SSH is worth a look as an alternative to WinRM, especially in non-domain environments, since it allows key-based auth and faster file transfers.

Why Not Cygwin Anymore

Cygwin worked in 2015 because there was no better option from Windows and Ansible still ran on Python 2. Every leg of that has been removed: Python 2 reached end of life, the crypto stack moved from pycrypto to cryptography, and WSL now gives you an actual Linux userland instead of a POSIX emulation layer. There is no reason to fight Cygwin for this today.

Conclusion

If you want Ansible on your Windows desktop, run it in WSL for tinkering or in a container for anything real. If you want to automate Windows servers, keep your Linux control node and talk to them over WinRM or SSH with the ansible.windows collection. Same Ansible, far less friction than the old way.

Enjoy!