Understand the independent topology

In an independent deployment, automation orchestrator runs on its own OpenShift cluster.

Understand how this topology works

You deploy automation orchestrator on its own dedicated OpenShift cluster. The automation orchestrator operator manages its own set of pods and services with an independent lifecycle.

This topology is suitable for organizations that need workload isolation or require independent lifecycle management for automation orchestrator.

Understand authentication

When co-located with Ansible Automation Platform, automation orchestrator uses OpenID Connect (OIDC) with automation gateway as the identity provider. The OIDC flow routes through automation gateway over port 443. No special secret integration or cross-cluster configuration is required beyond standard HTTPS connectivity.

Understand job dispatch

When co-located with Ansible Automation Platform, automation orchestrator dispatches automation jobs to automation controller through the automation gateway external API on port 443. This is the same mechanism used in the Ansible Automation Platform co-located topology.

Identify component boundaries

The automation orchestrator operator and the Ansible Automation Platform operator each manage their own set of resources independently.

Automation orchestrator cluster: The automation orchestrator operator manages all automation orchestrator application services, internal mutual TLS (mTLS) certificates (with the exception of Redis, which uses password authentication only), and the OpenShift Route for external access.
Ansible Automation Platform: If configured, automation orchestrator connects to automation gateway on port 443 for OIDC authentication and job dispatch to automation controller. Ansible Automation Platform can be any supported deployment type (VM-based, containerized, or OpenShift-based) as long as automation gateway is network-accessible.
Customer-managed: External PostgreSQL 15 database host (required), S3-compatible storage (optional), OpenTelemetry Collector endpoint (optional), and LLM provider (optional). These services can run on-cluster or off-cluster, as long as they are network-accessible to automation orchestrator.

Review network connectivity

If co-located with Ansible Automation Platform, the automation orchestrator cluster must have HTTPS connectivity to automation gateway on port 443 for OIDC authentication and job dispatch. You can configure zero or more Ansible Automation Platform co-locations.

Configure your firewall rules to allow outbound HTTPS traffic from the automation orchestrator cluster to the automation gateway endpoint. No inbound connections from Ansible Automation Platform to the automation orchestrator cluster are required.

Independent infrastructure topology

Review the infrastructure topology for an independent deployment to understand how automation orchestrator components connect to external services.

Review the infrastructure topology

The following diagram shows all automation orchestrator components on a dedicated OpenShift cluster and the customer-managed external dependencies.

Infrastructure topology diagram showing automation orchestrator on a dedicated OpenShift cluster with connections to Ansible Automation Platform, external PostgreSQL, S3 storage, OpenTelemetry Collector, and LLM provider dependencies. — Figure 1. Independent infrastructure topology

Read the diagram

The diagram uses the following conventions.

Enterprise ingress: A firewall or load balancer in front of the automation orchestrator OpenShift cluster. Automation orchestrator does not require a load balancer, but the diagram shows where one would sit in a typical enterprise deployment.
Automation orchestrator cluster: A dedicated OpenShift cluster containing all automation orchestrator components: backend service, worker, background worker, Temporal workflow engine, web UI, and Redis. The OpenShift Route provides external access. Communication between most services is secured with mTLS. Redis uses password authentication only and does not use TLS.
Ansible Automation Platform: Ansible Automation Platform components including automation gateway, automation controller, private automation hub, and Event-Driven Ansible. If configured, automation orchestrator connects to automation gateway on port 443 for OpenID Connect (OIDC) authentication and job dispatch. Ansible Automation Platform can be any supported deployment type, as long as automation gateway is network-accessible.
External dependencies: Customer-managed services that automation orchestrator connects to: PostgreSQL 15 database host (required), S3-compatible storage (optional), OpenTelemetry Collector endpoint (optional), and LLM providers (optional). These can run on-cluster or off-cluster, as long as they are network-accessible.

Review key connections

Automation orchestrator supports the following external connections.

If integrated with Ansible Automation Platform, automation orchestrator connects to automation gateway over HTTPS on port 443 for OIDC authentication and job dispatch to automation controller. You can configure zero or more Ansible Automation Platform integrations.
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.

Independent topology components

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

Review automation orchestrator components

The automation orchestrator operator deploys and manages the following components on the dedicated automation orchestrator cluster. All internal communication is secured with mutual TLS (mTLS).

Table 1. Automation orchestrator components
Count	Component	Description
1	Backend service	Processes API requests and coordinates communication with external services.
1	Worker	Runs workflow tasks.
1	Background worker	Runs scheduled jobs and maintenance tasks.
1	Temporal workflow engine	Coordinates workflow execution and scheduling.
1	Web UI	Serves the automation orchestrator browser interface.
1	Redis	Provides internal caching and message passing.

