RunwayService

This type of workload deploys a Cloud Run Service.

gRPC

If you are deploying a gRPC service, set your backend_protocol to HTTP2.

Cloudflare

If you are deploying a public-facing service but you only want to allow Cloudflare-initiated connections, you just need to set spec.network_policies.cloudflare: true, which will only allow inbound traffic from the Cloudflare IP ranges.

Container Image

You will notice spec.image is defined in the schema, however it is deprecated. You need to define your image as an input when including the runwayctl project.

For example:

.gitlab-ci.yml

include:
  - project: 'gitlab-com/gl-infra/platform/runway/runwayctl'
    file: 'ci-tasks/service-project/runway.yml'
    inputs:
      runway_service_id: your-service-id
      image: "$CI_REGISTRY_IMAGE/some-image:$CI_COMMIT_SHORT_SHA"
      runway_version: v3.40.0

Request-Based vs Instance-Based Billing New in v4.31.0

By default, Cloud Run uses request-based billing — the CPU is throttled between requests and you are only charged while a request is being handled. This is controlled by spec.request_based_billing, which defaults to true.

You can disable request-based billing to enable instance-based billing:

spec:
  request_based_billing: false

With instance-based billing, the CPU is always allocated and you are billed per instance-hour regardless of traffic. This can be useful when your service:

• Runs background work outside of request handling (e.g. goroutines, timers, Pub/Sub consumers)
• Has streaming or WebSocket connections with significant idle time between messages
• Needs to avoid cold-start latency by keeping the CPU active between requests

Resource limits

Resource limits must be at least 1000m CPU and 512Mi memory. These are the defaults, so the limits block can be omitted unless you need to override them with larger values:

spec:
  request_based_billing: false
  resources:
    limits:
      cpu: 2000m
      memory: 4G

Example

runway.yml

apiVersion: runway/v1
kind: RunwayService
metadata:
  name: "<service name>"
  department: "..."
  department_group: "..."
  product_category: "..."
  owner_email_handle: "..."
spec:
  regions:
    - europe-west2
    - europe-west3
  startup_probe:
    path: "/monitoring/ready"
    initial_delay_seconds: 20
    timeout_seconds: 10
    period_seconds: 17
    failure_threshold: 24
  liveness_probe:
    path: "/monitoring/healthz"
  scalability:
    min_instances: 2
    max_instances: 10
  resources:
    startup_cpu_boost: true
    limits:
      cpu: 2000m
      memory: 8G
  network_policies:
    cloudflare: true
  load_balancing:
    external_load_balancer:
      backend_protocol: HTTPS

Refer to the schema for all supported configuration options.