FAQ

What is FlareRunner?

FlareRunner runs ordinary GitHub Actions jobs on a managed runner service built entirely on Cloudflare infrastructure. Your workflows stay focused on the job while FlareRunner handles the runner operations.

Who is it for?

We are starting with small engineering teams using private GitHub repositories, Linux CI, and standard test, lint, build, and deployment workflows.

How do we get started?

Connect the FlareRunner GitHub App, choose a private repository, and change one job's runner label using the Quick Start. Nothing runs until you commit the workflow update.

Do we need to rewrite our workflows?

Usually not. FlareRunner keeps GitHub Actions syntax and changes the runner target for compatible jobs. Unsupported features are discussed in the quick start.

What happens during a job?

Each job receives one ephemeral Linux x64 runner. The runner is created for that job and destroyed when the job finishes, so work does not carry across jobs by default. Use the Caching guide for dependencies you want to restore in later jobs.

What runner sizes are available?

Nano, Micro, Small, 1x, 2x, and 4x are available, ranging from 1/16 vCPU and 256 MiB of memory to 4 vCPUs and 12 GiB. Each profile has an explicit runtime and resource limit; the quick start explains how to choose one.

How does pricing work?

A workspace is one GitHub organization or personal account. Workspace access is $10 monthly or $100 annually. Managed runner usage is prepaid and charged from published rates based on measured runtime; there is no free compute or unfunded overage.

Dependency caches are stored by FlareRunner in Cloudflare R2 when FlareRunner caching is enabled. Storage, writes and reads are automatically billed from service credit for every workspace and appear as separate usage line items. Uploads and restores also consume billed runner time. Learn about cache storage and downloads.

Can we control spending?

Completely. Workspaces have funded balances, concurrency limits, maximum job durations, spending controls, and optional bounded automatic top-ups. New jobs stop when FlareRunner cannot reserve enough credit.

Can we see what our jobs are doing?

FlareRunner provides live and retained logs, job status, queue time, usage, cost, and clear failure reasons in one fast interface. GitHub still defines and triggers the workflow, but our goal is for FlareRunner to be where you monitor and troubleshoot jobs without needing to open the GitHub Actions website.

Why private repositories only?

A public repository can receive pull requests from any fork, and those requests may include workflow code that runs on a self-hosted runner. GitHub recommends using self-hosted runners only with private repositories because malicious workflow code can compromise the runner environment.

FlareRunner creates a fresh runner for every job and destroys it afterward, but that does not make untrusted code safe while the job is running. The private preview stays private-only while we focus on repository-controlled workloads, abuse prevention, and stronger controls before considering public repositories.

Other preview limits include macOS, Windows, ARM, GPUs, service containers, job containers, and workflows that require a Docker daemon.