Ansible Automation Platform 2.7 ships a visual Execution Environment (EE) Builder in Automation Portal — a four-step wizard that builds container-based EEs without hand-writing YAML. Step 1, Base Image, is where every EE starts: pick the Red Hat-provided image your automation content will run on. Here's what that choice produces under the hood.

# execution-environment.yml
# Generated definition after completing Step 1: Base Image
# in the AAP 2.7 Automation Portal EE Builder wizard.
---
version: 3

images:
  base_image:
    name: "registry.redhat.io/ansible-automation-platform-27/ee-minimal-rhel9:latest"
    # Recommended option selected in the wizard:
    # "Red Hat Ansible Minimal EE - Ansible Core 2.18 on RHEL 9"

dependencies:
  python: requirements.txt
  system: bindep.txt

additional_build_steps:
  append_final: []

What this does

The wizard's Step 1 screen lists five base image choices, each mapping to a Red Hat container image reference:

  • Red Hat Ansible Minimal EE — Ansible Core 2.18 on RHEL 9 (recommended, shown pre-selected)
  • A stable-channel variant of the Ansible Core 2.18 image
  • Red Hat Ansible Minimal EE — Ansible Core 2.16 on RHEL 9
  • A stable-channel variant of the Ansible Core 2.16 image
  • A fully custom base image, where you supply your own registry reference

Selecting one of the Red Hat-provided options simply pins images.base_image.name in the EE definition that the portal maintains for you — nothing else in the definition changes yet. The empty dependencies and additional_build_steps blocks are placeholders the wizard fills in during Step 2 (Configuration), when you search Private Automation Hub or GitHub for collections to add — for example redhat.rhel_system_roles at version 1.20.5 — and optionally add extra Python packages, system packages, or custom build steps via Advanced Configuration.

Choosing the minimal RHEL 9 / Ansible Core 2.18 image over the 2.16 line matters because content that depends on newer ansible-core features (module options, filter plugins, collection requirements) will only run correctly on the image version that ships that behavior. The "stable channel" variants track a slower-moving stream of the same base, useful when you want fewer unplanned image updates between builds.

Notes / Gotchas

  • Base image selection happens once per EE definition, in Step 1 — going back to change it later re-runs validation in Step 4 (Review) before any build kicks off.
  • If your playbooks or roles pin ansible-core version requirements, match the base image accordingly: Core 2.18 on RHEL 9 is the current recommended default, Core 2.16 on RHEL 9 remains available for existing content that hasn't been validated against 2.18 yet.
  • The "fully custom base image" option bypasses the Red Hat-maintained image catalog entirely — you own patching and Ansible Core version compatibility for that image.
  • Every EE definition, regardless of base image, shows up afterward in Automation Portal's searchable EE catalog with owner, tags, and star/edit/delete actions — useful for auditing which teams are still building against the 2.16 line.
  • Step 3 (Destination and Build) is where the definition actually gets published to a Git repository and, optionally, built immediately — the base image choice from Step 1 has no effect until that build runs.

Picking the right base image in Step 1 is a one-time decision with lasting consequences for compatibility, so default to the recommended Ansible Core 2.18 on RHEL 9 image unless existing content ties you to 2.16.

References