Connectivity

Configure network access between your Platform Orchestrator installation, runners, and external services.

Network administrators and platform engineers need to configure connectivity between the Platform Orchestrator and their infrastructure. Because the Orchestrator is self-hosted, endpoint and source addresses are assigned by your own load balancers, ingress controllers, NAT gateways, and network policies.

Orchestrator endpoints

Expose the console and API hostnames configured during installation to the users and systems that need them. Agent and ECS runners outside the installation cluster require outbound HTTPS access to the API hostname’s /runner-gateway path, normally on TCP port 443. Keep the bundled NATS service cluster-local.

Direct runners require the data plane to reach the target infrastructure. Use the installation’s egress source ranges when target systems use IP allowlists.

There are no shared Stellwerk endpoint or source IP ranges.

Optional OIDC endpoint

AWS and Google Cloud federation require the cloud identity service to retrieve the per-install OIDC discovery and signing-key documents over HTTPS. Configure public reachability and trusted TLS for the hostname set in data-plane.config.OIDC_ISSUER_URL.

The exposed paths are:

  • /.well-known/openid-configuration
  • /.well-known/jwks

Installations that do not use OIDC-based AWS or Google Cloud federation can leave this endpoint disabled.

Runner network requirements

General connectivity

Runners require network connectivity to all external services they interact with during deployment execution. This includes:

  • Cloud provider APIs (AWS, GCP, Azure)
  • Kubernetes cluster API servers
  • Container registries
  • Storage services (S3 buckets, Azure Blob Storage, etc.)
  • Any custom APIs or services referenced in your Resource Definitions

For example, a runner deploying to an AWS environment needs network access to the AWS API endpoints for services like EKS, S3, and IAM.

Runner image registry access: All runners must have egress access on TCP port 443 to pull the runner container image from its registry. The specific registry depends on your runner configuration. See runner image for details.

For each runner type, the Orchestrator either launches runners itself or uses an agent component in the target infrastructure.

Direct: If the target compute for the runner execution is reachable from the Orchestrator, the data plane can create a runner itself. This applies, for example, to runner types using a cloud service with a reachable API.

Agent: If the target compute is not reachable from the Orchestrator, install the runner agent in the target infrastructure. The agent makes outbound HTTPS requests to the runner gateway. Commands remain buffered while the agent is disconnected. The agent launches runner Jobs in its local compute; those Jobs return results and encrypted logs through the same HTTPS gateway. They never receive broker credentials.

Direct

For a direct runner, configure ingress from the data plane’s egress source ranges to the target infrastructure where the runner will execute.

For example, a kubernetes-gke runner requires ingress access from those source ranges to the GKE cluster’s API server, typically on TCP port 443, so the Orchestrator can create runner jobs in the cluster.

Agent

For an agent runner, configure egress from the system hosting the agent component to the HTTPS runner gateway, normally on TCP port 443. The agent long-polls outbound and commands remain buffered while an edge is disconnected, eliminating the need for inbound firewall rules at the runner cluster.

For example, a kubernetes-agent runner requires egress access from the cluster nodes where the agent pod runs to your API hostname.

Authentication