Using self-service automation portal


Red Hat Ansible Automation Platform 2.6

Use self-service automation portal

Red Hat Customer Content Services

Abstract

This guide describes how to use self-service automation portal to implement role-based access control and run automation.

Preface

Thank you for your interest in Red Hat Ansible Automation Platform. Ansible Automation Platform is a commercial offering that helps teams manage complex multi-tier deployments by adding control, knowledge, and delegation to Ansible-powered environments.

This guide describes how to add templates to your self-service automation portal instance, and how to launch them to run automation jobs. It also describes how to configure role-based access control (RBAC) so that you can restrict the teams and users who can run the jobs.

This document has been updated to include information for the latest release of Ansible Automation Platform.

Providing feedback on Red Hat documentation

If you have a suggestion to improve this documentation, or find an error, you can contact technical support at https://access.redhat.com to open a request.

Chapter 1. Overview

You can launch templates from self-service automation portal to execute job templates from your existing Ansible Automation Platform setup.

  • Auto-generated self-service templates are automatically synced from the job templates in Ansible Automation Platform to the self-service automation portal. The forms for the auto-generated templates are identical to the forms for the job templates.
  • You can import custom self-service templates from a Git repository. A configuration file links each custom template to a specific job template in Ansible Automation Platform and contains the forms that users must complete.

You can associate multiple custom self-service templates with a single Ansible Automation Platform job template. You can use role-based access control (RBAC) to assign different custom self-service templates for users with different levels of automation experience. For example, you can design a simplified template with a narrow scope for configuration for new users, and a more detailed template for automation experts.

Learn how to access and authenticate to the self-service automation portal using your Ansible Automation Platform credentials.

2.1. Signing in to self-service automation portal

Log in to the deployed self-service automation portal using your existing Ansible Automation Platform credentials. The portal uses these credentials for authentication.

Prerequisites

  • You have configured an OAuth application in Ansible Automation Platform for self-service automation portal.
  • You have configured a user account in Ansible Automation Platform.

Procedure

  1. In a browser, navigate to the URL for self-service automation portal to open the sign-in page.

    Self-service sign-in page
  2. Click Sign In.
  3. The sign-in page for Ansible Automation Platform appears:

    Ansible Automation Platform sign-in page
  4. Enter your Ansible Automation Platform credentials and click Log in.
  5. The self-service automation portal web console opens.

Troubleshooting

If you are using custom or self-signed SSL certificates and when attempting to log in to self-service automation portal, it displays the error:

Login failed; caused by Error: Failed to send POST request: fetch failed

This error indicates that self-service automation portal cannot verify the SSL certificate from your Ansible Automation Platform instance.

To resolve this issue, configure self-service automation portal to trust your custom CA certificate. For more information, see Section 2.2, “Configuring custom SSL certificates for self-service automation portal”.

Note

While you can disable SSL validation by setting checkSSL: false in the Helm chart configuration, this approach is not recommended for production environments as it reduces security. Instead, configure self-service automation portal to trust your custom CA certificate.

If your Ansible Automation Platform instance uses custom or self-signed SSL certificates, you must configure self-service automation portal to trust those certificates. Without this configuration, authentication between self-service automation portal and Ansible Automation Platform fails with SSL verification errors.

Prerequisites

  • You have administrator access to your OpenShift Container Platform cluster.
  • You have the custom Certificate Authority (CA) certificate file used by your Ansible Automation Platform instance.
  • self-service automation portal is installed in your OpenShift Container Platform cluster.

Procedure

  1. Obtain the CA certificate file from your Ansible Automation Platform instance.

    If you do not have the CA certificate file, you can extract it from your Ansible Automation Platform server:

    openssl s_client -showcerts -connect <aap-hostname>:443 </dev/null 2>/dev/null | openssl x509 -outform PEM > aap-ca-cert.pem

    Replace <aap-hostname> with your Ansible Automation Platform hostname.

  2. Log in to your OpenShift Container Platform cluster with administrator privileges.
  3. Create a ConfigMap containing your custom CA certificate:

    oc create configmap custom-ca-bundle \
      --from-file=ca-bundle.crt=aap-ca-cert.pem \
      -n <namespace>

    Replace <namespace> with the namespace where self-service automation portal is installed.

  4. Update your self-service automation portal Helm chart values to mount the custom CA certificate:

    upstream:
      backstage:
        extraEnvVarsSecrets:
          - custom-ca-bundle
        extraVolumes:
          - name: custom-ca
            configMap:
              name: custom-ca-bundle
        extraVolumeMounts:
          - name: custom-ca
            mountPath: /etc/pki/ca-trust/source/anchors/
            readOnly: true
  5. Apply the updated configuration by upgrading the self-service automation portal Helm chart:

    helm upgrade <release-name> <chart-name> \
      -f values.yaml \
      -n <namespace>

    Replace <release-name> with your Helm release name and <chart-name> with the self-service automation portal chart name.

  6. Wait for the self-service automation portal pods to restart with the new configuration.

Verification

  1. Verify that the self-service automation portal pods are running:

    oc get pods -n <namespace>

    All self-service automation portal pods should show a status of Running.

  2. Attempt to sign in to self-service automation portal using your Ansible Automation Platform credentials.

    If the SSL certificate configuration is correct, you can authenticate successfully without SSL verification errors.

  3. Check the self-service automation portal logs for SSL-related errors:

    oc logs -n <namespace> <pod-name> | grep -i ssl

    If you see no SSL verification errors, the custom CA certificate is trusted correctly.

Troubleshooting

If you continue to experience SSL verification errors after following this procedure:

  • Verify that the CA certificate file contains the complete certificate chain.
  • Ensure that the certificate file is in PEM format.
  • Confirm that the Ansible Automation Platform hostname in your configuration matches the hostname in the SSL certificate.
  • Check that the checkSSL parameter in your Helm values is set to true (the default). Setting it to false disables SSL verification entirely, which is not recommended for production environments.

2.3. Viewing templates

View your accessible automation templates, displayed as tiles, on the Templates landing page of the self-service automation portal console.

Prerequisites

  • You have signed in to self-service automation portal.

Procedure

  1. In a browser, sign in to self-service automation portal.
  2. In the navigation pane, select Templates to open a landing page where tiles are displayed, representing the templates that you have access to.

    Templates view

2.4. Synchronizing auto-generated templates

The auto-generated self-service templates are synchronized from the job templates in Ansible Automation Platform to self-service automation portal. You can manually trigger a sync from the Templates page.

Note

This synchronization fetches updates for auto-generated self-service templates only.

Procedure

  1. In a browser, sign in to self-service automation portal.
  2. In the navigation pane, select Templates to display the templates that you have access to.

    Templates view
  3. Select Sync now to launch a synchronization.

2.5. Viewing task run history

You can view a list of all the tasks that have been run from self-service automation portal. You can manually trigger a sync from the Templates page.

Procedure

  1. In a browser, sign in to self-service automation portal.
  2. In the navigation pane, select History.

    The Task list page displays the tasks that have been run.

    Templates view

Troubleshooting

If the Task List page does not display the tasks that have been run, contact your administrator to ensure that the scaffolder.task.read permission is selected in RBAC for your account.

Chapter 3. Working with templates

Understand how to deploy and manage both auto-generated and customized templates within the self-service automation portal to run your automation jobs.

3.1. Customized self-service templates

Custom self-service templates are stored as YAML files in repositories in GitHub or Gitlab. When a user launches a software template from self-service automation portal, they must fill in a form with the values needed to run the associated job template in Ansible Automation Platform.

The custom self-service template YAML file must have a token: section that includes a ui:field: key for the authentication token for Ansible Automation Platform. This generates a field for the token in the form that appears when the user launches the template in self-service automation portal. The user enters the token: it is used to authenticate job template execution in Ansible Automation Platform.

