GitHub Actions runners in your own cloud

Every GitHub Actions job gets a fresh machine in your own cloud account, described by one file in your repository.

Airship is a control plane for GitHub Actions runners. You connect a cloud account once, activate a repository, and commit an airship.yaml that describes the machines you want. From then on, every job that asks for one of your labels gets its own machine — launched when the job is queued, destroyed when the job ends.

Nothing is installed in your account. There is no autoscaling group to tune, no runner image to keep alive, no agent to upgrade. The machines are yours, in your regions, on your bill.

airship.yaml

runners:
  - name: build
    cloud: aws
    instance_type: [c7i.2xlarge, m7i.2xlarge]   # tried in order
    region: eu-west-1
    labels: [airship-build]
    extra_config:
      cache: true

.github/workflows/ci.yml

jobs:
  test:
    runs-on: airship-build--${{ github.run_id }}
    steps:
      - uses: actions/checkout@v4
      - run: make test

That is the whole integration. Jobs on ubuntu-latest are untouched, so you can move one workflow at a time.

Why run jobs this way

Machines GitHub does not rent you

64-core builders, 1 TiB of RAM, Graviton and Arm, GPUs, bare metal, Windows, your own images with the toolchain already baked in.

Your cloud's prices, including spot

You pay your provider directly, at your committed-use and spot rates. Spot capacity with an on-demand fallback is two lines of YAML.

One job per machine, always

A runner registers for a single job and the machine destroys itself afterwards. No job inherits another’s disk, environment or credentials.

Caching without a size limit

actions/cache and everything built on it, served from a bucket in your own account over the local network.

Configured as code, per branch

A job reads airship.yaml at its own commit, so a pull request can try a bigger machine before anyone merges it.

Your network, your boundary

Private subnets, your own egress rules, no inbound ports, and no SSH key for Airship to hold.

Start here

Quickstart

From nothing to a green job on your own hardware, in about fifteen minutes.

How it works

What happens between a queued job and a terminated machine, step by step.

Connect your cloud

The credential, the permissions and the quotas for AWS, Google Cloud and Azure.

airship.yaml reference

Every field, what it accepts, and what each cloud does with it.

What Airship never holds

Your source code, your Actions secrets, your artifacts and your job logs never reach the control plane — the runner talks to GitHub directly. Your cloud credential never reaches a runner. Airship holds job metadata and a sealed credential it opens for the length of one API call.

Security and trust is written to be read adversarially, and says plainly where the edges are.