Red Hat Ansible development workspaces for governed automation content creation

Accelerate automation development with Ansible development workspaces in Red Hat OpenShift Dev Spaces

August 21, 2026
Leonardo Gallego
Related topics:
Developer tools
Related products:
Red Hat Ansible Automation Platform

Onboarding a new automation developer is rarely quick. Day 1 is paperwork. On day 10, the laptop arrives. On day 20, the IDE and tools are installed. On Day 30, repository access and permissions are finally sorted out, and it can be weeks before a single playbook gets written.

Even after that initial setup, keeping environments consistent across a team is a challenge that documentation alone can't solve. One developer runs ansible-lint v25 while another uses v26. Molecule tests pass on one workstation but fail on another because of a missing system dependency. When something breaks, the first question is always "which version were you running?" instead of "what changed?"

The way to eliminate this problem is Ansible development workspaces , available in Red Hat Ansible Automation Platform and powered by Red Hat OpenShift Dev Spaces. Developers open a browser, navigate to their OpenShift Dev Spaces dashboard, and launch a workspace. Within minutes, they have a full VS Code environment running in the cloud with every Ansible development tool pre-installed, the Ansible VS Code extension configured, and the team's linting profile active. No local Python. No container runtime. Just a browser and credentials.

Benefits of OpenShift Dev Spaces

  • Standardization and consistency: By defining the entire development workspace as code (using a devfile in YAML), all developers use the exact same tools and configurations, which eliminates the infamous "it worked on my machine" problem.
  • Accelerated onboarding: Developers can launch the environment in their browser and be ready to code in minutes, without needing to install local tools or extensions.
  • Enhanced security: The source code lives on the OpenShift cluster and never lands on the user's local laptop, allowing the operations team to centrally control the security standards for the development environments.

What if it took five minutes to onboard your automation developers?

Ansible development tools is a bundle of essential CLI capabilities in a single, versioned package for the Ansible content lifecycle. The maturity path for delivering Ansible development tools to automation developers looks like this:

Crawl

  • Method: pip or uv
  • Onboarding: ~30 min
  • Environment consistency: Low. Each developer manages their own.

Walk

  • Method: RPM
  • Onboarding: ~15 min
  • Environment consistency: Medium. Same package, no IDE config.

Run

  • Method: Dev container
  • Onboarding: ~10 min
  • Environment consistency: High. Same image, tools, and config.

Fly

  • Method: OpenShift Dev Spaces
  • Onboarding: ~5 min
  • Environment consistency: Highest. Centrally managed, browser-only.

Most organizations are somewhere between the "crawl" and "walk" stage today. Dev containers and OpenShift Dev Spaces are the target. They require an initial investment in image management, but once that investment is made, the environment is completely transparent to developers.

The implementation of Ansible development workspaces enables the "fly" stage, ensuring maximum consistency with minimum friction. It's especially important for organizations needing secure, highly controlled development environments.

What the developer sees

From the developer's perspective, the complexity is invisible. They see a VS Code interface in their browser with a terminal, file explorer, extensions panel, and all the Ansible tooling ready to go. The full Create/Test/Deploy lifecycle works out of the box:

  • Create: Set up development environments with ansible-dev-environment. Scaffold new collections and roles with ansible-creator.
  • Test: Lint with ansible-lint, run molecule integration tests inside nested Podman containers, and validate modules with pytest-ansible and tox-ansible.
  • Deploy: Build execution environments with ansible-builder, sign content with ansible-sign, and push to Git to trigger continuous integration (CI).

All from the browser. No local installs, no "which Python version do I need?" conversations.

The workspace itself is defined declaratively in a devfile.yaml checked into the project repository. When a developer clicks Create Workspace on that repository, OpenShift Dev Spaces reads the devfile, provisions the environment, and presents a ready-to-use IDE. Every developer who opens the same repository gets the same environment.

Why this matters for enterprise teams

Introducing Ansible development workspaces isn't just about convenience. For platform teams, automation architects, and engineering managers, it's about control and governance without friction.

When the platform team controls the workspace image, they control the toolchain version, the linting rules, the VS Code extensions, and the resource limits. Standards aren't documented and hoped-for; they're inherited automatically by every workspace that uses the image.

This matters most for organizations where automation architects manage multiple automation domains. Consider the package requirements across different teams:

  • Network automation: libssh-devel, python3-netaddr, paramiko
  • Windows automation: krb5-workstation, python3-pykerberos
  • Red Hat Ansible Automation Platform config-as-code: httpie, python3-pyyaml
  • Cloud automation: awscli, python3-boto3

A single monolithic image either bloats with every team's dependencies or satisfies no one. The Ansible development tools container image has /var read-only at runtime, and that's by design. Container immutability is a feature, not a limitation. You don't want developers running dnf install inside their workspaces, because that creates drift.

Tiered image strategy: Customization without compromise

The solution is a tiered approach to image management, using standard OpenShift build primitives:

Base Image

  • Scope: Everyone
  • What it adds: Ansible development tools
  • Managed by: Red Hat

