Understand the Ansible Automation Platform co-located topology

In an Ansible Automation Platform co-located deployment, automation orchestrator runs on the same OpenShift cluster as Ansible Automation Platform with single sign-on through Automation Gateway.

How this topology works

You deploy automation orchestrator on an existing OpenShift cluster. The automation orchestrator operator manages its own set of pods and services independently from any other operators on the cluster.

If you co-locate with Ansible Automation Platform, automation orchestrator connects to automation gateway on port 443 for OpenID Connect (OIDC) authentication and job dispatch. Ansible Automation Platform can run on the same cluster, on a separate cluster, or on any other supported deployment type, as long as automation gateway is network-accessible.

Understand how users authenticate

When co-located with Ansible Automation Platform, automation orchestrator uses OIDC with automation gateway as the identity provider. The OIDC flow routes through automation gateway on port 443. Users who sign in to automation gateway can access automation orchestrator without a separate login.

Understand how automation jobs run

When co-located with Ansible Automation Platform, automation orchestrator dispatches automation jobs to automation controller through the automation gateway external API on port 443. Automation orchestrator stores credentials for each Ansible Automation Platform co-location and uses them to trigger job template execution. No direct connection to automation controller is required.

Internal service URL validation

In a co-located deployment, integrations can use internal OpenShift service URLs with .svc hostnames. By default, automation orchestrator rejects integration URLs that resolve to private or reserved addresses. If your integrations use internal service URLs, you must configure an allowlist so that automation orchestrator accepts these hostnames. See "Allow internal service URLs for integrations" in the Configure section for more detail.

Review what each operator manages

Automation orchestrator and the other Ansible Automation Platform components each have their own operator. When both run on the same cluster, each operator manages its own set of resources independently.

Managed by the automation orchestrator operator

All automation orchestrator application services, internal mutual TLS (mTLS) certificates, and the OpenShift Route for external access.

Managed by the Ansible Automation Platform operator

Automation gateway, automation controller, Event-Driven Ansible, and their associated services.

Customer-managed

External PostgreSQL 15 database host (required), S3-compatible storage (optional), OpenTelemetry Collector endpoint (optional), and LLM provider (optional). Automation orchestrator requires its own PostgreSQL database host with three databases ( orchestrator , temporal , and temporal_visibility ), separate from any Ansible Automation Platform databases.

Review network traffic flow

All external traffic enters through a single OpenShift Route that points to the web UI service. The Route terminates TLS, and nginx in the web UI pod reverse-proxies /api and /ws paths to the backend service on port 8000. The automation orchestrator operator creates the Route automatically during installation.

Communication between automation orchestrator services is secured with mTLS, with the exception of Redis, which uses password authentication only. The operator generates a self-signed certificate authority (CA) and per-service certificates automatically.

If co-located with Ansible Automation Platform, automation orchestrator connects to automation gateway on port 443 for both OIDC authentication and job dispatch.

Ansible Automation Platform co-located infrastructure topology

Review the infrastructure topology for an Ansible Automation Platform co-located deployment to understand how automation orchestrator components connect to each other and to external services.

Review the infrastructure topology

The following diagram shows automation orchestrator components on an OpenShift cluster, including external dependencies and network connections.

Figure 1. Ansible Automation Platform co-located infrastructure topology
Infrastructure topology diagram showing automation orchestrator components deployed on an OpenShift cluster, with connections to Ansible Automation Platform, external PostgreSQL, S3 storage, OpenTelemetry Collector, LLM providers, and the OpenShift Route for ingress traffic.

Read the diagram

The diagram uses the following conventions.

Enterprise ingress

A firewall or load balancer that sits in front of the OpenShift cluster in a production environment. Automation orchestrator does not require a load balancer, but the diagram shows where one would sit in a typical enterprise deployment.

OpenShift Route

The entry point for all external traffic to automation orchestrator. TLS terminates at the Route, and nginx in the web UI pod reverse-proxies /api and /ws paths to the backend service on port 8000. The automation orchestrator operator creates the Route automatically during installation.

Automation orchestrator components