The following example shows the token: section in a template. For security reasons, set the value of token.ui:backstage.review.show to false to ensure that the token is not visible to the user.

spec:
  ...
  parameters:
    ...
      properties:
        token:
          title: Token
          type: string
          description: Oauth2 token
          ui:field: AAPTokenField
          ui:widget: hidden
          ui:backstage:
            review:
              show: false
Note

Setting the ui:widget: hidden field hides the Red Hat Ansible Automation Platform token input in the form.

3.2. Understanding auto-generated templates

self-service automation portal automatically generates templates from Ansible Automation Platform Job Templates. Each Ansible Automation Platform Job Template with the appropriate configuration becomes a template that users can execute from self-service automation portal.

Note

Templates in self-service automation portal use Backstage Software Templates as the underlying technology. For details on supported usage, see the self-service automation portal support policy.

Auto-generated templates include:

  • Form fields generated from Ansible Automation Platform Job Template Surveys and "Prompt on Launch" options.
  • Metadata (name, description, labels) mapped from Ansible Automation Platform Job Template properties.
  • A single step that launches the Ansible Automation Platform Job Template using the rhaap:launch-job-template action.
  • Output that displays the job execution results to the user.

Users only see and execute templates for Ansible Automation Platform Job Templates they have Job Template Execute permission in Ansible Automation Platform.

3.2.1. What users see

Auto-generated templates appear in the template catalog alongside custom templates. Users browse or search the catalog and select a template to run.

When a user opens an auto-generated template, self-service automation portal checks the Ansible Automation Platform Job Template for Prompt on Launch options and Survey questions. If the Job Template has Prompt on Launch options or Survey questions, self-service automation portal displays a form. Users select Ansible Automation Platform resources by name (such as Inventories or Credentials) and answer survey questions (such as application name or environment). self-service automation portal handles authentication automatically, so credentials are not visible on the form. If the Job Template has no Prompt on Launch options or Survey questions, the Job Template starts running automatically without displaying a form.

After the user submits the form or execution starts automatically, self-service automation portal launches the Ansible Automation Platform Job Template and displays an output page. The output page shows the job ID, job status, and optional links such as a direct link to the job in Ansible Automation Platform.

Users do not need to understand YAML or the template structure. The form collects the required input, and the output page displays the results.

3.2.2. Auto-generated template example

The following example shows a template that self-service automation portal auto-generates from an existing Ansible Automation Platform Job Template. Every field in the generated YAML maps directly to an Ansible Automation Platform artifact:

  • The Ansible Automation Platform Job Template name and description become metadata fields.
  • Each Prompt on Launch option becomes an AAPResourcePicker field.
  • Each Ansible Automation Platform Survey question becomes a standard form field.
  • The steps section launches the original Ansible Automation Platform Job Template using the rhaap:launch-job-template action.
apiVersion: scaffolder.backstage.io/v1beta3
kind: Template
metadata:
  # Namespace is hardcoded to "default"
  namespace: default
  # AAP artifact: Job Template name → lowercase with hyphens
  name: deploy-application
  # AAP artifact: Job Template name → title (copied directly)
  title: Deploy Application
  # AAP artifact: Job Template description → description (copied directly)
  description: Deploy application to target environment
  # AAP artifact: Job Template labels → tags (lowercase)
  tags:
    - automation
    - aap
  # AAP artifact: Job Template URL → annotations
  annotations:
    backstage.io/techdocs-ref: url:https://aap.example.com/#/templates/job_template/42
    backstage.io/source-location: url:https://aap.example.com/#/templates/job_template/42

spec:
  type: service

  parameters:
    - title: "Please enter the following details"
      required:
        - token
        - inventory
        - app_name
      properties:
        # Always present: OAuth token for AAP authentication (hidden from user)
        token:
          title: Token
          type: string
          description: Oauth2 token
          ui:field: AAPTokenField
          ui:widget: hidden
          ui:backstage:
            review:
              show: false
          ui:options:
            disabled: true
            hidden: true

        # AAP artifact: "Prompt on Launch" → Inventory (users select by name; self-service portal resolves to AAP ID)
        inventory:
          title: Inventory
          description: Please enter the inventory you want to use the services on
          resource: inventories
          ui:field: AAPResourcePicker
          default: Production Servers

        # AAP artifact: Survey question → "Application Name" (variable, title, type, default from survey spec)
        app_name:
          title: Application Name
          description: Name of the application to deploy
          type: string
          default: my-app

  steps:
    - id: launch-job
      # AAP artifact: Job Template name used as the step name
      name: Deploy Application
      action: rhaap:launch-job-template
      input:
        token: ${{ parameters.token }}
        values:
          # AAP artifact: Job Template name identifies which template to launch
          template: Deploy Application
          # "Prompt on Launch" values passed as launch parameters
          inventory: ${{ parameters.inventory }}
          # Survey answers passed as extra variables to AAP
          extraVariables:
            app_name: ${{ parameters.app_name }}

  output:
    text:
      - title: Deploy Application template executed successfully
        content: |
          **Job ID:** ${{ steps['launch-job'].output.data.id }}
          **Job status:** ${{ steps['launch-job'].output.data.status }}

The following table maps each generated field to its Ansible Automation Platform source:

Expand
Table 3.1. Field mapping
Ansible Automation Platform sourceAnsible Automation Platform valueGenerated fieldTransformation

N/A

default

metadata.namespace

Hardcoded to default.

Job Template → Name

Deploy Application

metadata.name

Lowercase with hyphens.

Job Template → Name

Deploy Application

metadata.title

Copied directly.

Job Template → Description

Deploy application to target environment

metadata.description

Copied directly.

Job Template → Labels

automation, aap

metadata.tags

Lowercase, special characters replaced with hyphens.

Always present

OAuth2 token

parameters.token

Auto-populated and hidden from user.

Prompt on Launch → Inventory

Production Servers

parameters.inventory

AAPResourcePicker; user selects by name, resolved to Ansible Automation Platform ID at launch.

Survey → Question 1

app_name (text, required, default: "my-app")

parameters.app_name

Variable, title, type, and default copied from Survey spec.

Job Template → Name

Deploy Application

input.values.template

Identifies which Ansible Automation Platform Job Template to launch.

Prompt on Launch value

${{ parameters.inventory }}

input.values.inventory

Name resolved to Ansible Automation Platform ID at launch.

Survey answers

${{ parameters.app_name }}

input.values.extraVariables

Passed as extra_vars to the Ansible Automation Platform Job.

3.2.3. How templates are generated

When synchronization runs, self-service automation portal reads Ansible Automation Platform Job Template configurations and generates corresponding templates. self-service automation portal maps Ansible Automation Platform Job Template properties to template fields as follows.

3.2.3.1. Metadata mapping

The following table shows how Ansible Automation Platform Job Template properties are mapped to template metadata fields:

Expand
Table 3.2. Metadata mapping
Ansible Automation Platform Job Template propertyGenerated template fieldTransformation

Name

metadata.name

Converted to lowercase with hyphens

Name

metadata.title

Copied directly

Description

metadata.description

Copied directly

Labels

metadata.tags

Converted to lowercase, special characters replaced with hyphens

N/A

metadata.namespace

Hardcoded to default

3.2.3.2. Parameter mapping

The following table shows how Ansible Automation Platform Job Template sources are mapped to template parameters:

Expand
Table 3.3. Parameter mapping
Ansible Automation Platform Job Template sourceGenerated template parameter type

Survey questions

Standard form fields (type: string, enum, ui:widget)

"Prompt on Launch" options

AAPResourcePicker fields for Ansible Automation Platform resources

3.2.3.3. Field order

