Investigate and plan runwayctl support for multi-port (listeners) Fairway charts

Context

Fairway is the chart-generation layer used by Runway and other consumers (Dedicated, Self-Managed, Cells) to produce Kubernetes manifests for services. Today it models exactly one service-facing port per workload (spec.container_port + optional spec.protocol), and runwayctl and the Runway platform are built around the same single-port assumption.

The Fairway team is now planning to support multiple service-facing ports per workload (fairway#31 (closed)). The proposal introduces a listeners list so a single service can publish e.g. gRPC and HTTPS on distinct ports:

# current — single port
containerPort: 8000
protocol: http

# proposed — multiple listeners
listeners:
  - port: 8000
    protocol: http
  - port: 9090
    protocol: grpc

The immediate driver is LabBench assemblies, which already model a repeated Listener shape (capped at 1 for now — bench!9), and services like IAM that expose gRPC alongside HTTP. Fairway already supports orthogonal extra ports (metric_ports, probe_port), but this is the first ask for multiple service-facing ports. Existing single-port manifests must keep rendering identical output, so backward compatibility is a hard requirement.

Designing and implementing the corresponding changes in Runway is explicitly out of scope of fairway#31 (closed), so runwayctl needs to perform adjustments and design a way to support this too. This goes beyond chart rendering — every layer that currently assumes a single service-facing port per service is potentially affected, including the surrounding infrastructure Runway provisions.

Purpose

Investigate the impact of multi-port (listeners) support on runwayctl and the Runway platform, and produce a plan on how to achieve it:

  • runwayctl: identify where the manifest schema/inputs, rendering, and runtime adapters (GKE and EKS) assume a single service-facing port, and design how Fairway's listeners shape maps onto runwayctl configuration and rendered output, keeping backward compatibility with existing single-port services.
  • Infrastructure / load balancers: how multiple listeners are exposed — load balancer configuration, backend/target mappings per port, protocol handling (HTTP vs gRPC), and public vs internal exposure per listener.
  • Cloudflare integration: how per-listener exposure interacts with our Cloudflare setup (DNS records, proxying, origin rules, which listeners go through Cloudflare vs stay internal).
  • Monitoring / observability: update monitoring dashboards, metrics, and alerting that assume one port/endpoint per service, so per-listener traffic and health are visible.
  • Follow the open questions in fairway#31 (closed) (visibility/public-private semantics, per-listener naming, Service-to-listener cardinality, whether container_port is eventually deprecated) as they get resolved, since their outcome affects the design.
  • Break the resulting plan down into implementation issues.

References