Fairway

Fairway is Theseus’s Helm chart generator. It reads a single declarative manifest describing a service — its container image, port, health endpoints, and infrastructure dependencies — and emits a complete, packaged Helm chart ready to deploy to Kubernetes.

Primary contribution to Theseus: one manifest, one chart, every environment. The same Fairway-generated chart ships to every target GitLab runs on — developer laptops via Caproni, CI, GitLab.com, Dedicated, and Self-Managed — with each environment’s operator free to choose their own orchestration and to satisfy the manifest’s abstract infrastructure dependencies. The service owner writes the manifest once.

What Fairway generates

From a service’s FairwayManifest, Fairway generates a self-contained, infrastructure-agnostic Helm chart containing:

• A Deployment and a Service, wired to the container image, port, and health endpoints declared in the manifest.
• A HorizontalPodAutoscaler and, optionally, a VerticalPodAutoscaler and PodDisruptionBudget.
• Optional Ingress or HTTPRoute resources when the manifest declares public routing.
• Optional CronJob resources for scheduled work.
• An optional metrics Service for Prometheus scraping.

The resulting chart is packaged as an OCI artifact and published to the consuming project’s container registry on every tagged release — it is not committed to Git. The manifest is the source of truth; the chart is the build output.

The two-layer manifest

A FairwayManifest separates two concerns, and this separation is Theseus’s core contract applied at chart-generation time:

• Generator-time inputs (everything under spec.* except spec.values) are baked into the chart and describe what the service is: the image, its port and protocol, its probes, and its abstract infrastructure dependencies (a PostgreSQL-compatible database, a key-value store, object storage).
• Deploy-time defaults (under spec.values) become the chart’s values.yaml and describe how the service is operated, with each environment’s operator free to override.

Developers declare requirements. Operators decide how infrastructure provides them. The same declaration drives every deployment target.

How service owners consume Fairway

Most service owners never run Fairway directly. The common-template-copier template scaffolds a .runway/fairway.yaml manifest and wires the helm-chart CI component into the pipeline, which runs fairway generate on merge requests and on every tagged release. The service-owner guide walks through writing the manifest, validating it locally with fairway validate, and understanding what gets generated.

For working with Fairway from the Theseus docs, see:

• Pass application configuration via Fairway — declare spec.values.appConfig once and let every environment deliver it.
• Modify values and secrets — the spec.values surface, including secretEnvFrom and secretVolumes.
• Fairway manifest schema — full field reference for the FairwayManifest.

Resources

• Project
• Service-owner guide — for people writing a manifest for their service
• Repository docs — deeper background and contributor guides
• helm-chart CI component — the pipeline entry point most service owners use