Automation orchestrator system requirements

Supported platforms

Automation orchestrator requires Red Hat OpenShift Container Platform. The operator creates a Route for external access automatically.

Automation orchestrator supports both x86_64 and ARM64 architectures. No elevated cluster permissions are required.

Internal service communication

Automation orchestrator secures all internal communication between backend components using mutual TLS (mTLS). The operator generates a self-signed certificate authority (CA) and per-service certificates automatically during installation. No additional configuration is required for the default path.

If your organization requires certificates from a specific CA, you can provide your own CA certificate and per-service TLS certificates. For details, see Provide your own internal TLS certificates

Cluster requirements

• Red Hat OpenShift Container Platform 4.14 or later.
• Operator Lifecycle Manager (OLM) installed on the cluster.
• Sufficient cluster resources to run the automation orchestrator components. For default CPU and memory requirements per component, see Default resource requirements

External dependencies

1. PostgreSQL 15 (required): Provide your own PostgreSQL 15 instance. This is the supported production configuration. Create the following databases:

   • A database for the automation orchestrator backend (for example, orchestrator).
   • A database for the Temporal workflow engine (for example, temporal). The automation orchestrator operator automatically creates an additional temporal_visibility database using the same connection credentials.
   • A PostgreSQL user with permissions to create tables and run migrations on all three databases (backend, temporal, and temporal_visibility).
   • Use TLS connections for production deployments. The default SSL mode is require.
   • For high-availability setups, provide a single connection endpoint (for example, through Patroni VIP, PgBouncer, or a Kubernetes Service fronting an HA cluster).

   • If all databases share one PostgreSQL instance, increase max_connections above the default of 100. Each component replica opens up to poolSize + maxOverflow connections (default: 30) across each database. The background worker also opens database connections and is included in the recommendations below. Set max_connections based on your total replica count:

     Table 2. Recommended max_connections by replica count

     Backend replicas	Worker replicas	Recommendedmax_connections
     2	2	230
     2	4	330
     4	8	530

     These values assume 1 background worker replica and default pool settings (poolSize=20, maxOverflow=10). The background worker scales automatically based on CPU usage, up to 5 replicas by default. Add 30 connections per additional background worker replica when you calculate max_connections for your peak load. With the default maximum of 5 replicas, plan for up to 150 background worker connections at peak load. If you increase pool settings in the custom resource, increase max_connections proportionally. Each connection slot adds approximately 5-10 MB of memory overhead on the PostgreSQL server. If you host databases on separate PostgreSQL instances, adjust each instance's max_connections accordingly.

   • If you do not have an existing PostgreSQL provider, you can use the aapctl CLI to provision PostgreSQL with CloudNativePG. Red Hat does not provide support for CloudNativePG. The aapctl CloudNativePG template sets max_connections to 200 by default, so no manual adjustment is required. See Alternative: Provision PostgreSQL with CloudNativePG.

2. S3-compatible object storage (optional): Provide an S3-compatible endpoint for file uploads. Automation orchestrator stores uploaded files in S3-compatible object storage. If you do not configure S3, file upload requests return HTTP 503. Configure the endpoint and credentials in spec.fileStorage on the AutomationOrchestrator custom resource. See File storage (S3) for the full field reference.

3. Red Hat OpenTelemetry operator (optional): Install the Red Hat build of the OpenTelemetry operator to collect audit events and telemetry data from automation orchestrator. The aapctl CLI can install the OpenTelemetry operator and deploy a collector automatically. See Enable OpenTelemetry collection with aapctl.

4. Network connectivity: Outbound HTTPS access is required if you configure large language model (LLM) provider integrations. Inbound HTTPS is handled by the Route that exposes the application.

Secrets and credentials

Create the following Kubernetes Secrets in the target namespace and reference them in the AutomationOrchestrator custom resource. If you use aapctl with CloudNativePG enabled, aapctl creates the PostgreSQL secrets automatically (see Provision PostgreSQL with CloudNativePG).

Required secrets (customer-provided):

Application secrets (auto-generated or customer-provided):

The automation orchestrator operator auto-generates the following secrets when you do not provide them. Auto-generated secrets are automatically deleted when you delete the custom resource.

For details on how internal TLS works and certificate requirements, see Understand internal TLS. For the full spec.tls field reference, see Installation reference.