> ## Documentation Index
> Fetch the complete documentation index at: https://docs.airshipci.com/llms.txt
> Use this file to discover all available pages before exploring further.

# One-line runners

> Describe the machine in the label itself, with no config file at all.

In an activated repository with AWS connected, a label can name the machine
directly. No `airship.yaml`, no commit to it, nothing to review — change one
line in a workflow and push.

```yaml theme={null}
# t2.large, Ubuntu 22.04
runs-on: airship-aws-t2-large-ubuntu2204--${{ github.run_id }}

# a Graviton c7g.xlarge on spot capacity
runs-on: airship-aws-c7g-xlarge-spot

# m7i.metal-24xl
runs-on: airship-aws-m7i-metal-24xl
```

This is for trying something: *is this build actually faster on 32 cores?*
Once you know the answer, write it down in `airship.yaml`, where it is
reviewed, shared and versioned with everything else.

## The label format

```
airship-aws-<instance-type>[-ubuntu2204|-ubuntu2404][-spot]
```

**1. airship-aws-**

The prefix. Only AWS has one-line runners.

**2. The instance type, with dots as dashes**

`t2.large` becomes `t2-large`; `m7i.metal-24xl` becomes `m7i-metal-24xl`.
The family has to look like one of EC2's — `c7i`, `c7i-flex`, `u7i-12tb`,
`mac2-m2` — so a typo is simply not a one-line runner rather than a
launch that fails.

**3. Optionally an image**

`ubuntu2204` (the default) or `ubuntu2404`.

**4. Optionally spot**

`spot` asks for spot capacity.

The image and `spot` tokens may come in either order, but only at the end. A
label that puts them elsewhere is not a one-line runner, and the job is
skipped with *No runner serves the labels*.

## What you get

| | |
| - | - |
| Region | The connected cloud's default region |
| Image | Canonical's newest Ubuntu for the architecture |
| Root volume | 75 GiB |
| Network | The default VPC, Airship's egress-only security group |
| Caching | Off |
| Architecture | From the instance type, as usual |

Everything else — disks, caching, environment variables, private networking,
idle pools, GPUs — needs a definition in
[`airship.yaml`](https://docs.airshipci.com/configuration/overview).

## A definition always wins

If any definition's `labels` include the same label, that definition is used
instead. So you can introduce `airship.yaml` later without changing a single
workflow file: name the definition's label after the one-line label you were
using, and the next job picks it up.

```yaml airship.yaml theme={null}
runners:
  - name: big
    cloud: aws
    instance_type: m7i.metal-24xl
    region: eu-west-1
    labels: [airship-aws-m7i-metal-24xl]    # takes over from the one-line form
    extra_config:
      BlockDeviceMappings:
        - VolumeSize: 300
          VolumeType: gp3
          Iops: 6000
          Throughput: 1000
```

> [!NOTE]
>
> A job that also asks for `windows` is never served by a one-line runner:
> the Ubuntu images are Linux. Windows needs [a definition naming a Windows
> image](https://docs.airshipci.com/configuration/windows.md).

## Still bounded

One-line runners obey everything else: the repository must be
[activated](https://docs.airshipci.com/concepts.md), [`max_runners`](https://docs.airshipci.com/organization/capacity) still caps
concurrency, the machine still destroys itself after one job, and the launch
still shows up on **Jobs**, **Runners** and **Events**.

What they skip is the review step. On a repository where that matters — a
public one, or one where people should not be choosing 48xlarge machines
casually — keep the shapes in `airship.yaml` and use [access
policies](https://docs.airshipci.com/organization/access-control.md) on the expensive ones.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.