Get started

FlameWill runs your GitHub Actions jobs on a fresh ARM machine per job, sized by the memory the job needs. You change one line of your workflow; nothing else in it has to change.

1. Get your organization added

FlameWill is in preview: organizations are added one by one. Once yours is, an owner installs the FlameWill GitHub App on it, and FlameWill registers organization runners in a runner group limited to the repositories you name. A job from any other repository never starts a machine.

2. Change one line

Pick the class by the memory your job needs at its peak, not by its cores:

jobs:
  build:
    runs-on: flamewill-arm-2c8g   # was: ubuntu-latest

The usable figure is the class memory minus about 1.5 GB for the operating system and the runner. Size each job by its own measured peak, never by a sibling job’s: every job log ends with a FlameWill: job report line that shows the peak (section 6).

The label must match exactly. runs-on: [self-hosted, linux, arm64] alone matches no class.

3. What the machine is

• Fresh for every job. The machine is created when your job is queued, runs that one job, and is destroyed when it ends. Nothing carries over from another job or another customer, except the caches of sections 4 and 5.
• ARM64 (AWS Graviton), Ubuntu 24.04, in Stockholm (AWS eu-north-1). Node, Python, Go, Rust, Java, esbuild, sharp and Playwright run natively; an x64-only binary or Docker image does not.
• Your job’s work folder is on the local NVMe disk.
• Preinstalled: git, node 24.16.0 in the runner tool cache (actions/setup-node with node-version: 24 downloads nothing), bun 1.4.2, npm, python3, build-essential, GNU time, Docker with buildx and compose (Docker starts on first use, with its data on the NVMe disk), Playwright 1.61.1’s Chromium with its system libraries, the AWS CLI, subversion, zip, rsync and jq. Anything else installs as usual: sudo apt-get install … works, and so does actions/setup-*.
• Passwordless sudo, so mount --bind, swap files and package installs work.
• No inbound network. No SSH port and no key pair.
• Spot capacity. FlameWill runs on AWS’s spare capacity, which is why it is cheap. A job that cannot get a machine at once waits and is retried automatically. AWS rarely takes a machine back mid-job; when it does, the job fails with “runner lost” and you re-run it from GitHub. Split or checkpoint jobs that run for hours.

4. Skip reinstalls with fw-cache

Every FlameWill machine carries fw-cache, a path cache in the same AWS region, reachable only by your organization’s runners:

key="node_modules-$(cat package-lock.json | sha256sum | cut -c1-16)-$(node --version)-$(uname -m)"
if ! { command -v fw-cache >/dev/null && fw-cache restore "$key" node_modules; }; then
  npm ci || { echo "STOP: npm ci failed"; exit 1; }
  if command -v fw-cache >/dev/null; then fw-cache save "$key" node_modules || true; fi
fi

Write it as if/then with an explicit exit 1. The one-liner fw-cache restore … || { npm ci && fw-cache save …; } does not stop a set -e script when npm ci fails: the shell ignores -e inside an && list, so the job would go on with a broken node_modules. On a machine without FlameWill, command -v skips the cache and the install runs as before.

• restore exits 0 on a hit and 1 on a miss. It is all or nothing: the archive’s sha256 and its tree digest are checked in a staging folder, and only a complete, verified tree is swapped in. Otherwise your paths stay as they were and the fallback runs.
• save stores a key once: keys are immutable, so derive them from everything the content depends on (lockfiles, tool versions, CPU architecture). When several jobs save one key at once, the first wins and the others are no-ops.
• Save right after the install: save refuses a tree that holds node_modules/.cache, which a build writes.
• fw-cache digest <path>... prints a tree’s digest, so two trees can be compared.
• Unused keys expire after 30 days.

Measured on our first customer: a toolchain step of three npm ci (1.26 GB of node_modules) went from 20.9 s to 8 s.

5. Caches you get without asking

• npm cache and pnpm store: restored before your first step and saved after your last when their contents changed, so npm ci and pnpm install read packages from the local disk. pnpm 11 and later need nothing; on pnpm 9 or 10, add npm_config_store_dir: /mnt/flamewill/pnpm-store to the job’s env.
• Shared read-only data, on request: an S3 prefix your jobs read through a role they assume with GitHub’s OIDC, and that only one GitHub environment can write. Overwritten objects stay recoverable, and no role can delete.

6. What you see in every job log

A FlameWill: job report line after your last step: the machine type, spot or on-demand, the zone, the CPU model, vCPUs, the job’s peak process memory and its peak including the page cache, out-of-memory kills, CPU seconds, disk used and wall time, then machine cost ≈ $…. Above 90 % of the memory, a warning names the next class that fits.

7. Roll back

Change the label back. Nothing else on your side depends on FlameWill.