Change configuration for a modular feature
Two existing guides cover configuration in depth: Pass application configuration via Fairway for your application’s own config, and Modify the values and secrets passed to your service for chart values and Vault secrets. This page adds only the operational framing: what to touch, what happens, and what does not.
Today, on Runway
Which file
| You want to change | Edit | Scope |
|---|---|---|
Application config (your config.yaml keys) | spec.values.appConfig.data in .runway/fairway.yaml | Every environment |
| An env var or chart value for every environment | .runway/values.yaml | Every environment |
| An env var or chart value for one environment | .runway/values-production.yaml or .runway/values-staging.yaml | That environment; overrides the base file |
| A secret | Vault, at runway/env/<environment>/service/<runway_service_id> | That environment |
Sources:
Migrating to Runway v2
(“Values in values-staging.yaml and values-production.yaml override the
base values.yaml for their environment”),
Runway secrets management.
What ships it
Config files are rendered into the chart and the Flux manifests at release
time. A config change ships as a release: commit it with a fix: (or
feat:) message and it goes through the normal chain, see
Roll a deployment. A chore: commit will not deploy
it.
What does not restart pods
Application config arrives as a ConfigMap mounted at /etc/<name>/config.yaml.
A ConfigMap update alone does not restart pods; your service reads the new
file only if it reloads, and LabKit’s loader reads at startup. A release that
changes the chart’s pod template does restart them. See
Caveats.
Secrets are different. On GKE, “secrets added to Vault are available immediately” because External Secrets Operator syncs straight from Vault; on EKS the sync depends on the provisioner’s Terraform cycle ( secrets management). Whether your process picks a rotated secret up without a restart depends on how it reads it, see Rotate a secret.
Two deploy-time switches worth knowing
- Log level per deployment: Tune the level per deployment.
- Metrics scraping per deployment: Enable scraping per deployment.
Both live in .runway/values.yaml, not in fairway.yaml, because the chart
is also consumed by Cells, Dedicated and Self-Managed.
On Cells
On Cells your service does not get an environment-specific values file. Values
come from the tenant model, materialised per cell by the Theseus
Configuration module and applied with the same Fairway chart. “A service built
against CONFIG_DIR today needs no changes to run on Cells.” See
Cells and Dedicated (forward-looking)
and
Override at deploy time.
The rule that follows: a modular feature must never know which cell it is in. Cell-specific behaviour is configuration delivered by the platform, not a branch in your code. See The boundary between them.