Ansible Development Environment Options

Where you write and test Ansible playbooks shapes more than your editor. It decides how quickly a new teammate gets productive, whether “it works on my machine” becomes a recurring meeting, and how close your tests run to the environment your automation will actually manage.

This post compares five setups, split between local and remote, so you can pick the one that fits your project. The rest of the series walks through the container and remote setups step by step.

At a glance

Option	Runs on	Setup effort	Best for
Python virtual environment	Your machine	Minutes	Solo work, quick experiments
Container (Podman or Docker)	Your machine	Low	Teams that need identical tool versions
Code Server	A remote server, in the browser	Medium	Working from any device
VS Code Remote SSH	A remote server, from your local VS Code	Low, if you have SSH	Heavy work on remote compute
OpenShift Dev Spaces	Your OpenShift cluster	Medium to high	Teams already on OpenShift

Local options

Local setups give you direct control, the lowest editing latency, and they work offline.

1. Python virtual environment

A Python virtual environment (venv) isolates Ansible and its dependencies from your system-wide Python, so two projects can use two different versions without stepping on each other.

python3 -m venv ansible-venv
source ansible-venv/bin/activate
pip install ansible-dev-tools

ansible-dev-tools installs the whole toolkit in one go: ansible-core, ansible-lint, ansible-navigator, molecule and the rest. If you only need the basics, pip install ansible-core ansible-lint works too.

• Benefits: lightweight, fast to set up, one environment per project.
• Trade-off: every developer builds their own, so versions drift unless you pin them.
• Best for: individuals who want simplicity and minimal tooling.

2. A container with Podman or Docker

Running Ansible inside a container gives you the same clean, reproducible environment every time, on every machine. With VS Code’s Dev Containers extension, the editor itself works inside that container.

• Benefits: consistent across machines, easy to reset, and the same image can run in your CI/CD pipeline.
• Trade-off: you need Podman or Docker locally, and access to the container registry.
• Best for: teams that need identical environments without cluttering their laptops.

Step by step: Ansible Dev Server using VS Code Dev Containers.

Remote options

Remote setups suit collaborative work, resource-heavy tasks, and environments you want to reach from anywhere.

3. Code Server

code-server runs VS Code on a remote server and serves it to your browser, so a fully configured Ansible workspace is one login away on any device.

• Benefits: works from any browser, the same settings everywhere, easy to share one set-up with teammates.
• Trade-off: you run and secure the server yourself, and it installs extensions from Open VSX rather than Microsoft’s marketplace.
• Best for: distributed teams who want a familiar IDE without installing anything locally.

Step by step: Ansible Dev Server using Code Server.

4. VS Code Remote SSH

With the Remote - SSH extension, your local VS Code connects to a server or VM where Ansible is installed. The editor stays local; the files, terminal and Ansible run remotely.

• Benefits: remote compute with a responsive local editor, and almost no setup if you already have SSH access.
• Trade-off: each developer still configures the remote environment, unless you standardize it.
• Best for: developers who want remote compute power with the feel of a local editor.

5. OpenShift Dev Spaces

OpenShift Dev Spaces provides containerized development workspaces that run inside your OpenShift cluster.

• Benefits: preconfigured workspaces with the Ansible tools, integration with GitOps and CI/CD workflows, and it runs in the same cluster where your automation will be deployed.
• Trade-off: you need OpenShift, and someone to administer Dev Spaces.
• Best for: teams already working in the OpenShift ecosystem who want a managed, enterprise-ready platform.

Which should you choose?

• Starting out, or working alone? A virtual environment is enough.
• Working in a team? Start with a container (option 2). It removes most version problems on day one.
• Mixing them is fine. For example, prototype locally in a container, then test in an OpenShift Dev Spaces workspace (option 5) before you commit to production.