self-service automation portal generates form fields from two sources in the Ansible Automation Platform Job Template configuration. Fields appear in the following order:

  1. OAuth token (hidden): Auto-populated with the user’s authentication token. This field is always present and always hidden.
  2. "Prompt on Launch" fields: Each enabled "Prompt on Launch" option becomes an AAPResourcePicker field. Users select Ansible Automation Platform resources by name (Inventories, Credentials, Execution Environments). self-service automation portal resolves names to Ansible Automation Platform internal IDs at launch time.
  3. Survey questions: Each survey question becomes a form field with the matching input type (text, dropdown, password, textarea, integer, float, multiplechoice, multiselect).
3.2.3.4. Defaults and required fields
  • Survey question defaults and required/optional settings are preserved from the Ansible Automation Platform Job Template Survey.
  • "Prompt on Launch" fields use the current Ansible Automation Platform Job Template settings for defaults and required/optional status.
  • Ansible Automation Platform resource picker fields display resource names, not internal IDs.

You can add a custom self-service template to the Templates view of your self-service automation portal instance. Custom self-service templates are stored in git repositories. self-service automation portal supports GitLab and GitHub Source Control Management (SCM).

Note

Names for custom self-service templates must be unique. Custom self-service templates must have a different name to auto-generated job templates and also to other custom self-service templates.

Prerequisites

  • You have created repositories in your Git SCM for the templates that you want to use.
  • In the git repository for your custom templates, ensure that the metadata.name field is unique and does not match an existing auto-generated template or another custom self-service template. For example, append *-custom to the value of the metadata.name key.
metadata:
  name: provision-database-custom
  • You must be logged in to self-service automation portal as an Ansible Automation Platform platform administrator.

Procedure

  1. In a browser, navigate to your self-service automation portal instance and sign in with your Ansible Automation Platform credentials.
  2. Navigate to the Templates Page.
  3. Click Add template.
  4. Enter a valid Git SCM URL for the template that you want to add.
  5. Click Analyze to fetch the template.
  6. After the template has been fetched, review the list of what will be imported and added to the catalog.
  7. Click Import.

Verification

After the import is complete, return to the Templates page to view the newly created template. You can now launch your template.

3.4. Launching a template

This procedure describes how to launch a template from a tile in the Templates view of your self-service automation portal instance.

Prerequisites

  • You have configured RBAC in Ansible Automation Platform for templates that are associated with Ansible Automation Platform job templates.

Procedure

  1. In a browser, navigate to your self-service automation portal instance and sign in with your Ansible Automation Platform credentials.
  2. Navigate to the Templates page. The templates you have set up are displayed as tiles on the page.
  3. In the template that you want to launch, click Start.

    A description of the template is displayed.

  4. Click Launch to begin configuring the parameters for running the template.
  5. Fill out the required fields.
  6. Click Next.
  7. Review the entered information.
  8. Click Create to launch the template.
  9. The progress for the template execution is displayed.

Custom self-service templates that you set up in self-service automation portal use a different set of RBAC rules than the RBAC rules for auto-generated self-service templates that are synchronized from Ansible Automation Platform.

  • Auto-generated self-service templates: The RBAC settings for these templates are synchronized from Ansible Automation Platform.
  • Custom self-service templates: You must set up RBAC for these templates in self-service automation portal.

By default, Ansible Automation Platform administrators can define self-service automation portal RBAC roles.

This procedure describes how to create a role in self-service automation portal that allows only a selected team to view and execute particular custom self-service templates.

Custom self-service templates in self-service automation portal are associated with job templates in Ansible Automation Platform. This association is set in the steps.actions section of the YAML file for the custom self-service template.

If you assign permissions to a particular team to launch a custom self-service template from self-service automation portal, then you must make sure that that team has permission to run the associated job templates in Ansible Automation Platform.

Prerequisites

  • You have created a user, for example example-user.
  • You have added this user as a member of a team, for example example-team.

Procedure

  1. In a browser, log in to your self-service automation portal instance as an Ansible Automation Platform user with Ansible Automation Platform administrator privileges.
  2. In the navigation panel, select AdministrationRBAC.
  3. In the RBAC view, click Create.

    The Create Role view appears.

    1. Enter a name for the role.
    2. In the Users and Groups section, select the Ansible Automation Platform teams and users to assign to this role.

      Select users and groups table showing Members column
      Note

      The Members column displays the total count of users in each team, including both regular team members and administrators.

    3. In the Add Permission policies section, select the plug-ins that you want to enable for the role.
    4. Select Permission in the list of plug-ins to configure the fine-grained permission policies for the role.
  4. Click Next.
  5. Review the settings that you have selected for the role.
  6. Click Create to create the role.

4.2. Verifying RBAC

This procedure describes how to verify that the role you set up is working correctly.

Procedure

  1. Verify that users with permissions can use a template:

    1. Log in to self-service automation portal as a user who is a member of a team that has been enabled to use a role.
    2. Verify that RBAC is applied and that the user can use the templates that you enabled for the role.
  2. Log out of self-service automation portal.
  3. Verify that users without permissions can not see or use a template:

    1. Log in to self-service automation portal as a user who is not a member of the new team that has been enabled to use the role.
    2. Verify that RBAC is applied and that the user cannot use the templates that you enabled for the role.
  4. Log out of self-service automation portal.

4.3. Deregistering custom self-service templates

You can deregister custom self-service templates. Deregistering templates deletes them from the Templates view in the self-service automation portal console.

Procedure

  1. In a browser, log in to self-service automation portal as a user with administrative privileges.
  2. Select Templates to display the self-service templates.
  3. For each custom self-service template that you want to delete, execute the following steps:

    1. Click a custom self-service template to open the Template detail view. The navigation bar contains the Unregister Template option.
    2. Click Unregister Template.

      Unregister template option
    3. In the dialog, confirm that you want to deregister the template.
    4. Click Delete Entity to unregister the template.

Verification

In a browser, navigate to the Templates view for your self-service automation portal instance. Verify that the custom self-service templates that you deregistered have been deleted.

The self-service automation portal is built on a Red Hat Developer Hub base image. It uses Backstage Software Templates, which are YAML-based workflow definitions that provide user forms to execute automation tasks in Ansible Automation Platform.

5.1. Overview

Learn how to use the custom actions, filters, and UI components provided by the Ansible Backstage Plugins to create and manage custom software templates for the self-service automation portal.

Important

Red Hat does not support the use of the Red Hat Developer Hub image for standalone purposes outside the scope of the Ansible Automation Platform self-service automation portal functionality. Refer to the official support policy for details.

5.2. Ansible backstage plugins

The portal’s capabilities are delivered through Ansible Backstage Plugins that extend Red Hat Developer Hub functionality; the base Red Hat Developer Hub image is not customized. These plugins provide additional Backstage actions and filters that you use to create custom software templates.

Expand
PluginFunctionality

auth-backend-module-rhaap-provider

Provides OAuth 2.0 authentication with Ansible Automation Platform.

catalog-backend-module-rhaap

Synchronizes Ansible Automation Platform job templates as Backstage Software Templates.

scaffolder-backend-module-backstage-rhaap

Provides the rhaap:launch-job-template action.

backstage-rhaap-common

Contains shared libraries and utilities for Ansible Automation Platform integration.

self-service

Provides the user interface for all listed functionality.

5.3. Custom backstage actions

The following actions enable you to manage Ansible Automation Platform resources within a software template workflow.

5.3.1. rhaap:create-project

Create an Ansible Automation Platform project that links to a source control repository containing Ansible content.

Input parameters

Expand
ParameterTypeRequiredDescription

token

string

Yes

OAuth2 token for Ansible Automation Platform authentication.

deleteIfExist

boolean

No

If true, the action deletes the project if it already exists before creating a new one.

values

object

Yes

The project configuration object. See the "values" Object Structure table.

“values” Object Structure

Expand
FieldTypeRequiredDescription

projectName

string

Yes

Name of the project.

projectDescription

string

No

Description of the project.

organization

object

Yes

Organization object with id (number, required) and name (string, optional).

