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, andtemporal_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.
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
/apiand/wspaths 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, andtemporal_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.
| 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.
| 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.
| 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.
| 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.
| 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.
| 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: 2Configure 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, andtemporal_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_PASSWORDConfigure 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.