## 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). The proposal introduces a `listeners` list so a single service can publish e.g. gRPC and HTTPS on distinct ports: ```yaml # 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](https://gitlab.com/gitlab-org/lab-bench/bench/-/merge_requests/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, 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 (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 - fairway#31 — [Draft] Support multiple ports in Fairway charts - LabBench `repeated Listener` shape: https://gitlab.com/gitlab-org/lab-bench/bench/-/merge_requests/9 - Fairway manifest proto: `proto/manifest/v1/manifest.proto`