credentials

object

No

Credential object with id (number, required), name (string, optional), and kind (string, optional).

scmUrl

string

Yes

Source control URL (for example, GitHub/GitLab repository URL).

scmBranch

string

No

Source control branch, tag, or commit.

scmUpdateOnLaunch

boolean

No

If true, updates the project revision before each job run.

Output parameters

Expand
ParameterTypeDescription

project

object

Created project details.

project.id

number

Project ID in Ansible Automation Platform (AAP).

project.name

string

Project name.

project.description

string

Project description.

project.url

string

Ansible Automation Platform URL for the project.

Example

steps:
  - id: create-aap-project
    name: Create AAP Project
    action: rhaap:create-project
    input:
      token: ${{ parameters.AAP_TOKEN }}
      deleteIfExist: true
      values:
        projectName: ${{ parameters.projectName }}
        organization: ${{ parameters.organization }}
        scmUrl: https://github.com/my-org/ansible-playbooks
        scmBranch: main
        scmUpdateOnLaunch: true
        credentials: GitHub Token

5.3.2. rhaap:create-execution-environment

Create an execution environment in Ansible Automation Platform that defines the container image used to run Ansible jobs.

Input parameters

Expand
ParameterTypeRequiredDescription

token

string

Yes

OAuth2 token for Ansible Automation Platform authentication.

deleteIfExist

boolean

No

If true, the action deletes the execution environment if it already exists.

values

object

Yes

The execution environment configuration object.

“values” Object Structure

Expand
FieldTypeRequiredDescription

environmentName

string

Yes

Name of the execution environment.

environmentDescription

string

No

Description of the execution environment.

organization

object

Yes

Organization object with required id (number) and optional name (string).

image

string

Yes

Full image location, including registry, image name, and tag (for example, quay.io/ansible/creator-ee:latest).

pull

string

No

Image pull policy: always, missing, or never. Default is missing.

Output parameters

Expand
ParameterTypeDescription

executionEnvironment

object

Created execution environment details.

executionEnvironment.id

number

Execution environment ID.

executionEnvironment.name

string

Execution environment name.

executionEnvironment.description

string

Execution environment description.

executionEnvironment.url

string

Ansible Automation Platform (AAP) URL for the execution environment.

Example

steps:
  - id: create-ee
    name: Create Execution Environment
    action: rhaap:create-execution-environment
    input:
      token: ${{ parameters.AAP_TOKEN }}
      deleteIfExist: false
      values:
        environmentName: Custom EE
        environmentDescription: Execution environment with custom collections
        organization: ${{ parameters.organization }}
        image: quay.io/ansible/creator-ee:v0.16.0
        pull: missing

5.3.3. rhaap:create-job-template

Create a job template in Ansible Automation Platform that defines a reusable configuration for running Ansible playbooks.

Input parameters

Expand
ParameterTypeRequiredDescription

token

string

Yes

OAuth2 token for Ansible Automation Platform authentication.

deleteIfExist

boolean

No

If true, the action deletes the job template if it already exists.

values

object

Yes

The job template configuration object.

“values” Object Structure

Expand
FieldTypeRequiredDescription

templateName

string

Yes

Name of the job template.

templateDescription

string

No

Description of the job template.

project

object

Yes

Project object with required id (number) and optional name (string).

organization

object

No

Organization object with id (number, required) and name (string, optional).

jobInventory

object

Yes

Inventory object with required id (number) and optional name (string).

playbook

string

Yes

Path to the playbook file to execute.

templateDescription

string

No

Description of the job template.

scmType

string

No

Source control type (for example, Github or Gitlab).

executionEnvironment

object

No

Execution environment object with required id (number) and optional name (string).

extraVariables

object

No

Extra variables to pass to the playbook (key-value pairs).

Output parameters

Expand
ParameterTypeDescription

template

object

Created job template details.

template.id

number

Job template ID.

template.name

string

Job template name.

template.description

string

Job template description.

template.url

string

Ansible Automation Platform (AAP) URL for the job template.

Example

steps:
  - id: create-job-template
    name: Create Job Template
    action: rhaap:create-job-template
    input:
      token: ${{ parameters.AAP_TOKEN }}
      deleteIfExist: true
      values:
        templateName: Deploy Application
        templateDescription: Deploys the application to production
        project: ${{ steps['create-aap-project'].output.project }}
        organization: ${{ parameters.organization }}
        jobInventory: ${{ parameters.jobInventory }}
        playbook: deploy.yml
        executionEnvironment: ${{ steps['create-ee'].output.executionEnvironment }}
        extraVariables:
          app_version: 1.0.0
          environment: production

5.3.4. rhaap:launch-job-template

Launch an existing job template in Ansible Automation Platform.

Input parameters

Expand
ParameterTypeRequiredDescription

token

string

Yes

OAuth2 token for Ansible Automation Platform authentication.

values

object

Yes

The job launch configuration object.

“values” Object Structure

Expand
FieldTypeRequiredDescription

template

string

Yes

Job template name to launch.

inventory

object

No

Override inventory with id (number) and name (string).

credentials

array

No

Array of credential objects to use.

extraVariables

object

No

Extra variables to pass to the job (key-value pairs).

limit

string

No

Host pattern to constrain which hosts the job runs against.

jobType

string

No

Job type: run or check.

executionEnvironment

object

No

Override execution environment with id (number) and name (string).

verbosity

object

No

Verbosity level object with id and name.

forks

number

No

Number of parallel processes (default: 5).

jobSliceCount

number

No

Divide the job into N slices.

timeout

number

No

Job timeout in seconds (0 = no timeout).

diffMode

boolean

No

Enable diff mode to show changes.

jobTags

string

No

Comma-separated tags to run only specific tasks.

skipTags

string

No

Comma-separated tags to skip specific tasks.

Output parameters

Expand
ParameterTypeDescription

data

object

Job execution details.

data.id

number

Job ID.

data.status

string

Job status.

data.url

string

Ansible Automation Platform (AAP) URL for the job.

Example

steps:
  - id: launch-job
    name: Launch Job Template
    action: rhaap:launch-job-template
    input:
      token: ${{ parameters.AAP_TOKEN }}
      values:
        template: Deploy Application
        inventory: ${{ parameters.jobInventory }}
        credentials: ${{ parameters.credentials }}
        extraVariables:
          app_version: v1.0.1
          deploy_env: production
        jobType: run
        verbosity: Normal
        diffMode: true
        timeout: 3600

5.3.5. Example with all backstage actions present

The following example displays how you can use multiple actions together.

apiVersion: scaffolder.backstage.io/v1beta3
kind: Template
metadata:
  name: ansible-complete-setup
  title: Complete Ansible Setup
  description: Creates an Ansible project, execution environment, job template, and launches it
