Specifying The Runner Location

By default, the default location of the server where the runner will be running is not specified. You can use the --default-location option to force a specific default server location.

You can also use the in-{name} runner label to specify the server location for a specific job. Where {name} must be a valid Hetzner Cloud location name such as ash for US, Ashburn, VA or fsn1 for Germany, Falkenstein.

For example,

job-name:
   runs-on: [self-hosted, type-cx22, in-fsn1]

Multiple Locations

✅ Available:	>= 1.8

You can specify multiple locations that will be tried in order for each server type. This is useful when you want to have fallback options if your preferred location is not available. The locations will be tried in the order they are specified.

For example, to try nbg1 first, and if that's not available, fall back to fsn1:

job-name:
   runs-on: [self-hosted, type-cx22, in-nbg1, in-fsn1]

✅ Available:

>= 1.9, you can also use a composite label value: ⚠️ Warning: Composite label values do not work inside meta labels. job-name: runs-on: [self-hosted, in-nbg1-fsn1] A composite label value will be treated as a meta-label and expanded to: runs-on: [type-nbg1-fsn1, type-nbg1, type-fsn1] This is useful when building the runs-on labels dynamically, for example: runs-on: [ "self-hosted", "${{ inputs.runner_location }}" ]

When combined with multiple server types, the system will try each server type first, then each location for that server type. For example, if you specify locations nbg1 and fsn1 with server types cx22 and cpx11, the system will try them in this order:

1. cx22 in nbg1
2. cx22 in fsn1
3. cpx11 in nbg1
4. cpx11 in fsn1

Here's an example configuration:

job-name:
   runs-on: [self-hosted, type-cx22, type-cpx11, in-nbg1, in-fsn1]