The backend service, worker, background worker, Temporal workflow engine, web UI, and Redis. The automation orchestrator operator manages these components. Communication between most services is secured with mutual TLS (mTLS) using operator-generated certificates. Redis uses password authentication only and does not use TLS.

Ansible Automation Platform

Automation gateway and automation controller. The diagram shows Ansible Automation Platform as an external co-location. If configured, automation orchestrator connects to automation gateway on port 443 for OIDC authentication and job dispatch. Ansible Automation Platform can run on the same cluster or on any other supported deployment that is network-accessible.

External dependencies

Services that automation orchestrator connects to outside the cluster boundary. These include the PostgreSQL 15 database host (required), S3-compatible storage (optional), OpenTelemetry Collector endpoint (optional), and LLM providers (optional).

Review key connections

Automation orchestrator supports the following external connections.

  • If co-located with Ansible Automation Platform, automation orchestrator connects to automation gateway on port 443 over HTTPS for OIDC authentication and job dispatch to automation controller. You can configure zero or more Ansible Automation Platform co-locations.
  • Automation orchestrator connects to its own external PostgreSQL 15 database host on port 5432. Automation orchestrator requires three databases ( orchestrator , temporal , and temporal_visibility ), separate from any Ansible Automation Platform databases.
  • If you configure S3-compatible storage, automation orchestrator connects to the S3 endpoint over HTTPS for workflow artifacts and agent task node context files.
  • If you configure an OpenTelemetry Collector endpoint, automation orchestrator sends telemetry data over OTLP on port 4318.
  • If you configure an LLM provider, the worker and background worker pods make outbound HTTPS requests to the provider endpoint.

Ansible Automation Platform co-located topology components

Review the components that make up an Ansible Automation Platform co-located deployment, including automation orchestrator pods, Ansible Automation Platform services, and customer-managed external dependencies.

Review automation orchestrator components

The automation orchestrator operator deploys and manages the following components. Communication between most services is secured with mutual TLS (mTLS). Redis uses password authentication only and does not use TLS.

Table 1. Automation orchestrator components
Count Component Description
2 Backend service Processes API requests and coordinates communication with external services.
2 Worker Runs workflow tasks. Connects to automation gateway on port 443 for OIDC authentication and job dispatch to automation controller.
HPA (1-5) Background worker Runs scheduled jobs and maintenance tasks. Scaled by a HorizontalPodAutoscaler with a target of 80% CPU utilization.
1 Temporal workflow engine Coordinates workflow execution and scheduling.
2 Web UI Serves the automation orchestrator browser interface. Includes nginx, which reverse-proxies/api and/ws paths to the backend service.
1 Redis Provides internal caching and message passing. Uses password authentication only, no TLS.

Review Ansible Automation Platform components

If you co-locate with Ansible Automation Platform, the following components are relevant to automation orchestrator. These components are managed by the Ansible Automation Platform operator.

Table 2. Ansible Automation Platform components used by automation orchestrator
Component Role in this topology
automation gateway Provides OIDC authentication for automation orchestrator users and serves as the API entry point for job dispatch. Automation orchestrator connects on port 443.
automation controller Executes automation jobs dispatched by automation orchestrator through automation gateway. No direct connection from automation orchestrator is required.

Identify customer-managed external dependencies

You provision and manage the following services. These can run on-cluster or off-cluster, as long as they are network-accessible to automation orchestrator.

Table 3. External dependencies
Component Required Description
PostgreSQL 15 database host Yes Stores automation orchestrator application data. You must provide a dedicated database host with three databases:orchestrator ,temporal , andtemporal_visibility . Automation orchestrator does not share Ansible Automation Platform databases.
S3-compatible storage No Provides persistent storage for workflow artifacts and context files used by agent task nodes. Can run on-cluster (for example, using OpenShift Data Foundation) or off-cluster.
OpenTelemetry Collector endpoint No Enables telemetry collection over OTLP on port 4318. Can run on-cluster (for example, using the Red Hat build of OpenTelemetry Operator) or off-cluster.
LLM provider No Provides large language model capabilities. Automation orchestrator supports any OpenAI-compliant API host, whether cloud-hosted or running locally in your environment. Required for agentic workflow nodes.