Org / Domain

  • Scope: Domain teams
  • What it adds: Domain-specific system packages
  • Managed by: Platform team

Team

  • Scope: One team
  • What it adds: Team-specific extras
  • Managed by: Team lead

Personal

  • Scope: One developer
  • What it adds: Individual niche needs (opt-in)
  • Managed by: Individual

Each tier is an OpenShift BuildConfig that layers on top of the previous tier's ImageStream. When the base image receives a security patch, the entire chain rebuilds automatically, with no manual intervention at any tier. Security patches propagate in minutes, not days.

Adding a new domain image is as straightforward as writing a short Containerfile:

FROM registry.redhat.io/ansible-automation-platform-27/ansible-devspaces-rhel9:latest
USER root
RUN dnf install -y \
      libssh-devel \
      python3-netaddr \
    && dnf clean all
USER 1000

For organizations with 5 or more domain variants, a CEKit (container environment kit) factory model generates Containerfiles from YAML definitions. Adding a new domain becomes a YAML file, not a Containerfile.

Self-service without bottlenecks

The tiered model keeps the platform team as gatekeepers without making them a bottleneck. Teams request image customizations with a pull request to the config repository. The platform team reviews for security and compatibility, merges, and the rebuild happens automatically.

For individual developers who need a system package no one else on the team requires, Tier 4 provides an opt-in personal layer: A fork of the team workspace repo with an additional Containerfile layer. If the same package shows up in multiple personal layers on the same team, it gets promoted to Tier 3. Lifecycle policies clean up stale personal images after 90 days.

The ownership model breaks down like this:

  • Base image version: Platform admin
  • Domain-specific packages: Platform team
  • Team-specific extras: Team lead
  • Personal extras: Individual developer (opt-in)

From local dev container to cloud workspace

If your team already uses the Ansible development tools dev containers locally, the transition to Ansible development workspaces is not complex. The same image that powers your .devcontainer/ setup is the same image that runs in OpenShift Dev Spaces. The difference is operational:

  • Dev containers require each developer to have a local container runtime (Docker or Podman), sufficient disk space, and permissions to run containers on their workstation.
  • OpenShift Dev Spaces removes all of those requirements. The infrastructure is managed by OpenShift. Developers only need a browser.

Both deliver high consistency in your environment. OpenShift Dev Spaces goes further by adding centralized governance: The platform team and automation architects control resource limits, image versions, and access policies from the cluster, not from documentation that developers may or may not follow.

The content lifecycle in a governed workspace

With Ansible development workspaces, the full content lifecycle (create, test, deploy) runs inside a governed environment:

Inner loop (automation developer)

  1. Write playbooks and roles
  2. Lint with ansible-lint
  3. Test with molecule in nested Podman
  4. Iterate

Fast feedback, consistent tools, no local setup.

Outer loop (CI/CD)

  1. Push to Git
  2. PR triggers quality gates (ansible-lint, molecule, ansible-sign) on merge
  3. ansible-builder builds the execution environment, automation controller syncs the project.

The same toolchain in the workspace matches the toolchain in CI.

Every execution in automation controller records the project revision, so the audit trail connects production runs back to specific commits, written in an environment that enforced the team's quality standards from the start.

Getting started

Ansible development workspaces require an OpenShift cluster with the Red Hat OpenShift Dev Spaces operator installed. Point a workspace at any Git repository containing a devfile.yaml with the Ansible development tools container image:

schemaVersion: 2.2.2
metadata:
  name: ansible-dev-tools-workspace
components:
  - name: tooling-container
    container:
      image: registry.redhat.io/ansible-automation-platform-27/ansible-devspaces-rhel9:latest
      memoryRequest: 2Gi
      memoryLimit: 4Gi
      cpuRequest: 500m
      cpuLimit: 1000m

The supported image requires Red Hat registry authentication and an Ansible Automation Platform or Ansible Developer subscription.

For development, testing, or community use without a subscription, replace the image value with ghcr.io/ansible/ansible-devspaces:latest.

Developers log into the OpenShift Dev Spaces dashboard, paste the repository URL, click Create & Open, and start coding.

For setup details and the supported image variants, see the Ansible development workspaces documentation. For the tiered image strategy, see the Ansible development tools container community documentation.

The recommended adoption path: Start with a Tier 2 org-wide image using a simple inline BuildConfig, validate with 2 pilot teams, then expand to Tier 3 team images as demand grows. The infrastructure cost is low. A typical deployment of one org-wide image plus 5 team images produces around 50-80 builds per month, each running 3 to 5 minutes.

What's next

Ansible development workspaces governs the environment -- same tools, same versions, same image for every developer. The next piece is governing the content itself using the same practices, same conventions, same quality bar. The Ansible development tools MCP server brings AI-assisted development into this governed environment, turning your AI assistant into an Ansible-aware pair programmer that can scaffold, lint, test, and troubleshoot automation content without leaving the conversation. For the full technical walkthrough covering both workspaces and MCP server setup, see the AI-assisted Ansible developer experience solution guide.

Additional resources