spec:
  owner: platform-team
  type: service

  parameters:
    - title: Project Information
      required:
        - projectName
        - repoUrl
      properties:
        projectName:
          title: Project Name
          type: string
          description: Name of the Ansible project
        repoUrl:
          title: Repository URL
          type: string
          description: Git repository URL containing Ansible content

    - title: AAP Configuration
      required:
        - organization
        - jobInventory
        - credentials
      properties:
        organization:
          title: Organization
          type: string
          description: AAP Organization name
          default: 1-org
          ui:field: hidden  # To hide this field in the UI
        jobInventory:
          title: Inventory name
          type: string
          description: AAP Inventory name
          resource: inventories
          ui:field: AAPResourcePicker
          default: my-inventory
        credentials:
          title: Credentials
          description: Select SCM credential for Private repositories
          resource: credentials
          ui:field: AAPResourcePicker
          default: my-machine-credential
  steps:
    # Step 1: Create AAP Project
    - id: create-project
      name: Create AAP Project
      action: rhaap:create-project
      input:
        token: ${{ parameters.AAP_TOKEN }}
        deleteIfExist: true
        values:
          projectName: ${{ parameters.projectName }}
          organization: ${{ parameters.organization }}
          scmUrl: ${{ parameters.repoUrl }}
          scmBranch: main
          scmUpdateOnLaunch: true

    # Step 2: Create Execution Environment
    - id: create-ee
      name: Create Execution Environment
      action: rhaap:create-execution-environment
      input:
        token: ${{ parameters.AAP_TOKEN }}
        values:
          environmentName: ${{ parameters.projectName }}-ee
          organization: ${{ parameters.organization }}
          image: quay.io/ansible/creator-ee:latest
          pull: missing

    # Step 3: Create Job Template
    - id: create-template
      name: Create Job Template
      action: rhaap:create-job-template
      input:
        token: ${{ parameters.AAP_TOKEN }}
        values:
          templateName: ${{ parameters.projectName }}-deploy
          templateDescription: Deployment job template
          project: ${{ steps['create-project'].output.project }}
          organization: ${{ parameters.organization }}
          jobInventory: ${{ parameters.jobInventory }}
          playbook: site.yml
          executionEnvironment: ${{ steps['create-ee'].output.executionEnvironment }}

    # Step 4: Launch the Job
    - id: launch-job
      name: Launch Job
      action: rhaap:launch-job-template
      input:
        token: ${{ parameters.AAP_TOKEN }}
        values:
          template: ${{ parameters.projectName }}-deploy
          inventory: ${{ parameters.jobInventory }}
          credentials: ${{ parameters.credentials }}
          jobType: run
          extraVariables:
            created_by: backstage
            timestamp: ${{ '' | now }}

  output:
    links:
      - title: AAP Project
        url: ${{ steps['create-project'].output.project.url }}
      - title: Job Template
        url: ${{ steps['create-template'].output.template.url }}
      - title: Job Execution
        url: ${{ steps['launch-job'].output.data.url }}

5.4. Custom UI components and filters

The Ansible Backstage Plugins provide custom UI components that enhance the software template experience by integrating directly with Ansible Automation Platform resource selection and authentication.

5.4.1. AAPTokenField

The AAPTokenField is a secure authentication field used in backstage scaffolder templates. It automatically fetches and stores an Ansible Automation Platform OAuth2 token, which is then available for all rhaap:* actions, enabling seamless authentication.

AAPTokenField Properties

The following table details the field’s properties for use in a template’s properties section.

Expand
PropertyTypeDescription

title

string

The label displayed in the UI (for example, "AAP Token"). Defaults to "AAP Token".

description

string

A short help text displayed below the input field.

ui:field

string

Must be set to AAPTokenField. This setting instructs Backstage to render a custom react component instead of a default input field.

ui:backstage.review.show

boolean

If true, this field appears in the Review step before scaffolding executes. The default value is true.

Authentication flow and token management

All rhaap:* actions require an OAuth2 token for authenticating with Ansible Automation Platform. The field manages the token through the following process:

  • Token Source: The token is automatically obtained from the Ansible Automation Platform OAuth2 authentication provider.
  • Storage: The token is stored securely in Backstage secrets or fetched through the @ansible/backstage-plugin-auth-backend-module-rhaap-provider.
  • Usage: The token is passed to each action using the token input parameter.

When the RHAAP auth provider is used, the token is injected automatically and can be referenced in the workflow steps as shown:

  - id: create-project
    action: rhaap:create-project
    input:
      token: ${{ parameters.AAP_TOKEN }}
      # ... other inputs

Example

The following example shows how to declare and reference the AAPTokenField within a backstage template. Note that ui:widget: hidden and ui:backstage: review: show: false are used to ensure the token is not exposed in the UI.

apiVersion: scaffolder.backstage.io/v1beta3
kind: Template
metadata:
  name: my-AAP-template
  title: Example AAP Template
spec:
  parameters:
    - title: Authentication
      properties:
        token:
          title: AAP Authentication Token
          type: string
          description: Oauth2 token
          ui:field: AAPTokenField
          ui:widget: hidden
          ui:backstage:
            review:
              show: false
  steps:
    - id: launch-job
      name: Launch AAP Job Template
      action: rhaap:launch-job-template
      input:
        token: ${{ parameters.token }}
        ...

Error and validation handling

All rhaap:* actions include built-in validation and user-friendly error reporting:

  • Validation: If the token is missing or invalid, the action throws the error: "`Authorization token not provided`."
  • Error Messages: Actions catch API client errors, extracting and surfacing meaningful messages without exposing stack traces.
  • Workflow Safety: If a step fails due to authentication, subsequent steps are automatically skipped, ensuring a safe and predictable workflow.

5.4.2. AAPResourcePicker

The AAPResourcePicker is a dynamic field for backstage scaffolder templates. It fetches and displays a list of Ansible Automation Platform resources (such as inventories, organizations, or credentials) directly from the Ansible Automation Platform API, allowing users to select a resource for their automation workflow.

AAPResourcePicker Properties

The following table details the essential properties for configuring the resource picker in a template’s properties section.

Expand
PropertyTypeDescription

title

string

The label displayed in the UI (for example, "Inventory").

description

string

A short help text shown below the field.

ui:field

string

Must be set to AAPResourcePicker.

resource

string

The specific Ansible Automation Platform (AAP) resource type to fetch and display (for example, inventories, credentials, or organizations).

idKey

string

The property name used to retrieve the resource ID (default: id).

nameKey

string

The property name used to display the resource name in the list (default: name).

type

string

Set to array for a multi-select field; omit this property for a single-select field.

Example

The following example demonstrates how to use the AAPResourcePicker to create a single-select field for choosing an Inventory.

apiVersion: scaffolder.backstage.io/v1beta3
kind: Template
metadata:
  name: my-AAP-template
  title: Example AAP Template
spec:
  parameters:
    - title: Authentication
      properties:
        jobInventory:
          title: Inventory
          description: Select inventory
          resource: inventories
          ui:field: AAPResourcePicker
          default: DemoInventory

5.4.3. Custom filters

The plugins provide custom filters to extract specific properties from resource objects, which is essential for passing data between backstage steps.

Expand
FilterPurposeExample Usage

resourceFilter

Extracts a single, specific property from a resource object.

`$!{{ parameters.organization

resourceFilter('name') }}`

multiResourceFilter

Extracts a specific property from multiple resource objects (when the input is an array).

5.5. Standard UI widgets

Standard UI widgets provide enhanced components for user forms to capture various types of input.

5.5.1. Textarea widget

The textarea widget renders a multi-line text input field for capturing long-form user input such as descriptions or configuration content.

properties:
  description:
    type: string
    title: Description
    ui:widget: textarea
    ui:options:
      rows: 5
      placeholder: "Enter description..."

5.5.2. Select widget

The select widget displays a dropdown menu that enables users to choose a single value from a predefined list of options.

properties:
  environment:
    type: string
    title: Environment
    enum: ['dev', 'staging', 'prod']
    ui:widget: select
    default: 'dev'

5.5.3. Checkboxes widgets

The checkboxes widget renders a group of checkboxes, enabling the selection of multiple options from a list. The original plural "Checkboxes Widgets" is corrected to the singular form for style consistency.

properties:
  features:
    type: array
    title: Base Images
    items:
      type: string
      enum: ['baseImage1', 'baseImage2', 'baseImage3']
    ui:widget: checkboxes
    uniqueItems: true

5.5.4. Hidden widget

The hidden widget holds a fixed or prefilled value that is not visible to the user but is included in the submitted data. Use this widget for passing non-user-editable data, such as authentication tokens.

kind: Template
metadata:
  name: my-AAP-template
  title: Example AAP Template