Ansible Automation Platform co-located tested system configurations

Review the tested system configurations for an Ansible Automation Platform co-located deployment to verify that your environment meets the requirements before you install.

Review tested configurations

The following table lists the infrastructure components and versions tested with automation orchestrator in an Ansible Automation Platform co-located deployment.

Table 4. Tested system configurations
Type Description Notes
Subscription Valid Red Hat Ansible Automation Platform subscription Required for automation orchestrator.
Red Hat OpenShift Container Platform Red Hat OpenShift Container Platform 4.14 - 4.22. The OpenShift Container Platform version must be within the Red Hat supported lifecycle. For details on which versions are supported, see theOpenShift Container Platform Life Cycle Policy. Supports x86_64 and ARM64 architectures. No elevated cluster permissions are required. For minimum cluster sizing, seeCluster requirements.
Ansible Automation Platform Any supported Ansible Automation Platform deployment with a network path to automation gateway on port 443 Review theRed Hat Ansible Automation Platform system requirements for the minimum supported version. Ansible Automation Platform can run on the same cluster, on a separate cluster, or on any other supported deployment type. You configure Ansible Automation Platform co-located as a day-2 operation after installation.
Database PostgreSQL 15 Customer-provided. Automation orchestrator requires its own database host with three databases:orchestrator ,temporal , andtemporal_visibility , separate from any Ansible Automation Platform databases. Sizemax_connections based on the number of backend replicas.
S3-compatible storage Any S3-compatible object storage provider Optional. Provides persistent storage for workflow artifacts and context files used by agent task nodes. Can run on-cluster or off-cluster.
LLM provider Any OpenAI-compliant API host Optional. Required for agentic workflow nodes. Supports cloud-hosted or locally running providers, including Red Hat AI and Red Hat OpenShift AI. The worker and background worker pods make outbound HTTPS requests to the provider endpoint.
OpenTelemetry Collector endpoint Any standards-compliant OTLP endpoint on port 4318 Optional. Can run on-cluster (for example, using the Red Hat build of OpenTelemetry Operator) or off-cluster, as long as it is network-accessible to automation orchestrator.

Ansible Automation Platform co-located network ports and protocols

Review the network ports and protocols used by automation orchestrator in an Ansible Automation Platform co-located deployment to configure firewall rules and verify connectivity.

Review external network ports

The following ports handle traffic between automation orchestrator and services outside the cluster or outside the automation orchestrator namespace.

Table 5. External network ports
Port Protocol Source Destination Purpose
443 HTTPS External clients OpenShift Route All external user and API traffic to automation orchestrator. TLS terminates at the Route.
443 HTTPS Worker automation gateway OpenID Connect (OIDC) authentication and job dispatch to automation controller. Required only if Ansible Automation Platform is configured.
5432 TCP Backend, Worker, Background worker, Temporal PostgreSQL database host Application data storage. Connects to the customer-provided PostgreSQL 15 database host.
443 HTTPS Backend S3-compatible storage Workflow artifact and agent task node context file storage. Required only if S3 storage is configured.
443 HTTPS Worker, Background worker LLM provider Large language model API requests. Required only if an LLM provider is configured.
4318 TCP Worker, Background worker, Temporal OpenTelemetry Collector endpoint Telemetry data export over OTLP. Required only if an OpenTelemetry Collector is configured.

Review internal network ports

The following ports handle traffic between automation orchestrator components within the cluster. Communication between most services is secured with mutual TLS (mTLS) using operator-generated certificates. Redis uses password authentication only and does not use TLS.

Table 6. Internal network ports
Port Protocol Source Destination Purpose
8000 HTTPS (mTLS) Web UI (nginx), Worker, Background worker Backend service API requests to the backend. Nginx in the web UI pod reverse-proxies/api and/ws paths.
7233 gRPC Backend, Worker, Background worker Temporal workflow engine Workflow execution coordination and task scheduling.
8080 HTTP Web UI service Web UI pod Internal routing from the Kubernetes service to the web UI pod.
6379 TCP Backend, Worker, Background worker Redis Caching and internal message queuing. Password authentication only, no TLS.
5432 TCP Backend, Worker, Background worker, Temporal PostgreSQL database host Database connections from all components that require data persistence.
9090 TCP OpenShift monitoring Worker, Background worker, Temporal