Review external Ansible Automation Platform components

The following Ansible Automation Platform components run on a separate cluster. They are listed here because automation orchestrator connects to them across the network boundary.

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 across the network boundary.
automation controller	Executes automation jobs dispatched by automation orchestrator through Automation Gateway. No direct connection from automation orchestrator is required.

Automation orchestrator does not connect to automation hub or Event-Driven Ansible.

Identify customer-managed external dependencies

You provision and manage the following services outside either cluster.

Table 3. External dependencies
Component	Required	Description
PostgreSQL 15 database	Yes	Stores automation orchestrator application data. You must provide a dedicated database instance. Automation orchestrator does not share the Ansible Automation Platform database.
S3-compatible storage	No	Provides persistent storage for workflow artifacts.
OpenTelemetry Operator	No	Enables telemetry collection. Deploy the OpenTelemetry Operator on the automation orchestrator cluster.
LLM provider	No	Provides large language model capabilities. Supports any OpenAI-compliant API host, whether cloud-hosted or running locally.

Independent tested system configurations

Review the tested system configurations for an independent 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 independent deployment.

Table 4. Tested system configurations
Type	Description	Notes
Subscription	Valid Red Hat Ansible Automation Platform subscription	Required for the automation orchestrator cluster.
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	Deployed on a separate OpenShift cluster	Review theRed Hat Ansible Automation Platform system requirements for the minimum supported version. The automation orchestrator cluster must have HTTPS connectivity to Automation Gateway on port 443.
Database	PostgreSQL 15	Customer-provided. Automation orchestrator requires its own database instance. Size`max_connections` based on the number of backend replicas.
S3-compatible storage	Any S3-compatible object storage provider	Optional. Required only if your workflows produce artifacts that must be retained.
LLM provider	Any OpenAI-compliant API host	Optional. Supports cloud-hosted or locally running providers.
OpenTelemetry Operator	OpenTelemetry Operator deployed on the automation orchestrator cluster	Optional. Deploy the operator separately if you want to collect telemetry data.

Independent network ports and protocols

Review the network ports and protocols used by automation orchestrator in an independent deployment to configure firewall rules between clusters and verify connectivity.

Review cross-cluster network ports

The following ports handle traffic between the automation orchestrator cluster and the Ansible Automation Platform cluster. Configure your firewall rules to allow this traffic.

Table 5. Cross-cluster network ports
Port	Protocol	Source	Destination	Purpose
443	HTTPS	Automation orchestrator backend	Automation Gateway (Ansible Automation Platform cluster)	OIDC authentication and job dispatch to automation controller. This is the only cross-cluster connection required.

No inbound connections from the Ansible Automation Platform cluster to the automation orchestrator cluster are required.

Review external network ports

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

Table 6. 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.
5432	TCP	Automation orchestrator backend	PostgreSQL database	Application data storage. Connects to the customer-provided PostgreSQL 15 instance.
443	HTTPS	Automation orchestrator backend	S3-compatible storage	Workflow artifact storage. Required only if S3 storage is configured.
443	HTTPS	Automation orchestrator backend	LLM provider	Large language model API requests. Required only if an LLM provider is configured.

Review internal network ports

The following ports handle traffic between automation orchestrator components within the cluster. All internal traffic is secured with mutual TLS (mTLS) using operator-generated certificates.

Table 7. Internal network ports
Port	Protocol	Source	Destination	Purpose
6379	TCP	Automation orchestrator backend	Redis	Caching and internal message queuing.
8443	TCP	OpenShift monitoring	Automation orchestrator metrics endpoint	Prometheus metrics scraping. 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 all internal communication between its components with mTLS. The operator generates a self-signed certificate authority (CA) and per-service certificates automatically during installation. You do not need to open additional ports or configure TLS certificates for internal traffic unless your organization requires certificates from a specific CA.

Independent example custom resource

Use this example AutomationOrchestrator custom resource as a starting point for an independent deployment on a dedicated OpenShift cluster.

Review the example custom resource

