Skip to main content
Airship holds one credential per cloud per organization, and you can connect all three at once — each runner definition names its own cloud:. Nothing is installed in your account: no stack, no agent, no peering, no bootstrap script.

Amazon Web Services

An IAM user’s access key. EC2 instances, spot, Graviton, bare metal, GPUs, and cache acceleration backed by S3.

Google Cloud

A service account key. Compute Engine instances, spot, Arm machine families, attached GPUs, extra and existing disks.

Microsoft Azure

An Entra application’s client secret. Virtual machines, spot, Arm sizes, GPU families, marketplace and gallery images.

​
What each one needs

cache: true on a cloud without acceleration is not an error: the runner launches without the proxy and the Events page records a cache.unavailable warning, so a shared definition stays portable.

​
A dedicated account is worth it

The recommendation for all three is a separate account, project or subscription for CI. It makes the permission grant uninteresting to argue about, the bill legible without tag archaeology, and the blast radius a boundary rather than a policy document. Two installations can share one cloud account — isolation then rests on the installation tag, which holds — but a dedicated one is the stronger boundary.

​
How the credential is held

1

Verified before it is stored

Airship calls your cloud with the credential first. One that does not work is never written, and you get the account identity echoed back so you can confirm it is the one you meant.
2

Sealed at rest

AES-256-GCM, under a key held in the control plane’s environment rather than in its database, and bound to its own row so it cannot be lifted somewhere else and opened.
3

Opened per call

Decrypted, handed to the provider for one API call, discarded. It is never written to a log, an error, a metric or a response, and never reaches a runner machine.
4

Never echoed back

No endpoint returns a secret. The dashboard shows the public half — the account ID and the principal your cloud reported at verification.

​
Rotating and disconnecting

Replacing a key within the same account is allowed at any time. Swapping it for a different account’s key, or disconnecting the cloud entirely, is refused while runners launched with it are still alive — without that key their machines could not be terminated. Wait for them to finish, then disconnect.

​
What Airship creates

Everything below is created once, on first use, and reused forever after. Nothing has an inbound rule.
Instances launch into the region’s default VPC unless a definition names a subnet, rotating availability zones so one zone running short does not fail the job.

​
Quotas bite before Airship does

The limit on concurrent runners is almost always a vCPU quota, not Airship. Do the arithmetic once: vCPUs per runner × concurrent runners. A 16-vCPU builder times ten runners is a quota of 160; a fresh account often has 32. Set max_runners below what your quota allows. Then hitting the ceiling is a clear message on the dashboard instead of a stream of failed launches. The per-cloud pages list the exact quotas to check, including the GPU ones, which are usually zero until you ask.