Prometheus metrics scraping for workload pods (worker, background worker, temporal). The operator creates a metrics-ingress NetworkPolicy to allow cross-namespace traffic on this port. For the full list of operator-managed NetworkPolicies, see Automation orchestrator operator-managed NetworkPolicies.

For the complete list of NetworkPolicy resources that the operator creates for each component, see Automation orchestrator operator-managed NetworkPolicies.

Review internal service communication

Automation orchestrator secures communication between most internal components with mTLS. The operator generates a self-signed certificate authority (CA) and per-service certificates automatically during installation. Redis uses password authentication only and does not use TLS. You do not need to open additional ports or configure TLS certificates for internal traffic unless your organization requires certificates from a specific CA.

Ansible Automation Platform co-located example custom resource

Use this example AutomationOrchestrator custom resource as a starting point for an Ansible Automation Platform co-located deployment on a shared OpenShift cluster.

Review the example custom resource

The following example shows an AutomationOrchestrator custom resource (CR) configured for an Ansible Automation Platform co-located deployment. Edit the values to match your environment before you apply the CR.

apiVersion: aap.ansible.com/v1alpha1
  kind: AutomationOrchestrator
  metadata:
    name: my-orchestrator
    namespace: automation-orchestrator
  spec:
    postgres:
      host: pg.example.com
      port: 5432
      sslMode: require
      backendDatabase:
        secretRef:
          name: orchestrator-pg-credentials
      temporalDatabase:
        secretRef:
          name: temporal-pg-credentials
      temporalVisibilityDatabase:
        secretRef:
          name: temporal-visibility-pg-credentials
    ingress:
      host: orchestrator.apps.example.com
    backend:
      replicas: 2
    ui:
      replicas: 2
    worker:
      replicas: 2

Configure required fields

Configure the following fields for every Ansible Automation Platform co-located deployment.

postgres

Connection details for your external PostgreSQL 15 database host. You must provide separate credential secrets for three databases: orchestrator (backend), temporal , and temporal_visibility . Automation orchestrator does not share Ansible Automation Platform databases.

ingress.host

The hostname for the OpenShift Route that the operator creates for external access. Set this to a DNS name that resolves to your OpenShift cluster.

Create database credential secrets

Create three Kubernetes secrets for the PostgreSQL database credentials before you apply the CR. Each secret must contain the following keys: database , username , and password .

apiVersion: v1
  kind: Secret
  metadata:
    name: orchestrator-pg-credentials
    namespace: automation-orchestrator
  type: Opaque
  stringData:
    database: orchestrator
    username: orchestrator
    password: REPLACE_WITH_PASSWORD

  apiVersion: v1
  kind: Secret
  metadata:
    name: temporal-pg-credentials
    namespace: automation-orchestrator
  type: Opaque
  stringData:
    database: temporal
    username: temporal
    password: REPLACE_WITH_PASSWORD

  apiVersion: v1
  kind: Secret
  metadata:
    name: temporal-visibility-pg-credentials
    namespace: automation-orchestrator
  type: Opaque
  stringData:
    database: temporal_visibility
    username: temporal_visibility
    password: REPLACE_WITH_PASSWORD

Configure optional fields

Uncomment and configure the following fields based on your requirements.

fileStorage

S3-compatible object storage for workflow artifacts and context files used by agent task nodes. If you omit this section, file upload operations return an error.

otel

OpenTelemetry export configuration for sending audit events to an external collector. Requires a network-accessible OpenTelemetry Collector endpoint on port 4318. The collector does not need to run on the same cluster.

secrets

References to pre-created secrets for JWT signing keys, the credential encryption key, the Redis password, and the initial admin password. The operator auto-generates these secrets if you do not provide them.

tls

References to customer-provided internal TLS certificates. The operator generates a self-signed CA and per-service certificates if you do not provide them.