Quick Start

Connect a private repository, select its runner group and size, and keep the rest of your GitHub Actions workflow as it is.

1. Set up your workspace

Sign in to FlareRunner, install the GitHub App, and select the private repository you want to try. Start with one test, lint, or build job.

Before the first job can run, activate a paid workspace plan and add prepaid compute credits. The plan pays for the FlareRunner service; credits pay for managed runner usage. See Pricing.

2. Change the workflow YAML

Open the workflow in .github/workflows/ and change the job from GitHub-hosted to the workspace's FlareRunner runner group. Copy the verified flarerunner-frg-… group name from FlareRunner and set the repository Actions variable FLARERUNNER_RUNNER_GROUP to that exact name. The selected repository must have access to the group. FlareRunner supplies and operates the runner; you do not need to register one by hand.

# Before
runs-on: ubuntu-latest

# After
runs-on:
  group: ${{ vars.FLARERUNNER_RUNNER_GROUP }}
  labels: [flarerunner-1x]
timeout-minutes: 30

Keep the workspace group and choose exactly one size label: flarerunner-nano, flarerunner-micro, flarerunner-small, flarerunner-1x, flarerunner-2x, or flarerunner-4x.

A missing or incorrect group prevents admission. Keep any existing shorter job timeout; use at most 30 minutes. Review the exact YAML change before committing it.

The size controls the CPU, memory, and temporary disk for that job:

flarerunner-nano — 1/16 vCPU, 256 MiB of memory, and 2 GB of disk. Use this only for very light scripts and orchestration.
flarerunner-micro — 1/4 vCPU, 1 GiB of memory, and 4 GB of disk. Use this for light linting, metadata jobs, and small scripts.
flarerunner-small — 1/2 vCPU, 4 GiB of memory, and 8 GB of disk. Use this for small builds and test suites.
flarerunner-1x — 1 vCPU, 6 GiB of memory, and 12 GB of disk. Start here when you are not sure which size an ordinary CI job needs.
flarerunner-2x — 2 vCPUs, 8 GiB of memory, and 16 GB of disk. Choose this for parallel builds or jobs that need more memory.
flarerunner-4x — 4 vCPUs, 12 GiB of memory, and 20 GB of disk. Choose this for CPU-heavy builds and the largest workloads.

How to choose. If the job already runs elsewhere, match that runner's CPU and memory as closely as possible. Otherwise, start with 1x. Move up when parallel tests or builds are CPU-bound, the job needs more memory, or its checkout and build outputs approach the disk limit. All six sizes are Linux x64 and have the same 30-minute maximum; larger sizes cost more while running.

If the runner is too small. FlareRunner does not resize or automatically retry the job on a larger runner. A memory-starved process may be killed, a full disk produces a no-space error, and a CPU-bound job may run until the 30-minute limit. The job fails normally and its logs remain available. Change the one size label in the workflow and rerun the job.

3. Commit and run

Commit the YAML change and trigger the workflow as usual. GitHub defines and starts the workflow, while FlareRunner handles the Cloudflare infrastructure outside your repository and gives you the interface for live logs, status, usage, cost, and troubleshooting.

Before moving more jobs

The private preview supports Linux x64 jobs with a 30-minute maximum runtime. Job containers, service containers, and workflows that require a Docker daemon are not supported yet.