spec:
  parameters:
    - title: Authentication
      properties:
        token:
          title: AAP Authentication Token
          type: string
          description: Oauth2 token
          ui:field: AAPTokenField
          ui:widget: hidden
          ui:backstage:
            review:
              show: false
  steps:
    - id: launch-job
      name: Launch AAP Job Template
      action: rhaap:launch-job-templat
      input:
        token: ${{ parameters.token }}
      ...

5.6. Parameter types and field options

The parameters section in a template defines the form fields that users complete before execution. Each property in parameters.properties renders as a form field. This section documents the available types, widgets, and validation options you can use when building custom templates.

5.6.1. Supported parameter types

Templates support standard Backstage parameter types (string, number, integer, boolean, array) and widgets (textarea, select, checkboxes, hidden). For a complete reference of standard types and widgets, see the Backstage Software Templates documentation.

self-service automation portal adds the following Ansible Automation Platform-specific field types:

Expand
Table 5.1. Ansible Automation Platform-specific field types
TypeWidgetDescriptionExample use case

ui:field: AAPTokenField

Hidden token field

OAuth2 authentication token, auto-populated and hidden from the user.

Always present in auto-generated templates.

resource + ui:field: AAPResourcePicker

Ansible Automation Platform resource picker (single-select)

Select one Ansible Automation Platform resource by name.

Inventory, organization.

type: array + ui:field: AAPResourcePicker

Ansible Automation Platform resource picker (multi-select)

Select multiple Ansible Automation Platform resources by name.

Credentials.

These Ansible Automation Platform-specific fields are documented in detail in AAP resource picker fields.

5.6.2. AAP resource picker fields

Use ui:field: AAPResourcePicker to let users select Ansible Automation Platform resources by name. self-service automation portal queries the Ansible Automation Platform API and displays available resources in a picker. Set the resource property to specify the Ansible Automation Platform resource type.

The following table lists supported resource values:

Expand
Table 5.2. Supported resource values
resource valueAnsible Automation Platform resource typeSelection mode

inventories

Inventories

Single-select

credentials

Credentials

Multi-select (type: array)

organizations

Organizations

Single-select

5.6.2.1. Single-select example (inventory)
inventory:
  title: Inventory
  description: Select target inventory.
  resource: inventories
  ui:field: AAPResourcePicker
  default: Production Servers
5.6.2.2. Multi-select example (credentials)
credentials:
  title: Credentials
  description: Select credentials for accessing the target hosts.
  type: array
  resource: credentials
  ui:field: AAPResourcePicker
  default:
    - SSH Key
    - AWS Credentials

5.7. Dynamic fields

Dynamic fields appear or disappear based on user selections. Use the dependencies keyword with allOf and if/then to define conditional field visibility. This lets you build forms where selecting a value in one field reveals additional fields relevant to that selection.

Dynamic fields are useful for:

  • Showing advanced options only when the user enables them.
  • Displaying different configuration fields based on a resource type or category selection.
  • Requesting a reason or justification when the user selects a specific option.

5.7.1. Showing or hiding fields based on a toggle

Use a boolean toggle field to show or hide a group of additional fields.

In this example, selecting "Show advanced options" reveals one additional field. When the toggle is off, the field is hidden and not submitted.

parameters:
  - title: Time server settings
    required:
      - ntpServers
    properties:
      ntpServers:
        title: NTP servers
        type: string
        default: 0.rhel.pool.ntp.org, 1.rhel.pool.ntp.org
      showAdvanced:
        title: Show advanced options?
        type: boolean
        default: false
    dependencies:
      showAdvanced:
        allOf:
          - if:
              properties:
                showAdvanced:
                  const: true
            then:
              properties:
                maxSyncDelay:
                  type: number
                  title: Max sync delay (ms)
                  default: 500

When showAdvanced is true, the form displays maxSyncDelay. When showAdvanced is false, the field is hidden.

Use an enum field with dependencies and allOf to display different configuration fields for each option.

In this example, selecting a database type reveals a version dropdown specific to that engine:

    properties:
      dbType:
        title: Database type
        type: string
        enum:
          - PostgreSQL
          - MySQL
    dependencies:
      dbType:
        allOf:
          - if:
              properties:
                dbType:
                  const: PostgreSQL
            then:
              properties:
                version:
                  type: number
                  enum: [13, 14, 15]
                  title: PostgreSQL version
                  default: 15
          - if:
              properties:
                dbType:
                  const: MySQL
            then:
              properties:
                version:
                  type: string
                  enum: ['5.7', '8.0']
                  title: MySQL version
                  default: '8.0'

Each if/then block in the allOf array matches one enum value. Selecting "PostgreSQL" shows the PostgreSQL version list; selecting "MySQL" replaces it with the MySQL version list.

5.7.3. Chaining multiple dynamic dependencies

You can define multiple dependencies in the same parameter step. Each dependency operates independently.

In this example, selecting "Yes" for the restart confirmation reveals a reason field, while enabling advanced options reveals additional technical fields:

    dependencies:
      showAdvanced:
        allOf:
          - if:
              properties:
                showAdvanced:
                  const: true
            then:
              properties:
                maxSyncDelay:
                  type: number
                  title: Max sync delay (ms)
                  default: 500
      serviceRestart:
        allOf:
          - if:
              properties:
                serviceRestart:
                  const: 'Yes'
            then:
              properties:
                restartReason:
                  type: string
                  title: Reason for restart
                  description: Provide a reason for restarting the service.
                  default: Applying new configuration.
                  minLength: 10
                  errorMessage:
                    minLength: 'Provide a more detailed reason (at least 10 characters).'

Each key under dependencies corresponds to a property name in the same parameter step. When the user changes a field value, only the matching if/then branch is displayed.

5.8. Configuring the output section

The output section defines what users see after a template runs. You can display text messages, reference user input from parameters, show job execution data from steps, and provide external links.

The output section supports two types of content:

  • text: Displays text blocks with titles and markdown content.
  • links: Displays clickable buttons that open external URLs.

5.8.1. Output text

Use output.text to display information to the user after the template runs. Each text block has a title and content field. The content field supports markdown formatting.

output:
  text:
    - title: Request submitted
      content: |
        Your request has been submitted.

You can include multiple text blocks:

output:
  text:
    - title: Request submitted
      content: |
        Your deployment of **${{ parameters.app_name }}** has been submitted.

        **Job ID:** ${{ steps['launch-job'].output.data.id }}
        **Status:** ${{ steps['launch-job'].output.data.status }}

    - title: Configuration summary
      content: |
        - Inventory: ${{ parameters.inventory }}
        - Application: ${{ parameters.app_name }}

5.8.3. Referencing parameters in output

You can reference any value the user entered in the parameters section by using the ${{ parameters.<field_name> }} syntax.

The following table lists common parameter references:

Expand
Table 5.3. Common parameter references
ReferenceDescriptionExample output

${{ parameters.app_name }}

User-entered text field value

my-app

${{ parameters.inventory }}

User-selected Ansible Automation Platform resource name

Production Servers

${{ parameters.credentials }}

User-selected credentials (array)

["SSH Key", "AWS Credentials"]

${{ parameters.environment }}

User-selected enum value

production

output:
  text:
    - title: Request submitted
      content: |
        Your request for **${{ parameters.app_name }}** has been submitted.

        **Configuration:**
        - Inventory: ${{ parameters.inventory }}
        - Environment: ${{ parameters.environment }}

5.8.4. Referencing step output in output

After the rhaap:launch-job-template action runs, the step output includes job execution data. Reference this data using the ${{ steps['<step-id>'].output.data.<field> }} syntax.

The rhaap:launch-job-template action returns the following output fields:

Expand
Table 5.4. Output fields from rhaap:launch-job-template
ReferenceTypeDescription

${{ steps['launch-job'].output.data.id }}

number

Ansible Automation Platform Job ID.

${{ steps['launch-job'].output.data.status }}

string

Ansible Automation Platform Job status (for example, pending, running, successful).

${{ steps['launch-job'].output.data.url }}

string

