Skip to content

Ansible on Windows: It's Complicated

Post Banner

Overview

When I first tried running Ansible on Windows a few years ago, I simply started with pip install ansible inside a Python virtual environment on my Windows machine. Very quickly, it turned into a nightmare trying to make it work reliably.

That experience led me to search for the root cause, and I eventually discovered that Ansible does not support a native Windows controller.

Based on research and experiments by Rolpdog—captured in a well-written blog post explaining why this is the case—the following is a concise summary of the key reasons:

No fork() on Windows

  • Ansible's core worker model relies on the POSIX fork() system call to clone processes for each task/host.

  • Windows doesn't have fork(), so the whole execution engine can't work as-is.

  • Cygwin's attempt at implementing fork() is unstable, and WSL's fork support isn't "native Windows" anyway.

Deep "UNIX-isms" in Code & Modules

Many parts of Ansible assume a POSIX environment:

  • Paths use /

  • Set UNIX file modes (e.g., chmod)

  • Expect POSIX tools/syscalls

  • Hardcoded behavior for core modules

Even if patched, most POSIX modules never would behave the same on Windows.

Playbook Content Is Unix-biased

Even if Ansible ran on Windows:

  • Most existing playbooks assume *nix behavior (e.g., localhost, piping, filters, become/sudo)

  • Execution parity with *nix controllers would be nearly impossible.

Insufficient Test Coverage and CI Gaps

Without a comprehensive Windows test suite:

  • Patches to make the Ansible core run on Windows would quickly regress

  • There is no reliable way to enforce correctness through automated testing

As a result, maintaining Windows support would be high risk and difficult to scale.

Workarounds

Ansible cannot run natively on Windows as a controller because:

  • It depends on UNIX process and system conventions

  • The ecosystem (modules + playbooks) assumes POSIX

  • Huge testing + compatibility work would be required

Based on this, several workarounds can replace the current situation with minimal friction, based on my experience.

(1) Run Ansible in a Linux-based container:

Use Docker or Podman to run Ansible inside a Linux container. This ensures a consistent, reproducible Linux environment across machines, while sharing SSH keys and configuration with the Windows host.

(2) Use WSL2 with Ubuntu:

Install WSL2 and run Ubuntu, then install Ansible inside it. This provides near-native Linux behavior and works well for local development, but environment consistency may vary between systems.

Reference