Workload identity, no keys
BYOC on Google Cloud
Runners in your GCP project with workload identity, local SSD and Artifact Registry caching.
Workload identity
Federated auth with no service-account keys to rotate or leak.
Local SSD
Attach local NVMe for the disk profile the hosted runners use.
Artifact Registry
Pull-through caching keeps image pulls inside your project.
GCP deployments use a managed instance group per runner shape. Local SSD is opt-in per shape because it changes the machine families available to you.
Common questions
- Do I need service account keys?
- No. Workload identity federation is used instead, so there are no long-lived JSON credentials to rotate or leak. Scope the trust condition on repository owner at minimum.
- Does local SSD matter?
- Considerably. File-heavy CI steps are disk-bound, and local NVMe is what gives BYOC runners the same profile as the hosted product. It also constrains which machine families you can use, so pick the disk first.
- Are Windows runners supported on GCP?
- Support is more limited than on AWS and Azure. Check the Azure limitations page for the current capability matrix across providers.
Your next build could be twice as fast, at half the price
Start free. Migrating away is the same one line, and we publish that diff too.