The following example shows an AutomationOrchestrator custom resource (CR) configured for an independent 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:   # PostgreSQL connection (required)   # Automation Orchestrator requires its own database,   # separate from the Ansible Automation Platform database.   postgres:     host: pg.example.com     port: 5432     sslMode: verify-full     backendDatabase:       secretRef:         name: orchestrator-pg-credentials     temporalDatabase:       secretRef:         name: temporal-pg-credentials     caCertSecretRef:       name: orchestrator-pg-ca    # External access   ingress:     host: orchestrator.apps.example.com    # Per-component replicas   backend:     replicas: 2   ui:     replicas: 2   worker:     replicas: 2    # S3-compatible file storage (optional)   # fileStorage:   #   endpointURL: https://s3.example.com   #   bucketName: orchestrator-files   #   region: us-east-1   #   verifySSL: true   #   usePathStyle: true   #   credentialSecretRef:   #     name: s3-credentials    # OpenTelemetry export for audit events (optional)   # otel:   #   enabled: false   #   endpoint: https://otel-collector.example.com:4318/v1/logs   #   serviceName: automation-orchestrator   #   authHeaderName: X-API-Key   #   apiKeySecretRef:   #     name: otel-api-key

Configure required fields

Configure the following fields for every independent deployment.

postgres: Connection details for your external PostgreSQL 15 database. You must provide separate credential secrets for the backend database and the Temporal database. In an independent deployment, consider using verify-full SSL mode with a CA certificate to secure the database connection across the network.
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 automation orchestrator OpenShift cluster.

Create database credential secrets

Create two 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: <your-password> --- apiVersion: v1 kind: Secret metadata:   name: temporal-pg-credentials   namespace: automation-orchestrator type: Opaque stringData:   database: temporal   username: temporal   password: <your-password>

If you use verify-ca or verify-full SSL mode, also create a secret containing the PostgreSQL CA certificate.

apiVersion: v1 kind: Secret metadata:   name: orchestrator-pg-ca   namespace: automation-orchestrator type: Opaque stringData:   ca.crt: |     -----BEGIN CERTIFICATE-----     <your-ca-certificate>     -----END CERTIFICATE-----

Configure optional fields

Uncomment and configure the following fields based on your requirements.

fileStorage: S3-compatible object storage for workflow artifacts. If you omit this section, file upload operations return an error.
otel: OpenTelemetry export configuration for sending audit events to an external collector. Requires the OpenTelemetry Operator on the automation orchestrator 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.

Configure external PostgreSQL for automation orchestrator

Create and configure the PostgreSQL databases and Kubernetes secrets that automation orchestrator requires before you apply the custom resource.

Before you begin

A PostgreSQL 15 instance is running and accessible from the automation orchestrator OpenShift cluster on port 5432.
You have administrative access to the PostgreSQL instance to create databases and users.
You have oc CLI access to the automation orchestrator OpenShift cluster.

About this task

Automation orchestrator requires two PostgreSQL databases: one for application data and one for the Temporal workflow engine. You must create these databases and their credentials before you install automation orchestrator.

Procedure

Connect to your PostgreSQL 15 instance.
```
psql -h pg.example.com -U postgres
```

Create the databases and users for automation orchestrator.

CREATE USER orchestrator WITH PASSWORD '<your-password>';
CREATE DATABASE orchestrator OWNER orchestrator;

CREATE USER temporal WITH PASSWORD '<your-password>';
CREATE DATABASE temporal OWNER temporal;

Verify that the databases were created.
```
\l orchestrator temporal
```
Both databases appear in the output with the correct owners.
Create the namespace for automation orchestrator on the OpenShift cluster if it does not exist.
```
oc create namespace automation-orchestrator
```

Create Kubernetes secrets for the database credentials.

oc create secret generic orchestrator-pg-credentials \
  --namespace automation-orchestrator \
  --from-literal=database=orchestrator \
  --from-literal=username=orchestrator \
  --from-literal=password='<your-password>'

oc create secret generic temporal-pg-credentials \
  --namespace automation-orchestrator \
  --from-literal=database=temporal \
  --from-literal=username=temporal \
  --from-literal=password='<your-password>'

Optional: Create a secret for the PostgreSQL CA certificate if you use verify-ca or verify-full SSL mode.

oc create secret generic orchestrator-pg-ca \
  --namespace automation-orchestrator \
  --from-file=ca.crt=/path/to/ca.crt

Verify that the secrets were created in the correct namespace.
```
oc get secrets -n automation-orchestrator | grep -E "orchestrator-pg|temporal-pg"
```
The output lists orchestrator-pg-credentials, temporal-pg-credentials, and optionally orchestrator-pg-ca.

Results

The PostgreSQL databases and Kubernetes secrets are ready for use by automation orchestrator.

What to do next

Reference these secret names in the postgres section of the AutomationOrchestrator custom resource when you create the instance.