Direct URL to the job in Ansible Automation Platform.

output:
  text:
    - title: Job launched
      content: |
        **Job ID:** ${{ steps['launch-job'].output.data.id }}
        **Status:** ${{ steps['launch-job'].output.data.status }}
  links:
    - title: View job in Ansible Automation Platform
      url: ${{ steps['launch-job'].output.data.url }}

Create custom execution environment (EE) definitions through self-service automation portal using the EE Builder.

Note

Technology Preview features are not supported with Red Hat production service level agreements (SLAs) and might not be functionally complete. Red Hat does not recommend using them in production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process.

For more information about the support scope of Red Hat Technology Preview features, see Technology Preview Features Support Scope.

6.1. The Execution Environment Builder

The Execution Environment (EE) Builder in self-service automation portal enables you to create custom execution environment definitions through a guided UI wizard or backend configuration methods.

The EE Builder provides both a user-friendly web interface and flexibility for advanced users who prefer configuration-based approaches. When you use the UI wizard, the builder generates the necessary definition files and can publish them to your Git repository or provide them as a download.

The builder supports two primary workflows:

  • UI wizard: A step-by-step interface that guides you through selecting base images, collections, Python and system requirements, MCP servers, and additional build steps
  • Backend methods: Configuration through Helm charts and direct file management for users who require programmatic control

The generated execution environment definition includes:

  • execution-environment.yml: The main definition file specifying your environment configuration
  • requirements.yml: Ansible collections required by your environment
  • requirements.txt: Python dependencies
  • bindep.txt: System-level package dependencies
  • Template file: A reusable software template for sharing your configuration

When you publish to a Git repository, the EE Builder creates or updates the repository with all generated files and can create a pull request if the repository already exists.

An administrator must enable the EE definition files feature in the configuration to display it in the left navigation panel.

To enable the EE definition files feature, you must modify the enabled key in your Helm chart configuration.

Procedure

  1. Open the configuration file for your Helm chart.
  2. Navigate to the default.main-menu-items section.
  3. Set the value of the enabled key under the default.ee configuration block to true.

    Note

    Setting enabled: true enables the EE definition files feature for all users.

    Example

    The final configuration must look like the following example:

    default.main-menu-items:
      menuItems:
        default.mycatalog:
          title: Templates
          icon: home
          to: /self-service/catalog
          priority: 120
        default.myitem:
          title: History
          icon: category
          to: /self-service/create/tasks
          priority: 110
        default.ee:
          enabled: false

Understand how to successfully plan and configure your custom execution environment (EE) definition. Review the available options for base images, automation presets, and dependency requirements before you start the creation process to ensure your EE supports your organization’s automation content.

6.3.1. Execution Environment (EE) definition

The components and configurations for defining your EE are organized into two main categories: Pre-defined templates (presets) and custom components.

6.3.2. Predefined execution environment templates

Predefined execution environment (EE) templates are preconfigured templates that accelerate environment setup for common use cases. These templates include specific base images, collections, and dependencies tailored for each domain.

Expand
PresetDescriptionKey considerations and use cases

Start from scratch

A blank-slate template for creating custom execution environments.

Use this preset when you require complete control over the base image and dependencies to build a highly customized or minimized execution environment.

Networking Automation

A template optimized for network device interaction and network-specific content.

Use this preset when your automation primarily interacts with switches, routers, firewalls, and other network infrastructure.

Cloud Automation

A template optimized for deploying and managing cloud resources (such as AWS or Microsoft).

Use this preset when your automation targets provisioning, configuration, and management of cloud services.

6.3.3. Disabling pre-built templates

For environments where these pre-built templates are not needed or conflict with organizational standards, they can be disabled in the Helm chart configuration.

Procedure

  • You can disable pre-built templates by commenting them out in the Helm chart configuration. The following is an example of all three pre-built templates commented out:

    catalog:
      locations:
        # Local templates
        - type: file
          target: ../../examples/entities.yaml
    
        # The following Ansible pre-built templates are disabled:
        # - type: url
        #   target: https://github.com/ansible/ansible-rhdh-templates/blob/main/templates/ee-start-from-scratch.yaml
        # - type: url
        #   target: https://github.com/ansible/ansible-rhdh-templates/blob/main/templates/ee-network-automation.yaml
        # - type: url
        #   target: https://github.com/ansible/ansible-rhdh-templates/blob/main/templates/ee-cloud-automation.yaml

6.3.4. Components for custom EE definitions

When creating a custom EE, you define the core underlying elements that dictate the environment’s capabilities, security, and dependencies. These components are used to define the custom EE, and are also utilized internally by the pre-defined presets.

Expand
Component or settingDescriptionKey considerations and examples

Base images

The foundation layer of your EE, pre-configured with a specific operating system and toolset.

By default, the following base images are available in all 3 pre-defined templates:

  • Red Hat Ansible Minimal EE - Ansible Core 2.18 (RHEL 8)
  • Red Hat Ansible Minimal EE - Ansible Core 2.18 (RHEL 9)
  • Red Hat Ansible Minimal EE - Ansible Core 2.16 (RHEL 8)
  • Red Hat Ansible Minimal EE - Ansible Core 2.16 (RHEL 9)

Select a base image that aligns with your organization’s security and Python compatibility needs. Popular base images are optimized for minimal overhead or specific compliance requirements.

If you are providing a custom image, it must include ansible-core and ansible-runner.

Collections

Specifies the Ansible Collections and Python libraries required by your automation content.

Ensure all necessary content is included from the documentation’s list. You can add collections manually or upload a requirements.yml file.

When collections overlap, the system merges the contents. If duplicates occur:

  • If a version is not specified, the system prioritizes the collection using the most recent version available.
  • If versions are explicitly specified for both collections, the system defaults to using the most recent version.

Python requirements

Defines the minimum Python version and any extra Python packages required for this execution environment.

Must reflect the version compatibility used across your organization for running automation reliably.

Avoid repeating Python requirements already specified as a dependency by the selected collections (for example, in their respective requirements.txt files).

System packages

Operating system (OS) libraries and packages required by the Python packages or collections.

Defines the extra OS libraries and packages required by the Python packages or collections listed in the EE.

Examples: git, gcc, python3-devel. These are necessary for compiling Python packages during the build process.

This list supplements, and must not repeat, any base OS dependencies already managed by your environment’s build system.

Additional build steps

Additional build steps are custom shell commands injected directly into the container runtime instruction file.

Use additional build steps to perform actions like installing private certificates or configuring environment variables not covered by standard package installation.

The EE Builder supports the optional integration of a Model Context Protocol (MCP) server. MCP servers are an advanced feature used to expose automation actions to AI assistants or other cognitive services.

If you select an MCP server, the EE Builder automatically handles the necessary configuration files and dependencies. This portal feature generates execution environment definition files for building an execution environment with your selected MCP servers.

The EE Builder currently supports the following MCP servers:

  • Git Hub
  • AWS

    • AWS CCAPI
    • AWS CDK
    • AWS IAM
    • AWS Core
  • Azure

You can use the Execution Environment (EE) Builder in the self-service automation portal to create custom EE definitions through a guided workflow.

Prerequisites

