Deployment Strategy

Runway uses Kubernetes’ implicit RollingUpdate as default strategy when deploying your service. You can override this by setting spec.strategy in your default-values.yaml.

apiVersion: runway/v1
kind: RunwayKubernetesService
metadata:
  name: example-service
spec:
  image: "registry.gitlab.com/example/example-service:{{ .AppVersion }}"
  container_port: 8080

  strategy:
    type: RollingUpdate   # RollingUpdate (default) or Recreate
    maxUnavailable: 1     # optional
    maxSurge: 1           # optional

All fields under strategy are optional. If strategy is omitted entirely, Kubernetes uses its default (RollingUpdate with maxUnavailable: 25% and maxSurge: 25%).

Gradually replaces old pods with new ones. Traffic continues to be served during the rollout.

spec:
  strategy:
    type: RollingUpdate
    maxUnavailable: 1  # max pods that can be unavailable at a time
    maxSurge: 1        # max extra pods that can be created above desired count

maxUnavailable and maxSurge accept an integer (absolute pod count) or a percentage string (e.g. "25%"). Both are optional — if omitted, Kubernetes uses its own defaults (25% each).

Terminates all existing pods before starting new ones. Causes a brief downtime during deployment.

spec:
  strategy:
    type: Recreate

Use Recreate when your service cannot run two versions simultaneously — for example, services that hold exclusive locks on a database or shared resource.