Procedure

  1. Log into the self-service automation portal and select EE definition files from the lefthand navigation pane.
  2. If this is your first time creating an EE definition file, click Create Execution Environment definition file, otherwise select the Create tab.
  3. Click Start on your preferred template.
  4. Select your preferred base image and click Next.

    Note

    Red Hat recommends using the Red Hat Minimal EE base. If selecting Custom Image, it is important you fully understand what the contents of your base image are. For example, a base image without Ansible core or Ansible runner will fail to build.

  5. Select a collection from Add popular Collections or Add Collection Manually and click Next.

    1. Optional: To add additional Python or System requirements, select Specify additional python requirements and system packages, and then click Add packages manually or Choose File.
  6. Select your desired MCP servers and click Next.
  7. Optional: In the Additional Build Steps section, you can specify custom build instructions that will be executed at specific steps during the build process:

    1. Select Add build Step.
    2. Select a step from the Step type drop-down list.
    3. Input a command you want to run at that step. You can provide a string of commands by giving each command a new line.
    4. Click Next.
  8. In the Generate and publish section:

    1. Fill in the following mandatory fields:

      • EE File name
      • Description
      • Select source control provider
      • SCM repository organization name or username
      • Repository name
    2. Ensure the execution-environment tag is applied. Click the plus (+) icon to add additional tags if required.
    3. Ensure Publish to a Git repository is selected. If unselected, your EE will be provided as a download after the build process.
    4. If the Repository name you provided does not already exist, select Create new repository. If it does exist and you check the box, a pull request will be created instead.
    5. Click Next.
  9. Confirm your details are correct and click Create. This begins the scaffolding process.
  10. After the scaffolding is complete, click Getting started for next steps on how to build your EE definition.

Verification

Verify the creation and deployment of the EE definition file using one of the following methods:

  1. In the self-service automation portal:

    1. Click View details in catalog or Download EE files (downloads the generated files as a .tar file).
    2. Alternatively, select EE definition files in the left-hand navigation pane. The new file appears in the Execution Environment definition files box.
  2. In the repository:

    1. Click GitHub repository or Gitlab repository to confirm the files were scaffolded into your repository.

6.6. Importing your custom EE definition

The EE definition workflow generates a reusable software template, named <ee-name>-template.yaml. This template includes the specified default configurations when you select Publish to a Git repository during the creation of your custom EE definition.

The template is also generated for non-SCM based publishings.

You can import this template into the self-service automation portal to make the default configuration available to others.

Prerequisites

  • You have installed the self-service automation portal.
  • You have the EE Builder feature enabled.
  • You have a custom EE definition hosted in a repository.

Procedure

  1. Go to the repository where your <ee-name>-template.yaml is stored and open it.
  2. Copy the URL of the template.yaml page.
  3. Log into the self-service automation portal and select EE definition files from the lefthand navigation pane.
  4. Click Create > Add Template.
  5. Paste the template URL into the Select URL field and click Analyze.
  6. Click Import.

Verification

To verify your template was added successfully, go to EE definition files > Create. Here you should see your newly created custom template.

6.7. Managing your EE files

Download your Execution Environment (EE) file to create a local backup. Copy an existing EE to use it as a template for a new, similar environment. Delete an EE to remove obsolete or unwanted definitions.

Prerequisites

  • You have created an EE definition through the EE Builder.

Procedure

  1. Log into the self-service automation portal and select EE definition files from the lefthand navigation pane.
  2. Under the Name column, select the EE you want to take action on:

    • To download your EE definition, click Download EE files.
    • To delete your EE definition, click the vertical dots icon and then select Unregister entity.
    • To copy your EE definition:

      • Click the vertical dots icon and then select Copy entity URL.
      • Select EE definition files from the lefthand navigation pane.
      • Click Create and then Add template.
      • Paste your entity URL into the Select URL field and click Analyze.
      • Click Import. The new template now appears in the Execution Environment definition files page.

Use the execution environment and collection catalogs in self-service automation portal to discover, browse, and access automation content.

execution environment definitions created through the EE Builder and Ansible collections discovered from synchronized Git repositories are available in dedicated catalog views.

7.1. Execution environment catalog

7.1.1. The execution environment catalog

The execution environment (EE) catalog in self-service automation portal provides a centralized view of all execution environment definitions created through the EE Builder. Use the catalog to browse, search, and access EE definitions for your automation workflows.

7.1.1.1. Catalog content

The EE catalog displays execution environment definitions that have been created through the EE Builder.

7.1.1.2. Using the catalog

The catalog allows you to:

  • Browse available execution environment definitions
  • View EE configurations and associated files
  • Download EE definition files

7.1.2. Browse the execution environment catalog

Browse the execution environment catalog to find and manage EE definitions in self-service automation portal. The catalog displays execution environment definitions discovered from your synchronized repositories, allowing you to view their configurations and access their files. Use search and filtering to locate specific execution environments.

Prerequisites

  • You have logged in to self-service automation portal.
  • Repositories containing execution environment definitions have been synced to the portal.

Procedure

  1. Navigate to the execution environment catalog.

    Note

    Navigation path and catalog interface details will be documented here with screenshots.

  2. Browse or search for execution environment definitions.

    Note

    Search, filter, and sort options will be documented here with screenshots.

  3. View detailed information about an execution environment definition.

    Note

    Detail view contents and available options will be documented here with screenshots.

  4. To download an EE definition, click Download EE files.

    The EE definition files download as a .tar archive.

Verification

  1. Verify you can locate your expected execution environment definitions in the catalog.
  2. If expected EEs are missing, verify the source repository has been synced successfully and contains valid catalog entity files.

7.2. Collection catalog

7.2.1. The collection catalog

The collection catalog in self-service automation portal provides a centralized view of all Ansible collections discovered from your synchronized Git repositories and execution environment definitions. Use the catalog to browse, search, and learn about available collections for your automation content.

7.2.1.1. Catalog content

The collection catalog displays Ansible collections that have been discovered from:

  • execution environment definitions that specify collection requirements
  • Synchronized repositories containing collection metadata

Collections are discovered during repository synchronization when self-service automation portal processes catalog entity files and execution environment definitions.

7.2.1.2. Catalog capabilities

You can use the catalog to:

  • Browse available Ansible collections
  • View collection metadata and dependencies

7.2.2. Browse the collection catalog

Browse the collection catalog to find and explore Ansible collections in self-service automation portal. The catalog displays collections discovered from your synchronized repositories and execution environment definitions, showing collection metadata, dependencies, and documentation links. Use search and filtering to locate specific collections.

Prerequisites

  • You have logged in to self-service automation portal.
  • Repositories or execution environment definitions containing collection metadata have been synced to the portal.

Procedure

  1. Navigate to the collection catalog.

    Note

    Navigation path and catalog interface details will be documented here with screenshots.

  2. Browse or search for Ansible collections.

    Note

    Search, filter, and sort options will be documented here with screenshots.

  3. View detailed information about a collection.

    Note

    Detail view contents, including metadata, dependencies, and related execution environments, will be documented here with screenshots.

Verification

  1. Verify you can locate expected collections in the catalog.
  2. If expected collections are missing, verify repositories or EE definitions containing the collection have been synced successfully.

Self-service automation portal provides a feedback form where you can suggest new features and content, as well as provide general feedback.

Note

The feedback form is disabled by default. If the Feedback button is not visible in the console, your administrator must enable it in the portal configuration.

  1. Click Feedback in the self-service automation portal console to display the feedback form.

    Self-service automation portal feedback form
  2. Enter the feedback you want to provide.
  3. Tick the I understand that feedback is shared with Red Hat checkbox.
  4. Click Submit.
Note

To ensure that Red Hat receives your feedback, exclude your self-service automation portal URL in any browser ad blockers or privacy tools.

Legal Notice

Copyright © Red Hat.
Except as otherwise noted below, the text of and illustrations in this documentation are licensed by Red Hat under the Creative Commons Attribution–Share Alike 3.0 Unported license . If you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, the Red Hat logo, JBoss, Hibernate, and RHCE are trademarks or registered trademarks of Red Hat, LLC. or its subsidiaries in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
XFS is a trademark or registered trademark of Hewlett Packard Enterprise Development LP or its subsidiaries in the United States and other countries.
The OpenStack® Word Mark and OpenStack logo are trademarks or registered trademarks of the Linux Foundation, used under license.
All other trademarks are the property of their respective owners.
Red Hat logoGithubredditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust. Explore our recent updates.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

Theme

© 2026 Red Hat
Back to top