Flare Actions

Open-source GitHub Actions alternative you host on your own Cloudflare account. One click deploys the Worker and auto-provisions its D1 database and queues.

Already have Actions workflows? Keep them. Repos without a flare.yml run their existing .github/workflows/*.yml unchanged — same triggers, jobs, steps, matrices, cache, and artifacts; unsupported actions are dropped with warnings instead of silently misbehaving (support matrix). No GitHub App? Public repos can run from a plain repo webhook. Want full control? The native flare.yml format always wins when present, and cli import migrates a workflow with a warning report. Prefer to keep GitHub orchestrating? runs-on: flare hands your existing workflows Flare runners with a one-line change — checks, logs, and approvals stay on GitHub.

GitHub App webhook → Worker (verify) → D1 run row → Queue dispatch → external pull-runner → status callback. Dashboard + API + CLI.

Plus the agent forge (our Cloudflare "next git platform" competition entry): race N agents on one task — isolated Artifacts forks, real Flare CI verifying every attempt, collision radar, ranked verdict with rationale, immutable ledger. Live staging demo · try it.

Start here (no experience needed)

Flare checks your code for you: every time you save your work to GitHub, it runs your project's tests and tells you — in plain words — if anything broke.

1. Get your own Flare. Press Deploy to Cloudflare above and follow the prompts (a free Cloudflare account is enough).
2. Open it and make your account. Go to https://<your-flare>.workers.dev/dashboard. The first person to sign up becomes the owner.
3. Follow the Home page. It shows a short checklist with one big button per step: connect GitHub → pick your projects → run your tests. Each step ticks itself off when it's done.

If your tests are waiting for a computer, Home offers Use my computer: copy one line into the Terminal and that computer starts running your tests. When something fails, See what broke shows the failing step and a suggested fix.

Why

• Faster: warm edge dispatch, no 2–3 min hosted queue waits.
• Easier: TypeScript + wrangler.jsonc, local wrangler dev, no YAML push-test loop.
• Better: durable dispatch signals with Queue retry + DLQ, D1 run history, fully open and self-hosted.
• Zero-step migration: existing .github/workflows run as-is; every run is tagged in the dashboard with which pipeline ran it.
• Agent-scale development: npm run check lints, type-checks, and tests only what changed — serialized across worktrees so parallel sessions don't thrash (measurements).

Layout

• apps/worker — Cloudflare Worker: webhook verify, dispatch API, MCP server, dashboard + admin API, queue consumer, D1 state, R2 cache/artifacts
• packages/runner-sdk — shared client (pull/status/cache/artifacts), job orchestrator, Actions importer
• apps/runner — external pull-runner: labels, checkout, containers, services, cache, artifacts
• apps/cli — CLI: runs, logs, dispatch, rerun, flaky, import, badges, MCP config, login, forge (races, repos, claim, verdict)
• apps/seats — managed executor worker (seat DO + container image)
• docs/ — pipeline reference, runners, MCP, operations, roadmap, Actions compatibility, dev speed, economics
• llms.txt — model-readable index (docs, MCP config, quickstart) for agents and LLM tooling

Quickstart

One click (no terminal): hit Deploy to Cloudflare above. Cloudflare clones the repo into your account, reads the root wrangler.jsonc, and auto-provisions the Worker's D1 database, R2 bucket, queues, and Workers AI binding. When it finishes, open https://<your-worker>/dashboard:

1. Open the dashboard and create your admin account (email + password, or a passwordless magic link) — first signup claims admin.
2. Hit Connect GitHub (one click, no naming — the App name is automatic), install the App on your repos, and push. Prefer GitHub login? Connect first, then Login with GitHub instead. Invite teammates by email from the Access tab; runner tokens are only for BYO machines.

That is the whole core loop. Everything else is optional and additive: your own machine as a runner (npm run runner), managed seats (npm run setup on a machine with docker), a notification sender, and scheduled runs.

From source:

npm install
npm run setup   # provisions D1 + queues + R2, deploys, writes gitignored .env

setup prints your Worker URL. Open the dashboard, Connect GitHub, install the App, Login with GitHub — then run with zero config:

npm run runner            # external pull-runner (reads .env automatically)
npm run cli -- runs       # list runs
npm run cli -- logs <id>  # run logs

Manual fallback (if you prefer each step by hand): wrangler d1 create, wrangler queues create × 4 (-runs, -dlq, -seats, -seats-dlq), wrangler r2 bucket create flare-actions-cache, wrangler d1 migrations apply --remote, wrangler secret put for RUNNER_TOKEN, then npm run deploy — Connect GitHub in the dashboard manages the webhook secret + App credentials, and the first GitHub login claims admin. Only set GitHub values as env secrets if you want the manual App flow instead (then also set ADMIN_TOKEN, which becomes the dashboard recovery password). Local dev: npm run dev.

Replace your GitHub Actions — pick your path

Every path runs your existing .github/workflows files unchanged — nothing to migrate, no App required if you don't want one:

Path	Setup	What you get
One click + GitHub App (recommended)	Deploy button → dashboard → Connect GitHub → install	Push/PR runs, commit statuses, Check Runs, PR comments, private repos
One click, no App (public repos)	Deploy button → copy the webhook secret in Settings → add one repo webhook to https://<worker>/webhooks/github	Push/PR runs from your existing workflows — nothing installed on GitHub
Dispatch only (agents, no webhooks)	Issue an API token → cli run owner/repo HEAD or MCP run_and_wait	Verify any commit — or an uncommitted working tree — on demand
Runner mode (stay on GitHub)	Settings → enable runs-on: flare → change one runs-on: line	GitHub keeps orchestrating; Flare supplies the runners — checks and logs stay put
Self-host from source	npm install && npm run setup	Everything, fully under your control

If a repo has no flare.yml, its .github/workflows run as-is (support matrix); cli import is optional if you later want the native format. Want zero ops? A hosted control plane is on the roadmap — the OSS core stays free forever.

One command: npx flare connect

From any repo, with FLARE_ACTIONS_URL pointed at your deployment:

npx flare connect              # probe, explain the wiring, dispatch HEAD, report the verdict
npx flare connect --dry-run    # print the plan, change nothing
npx flare connect owner/repo --wire   # also create the repo webhook (needs GITHUB_TOKEN + FLARE_ADMIN_TOKEN)
npx flare connect owner/repo --init --wire   # also scaffold flare.yml from the auto-detected stack

connect detects your stack from repo manifests (Node, Python, Go, Rust, and more) and your pipeline (flare.yml or existing workflows — both run unchanged), probes the deployment (claimed? App connected? install URL), prints the exact wiring recipe for your situation, then dispatches HEAD with one bounded wait and a compact verdict. With --init it scaffolds a missing flare.yml first (a stack-matched starter, or converted from your workflows — same as npx flare init, safe to re-run). Exit 0 means connected and verified, 1 means the verification run failed, 2 means usage or environment error. If nothing picks the run up, it tells you how to start an executor instead of stalling.

Or with your agent — paste this into Claude Code, Codex, Cursor, or OpenCode (the flare-setup skill teaches the same loop):

Set up Flare Actions for this repo: probe $FLARE_ACTIONS_URL with
`npx flare connect --dry-run`, wire whatever is missing (ask me before
any GitHub-side change), start an executor, and verify HEAD with a run
digest. Report the digest; never claim CI passed without one.

Runner mode: runs-on: flare

Two lanes, one deployment. Full Flare orchestration (above) replaces GitHub Actions end to end; runner mode keeps GitHub orchestrating and has Flare supply the machines:

# .github/workflows/ci.yml — the only change
jobs:
  test:
    runs-on: flare   # was: ubuntu-latest

Push, and GitHub routes the job to an ephemeral Flare runner: checks, logs, approvals, and branch protection stay exactly where they are. Enable it in dashboard Settings (off by default), run an executor with npm run runner -- --github, and read the trust model, limits, and BYO toolchain notes in docs/GITHUB-RUNNERS.md.

Common questions

• Do I change anything? No — delete nothing. Existing workflows run as-is under full orchestration, and runner mode is one runs-on: line.
• Where do logs live? Full orchestration: dashboard, CLI, and API (plus Check Runs on your PRs). Runner mode: on GitHub, as today.
• What do jobs run on? Your machines (npm run runner), managed seats (Cloudflare Containers), or — in runner mode — Flare capacity behind ephemeral GitHub runners.
• How is this cheaper? BYO runners cost whatever your hardware costs; every run reports compute minutes plus the Actions list-price equivalent, so the gap is a number (cli usage).

GitHub App setup

One click: dashboard → Settings → Connect GitHub. GitHub shows a pre-filled App (Contents read, Pull requests read, Commit statuses write, Checks write, push + pull_request events, webhook URL wired) — click Create, then install it on your repos. App ID, private key, and webhook secret land in D1, so the main worker and managed seats both pick them up. The checks:write permission is what makes failures show up as rich Check Runs (failing command + output tail) on the PR page; apps created before it existed just need the permission added in App settings.

Manual fallback (env-managed instead): create the App yourself with the same permissions/events and webhook URL https://<worker>/webhooks/github, then set GITHUB_WEBHOOK_SECRET, GITHUB_APP_ID, and GITHUB_PRIVATE_KEY via wrangler secret put (env takes precedence; Connect refuses while any of them is set). Install the App on your repo either way.

No App at all? The App is only required for automatic push/PR runs on private repos and for GitHub-side surfaces (commit statuses, Check Runs, PR comments, GitHub login). Token dispatch (CLI/API/MCP), source runs, scheduled runs, and cli local work without it — and for public repos a plain repo webhook pointed at https://<worker>/webhooks/github (with the webhook secret from dashboard Settings) triggers runs with no App installed.

Dashboard

Open https://<worker>/dashboard and log in with GitHub, email + password, or a passwordless magic link (first login of any kind claims admin). The CLI works with any token scope — readonly reads, runner also dispatches and reruns; issue named tokens in Settings.

• Races — agent races on one task: per-agent lanes on isolated Artifacts forks, live verification status, collision radar, AI verdict with rationale, and the immutable ledger (see docs/TOURNAMENTS.md).
• Repositories — browse the Artifacts namespace: file trees, file contents, commit history, and each repo's verification runs.
• Merge queue — verify-then-land for pull requests: entries queue per repo, verify against current main, and land one at a time (see docs/MERGE-QUEUE.md).
• Runs — every run with job logs, triage, and cost; admins can dispatch by branch, tag, or SHA, and re-run finished jobs. Runs linked to a race show their lane and verdict rank. Every terminal job also posts a GitHub Check Run — the PR page shows the failing command, its output tail, and inline annotations parsed from file:line output (requires the App's checks:write permission; commit statuses still work without it). Pull request runs also get one summary comment, edited in place as the run completes (needs pull_requests:write), including quarantined failures the green check skipped.
• Settings — webhook secret, GitHub App connect, run notifications, budgets, runner mode (runs-on: flare), self-healing, registration, teammates (allow GitHub users, invite by email with single-use 24h links), named API tokens (runner / readonly / admin, optionally scoped to repos or org/*, shown once, revocable), Pair a runner single-use codes for cli login, and the audit log.

Press ⌘K (or /) for the command palette, g t / g o / g m / g r to jump between views — every view is a shareable #/... link.

Preview environments

Every branch gets an isolated staging environment — separate D1 database and queues from production — via Cloudflare Worker Previews:

git checkout -b my-feature
npx wrangler preview
# → https://my-feature-flare-actions.<you>.workers.dev

All previews share one staging database (isolated from prod, not from each other). Preview secrets live in the shared base config, distinct from prod values — set once with wrangler preview base-config secret put NAME. Delete a preview with wrangler preview delete --name my-feature.

On pull requests, CI deploys a preview automatically once you add CLOUDFLARE_API_TOKEN + CLOUDFLARE_ACCOUNT_ID repo secrets. Mint that token with the per-Worker Editor role scoped to your Worker plus D1 and Queues edit access — least privilege for CI and agents, per Cloudflare's granular authorization launch.

Pipelines (flare.yml)

Put a flare.yml in your repo root. On every push, Flare fetches it at that exact commit, fans out one job per entry, and runners execute the steps:

jobs:
  test:
    steps:
      - run: node --version
      - run: npm ci && npm test

• Lookup: flare.yml at the push SHA (public fast path, no auth; private repos via the GitHub App installation token). Missing or invalid files fall back to one default echo job — pushes never fail to dispatch.
• Each step runs as sh -c in a fresh temp dir with FLARE_REPO, FLARE_SHA, FLARE_RUN_ID, FLARE_JOB_ID, and CI=true (GitHub parity) in the environment.
• Steps stop at the first non-zero exit; 10 min timeout (per-step timeout-minutes: 1–180 overrides) and 32 KB of captured output per step. shell: bash switches the interpreter. A step marked continue-on-error: true is recorded as failed but doesn't fail the job. Steps and jobs accept a bounded if: subset — always(), failure(), success(), cancelled() and !fn() negations — so cleanup and notification steps still run after a failure, and a job with if: always() runs even when a needs job failed. Jobs can declare retry: 2 (0–5): a failed attempt requeues automatically until the budget is exhausted, so flaky suites stop paging humans. Limits: 32 jobs, 100 steps/job, 64 KB file.
• Every job records machine-readable results (result JSON: per-step command, exit code, duration, output) alongside the human log — this is what agents consume to triage failures.
• ${{ secrets.NAME }} in steps and env reads per-repo secrets (Settings tab, write-only), encrypted at rest and masked in logs.

Full reference (matrix, needs, concurrency, containers, services, cache, artifacts, labels, timeouts): docs/PIPELINES.md.

Scheduled runs

Cron schedules live on the deployment — dashboard → Settings → Schedules, or GET|POST|DELETE /v1/admin/schedules — not in flare.yml: a repo, a ref (branch or tag), and a 5-field UTC cron, checked every minute by a Worker cron trigger. Each entry shows its last dispatch attempt, so a schedule that silently stops is visible instead of invisible — the exact failure mode GitHub's best-effort on: schedule is known for. Previews never fire schedules, failed attempts are stamped (no hot-looping), and a schedule's run gets commit statuses and private-repo pipeline fetching like any other dispatch.

Runner

npm run runner

No env setup needed — .env from setup is loaded automatically (explicit env vars still win). The runner shallow-checkouts the repo at the push SHA into a temp dir (needs git; set GITHUB_TOKEN for private repos) and executes each step there.

Runners advertise [os, arch, ...FLARE_LABELS] and only take jobs whose runs-on labels they all carry — this is how macOS, Windows, GPU, and docker boxes coexist. Any OS runs the same protocol; see docs/RUNNERS.md. Job caches and artifacts live in your deployment's R2 bucket (created by npm run setup).

Prefer zero boxes? npm run setup also provisions the managed executor: scale-to-zero seat containers on Cloudflare that pick up eligible Linux jobs automatically, with BYO runners as the backstop. See docs/CONTAINERS.md.

MCP server (agents)

Every deployment is an MCP server at /mcp: list runs, read logs and triage, dispatch runs, run and wait in one call with compact digests, re-run jobs, check flakes, generate pipelines. npm run cli -- mcp-config prints a paste-ready client config; details in docs/MCP.md.

Agent tournaments (Cloudflare Artifacts)

Race N coding agents on one task: isolated forks, real CI per attempt, collision radar, AI verdict, winner fast-forwarded, immutable ledger. The dashboard shows it as Races + Repositories + Merge queue next to Runs — same CI engine underneath, verifying every attempt. Try it on staging in ~10 minutes — docs/TOURNAMENTS.md:

npm run cli -- login               # pair this machine (writes .env)
npm run cli -- races               # list races, or `races <id>` for one board
npm run cli -- claim <raceId> <agent>  # claim a lane (forks a workspace)
npm run cli -- verdict <raceId>    # ranking + why-it-won rationale
npm run cli -- repos [name]        # browse the Artifacts namespace

Built for agents

GitHub Actions is built for humans — commit, push, then stare at a queue. Flare is built for agents: trigger, wait, and read results over the API, MCP, or CLI. No git ceremony, no sleep loops, no log spelunking.

• One-call verify loop — run_and_wait (MCP) or cli run dispatches and blocks until the run is terminal (GET /v1/runs/:id/wait?timeout=60 under the hood). Verify → fix → repeat, without a polling loop.
• Zero-latency inner loop — cli local runs flare.yml in the current working tree, on this machine, with no server and no commit: the working-tree code, a warm local cache (~/.flare/cache), artifacts in .flare/artifacts/, and the same execution engine as the server (continue-on-error, if:, needs, matrix) with the same curated step env (FLARE_*, CI=true). cli local --parity reports image/cache/env divergences against the predicted cloud lane without running. Server dispatch stays the final parity check.
• Priority lane — priority: 0–10 on dispatch jumps queued batch work, so an agent's verification beats the nightly backlog.
• Explain, don't spelunk — cli explain <runId> turns a run into one narrative: verdict first, then failing steps, output tails, triage, and exact rerun commands (--json included).
• Dry-run dispatch — append --dry-run to run / dispatch (including --source, with no upload) to plan the fan-out — queued/blocked + reasons, runtime priors, live group state, budget verdict — with zero writes.
• Machine-shaped I/O — every CLI command accepts --json (one versioned envelope on stdout), and API failures carry a stable code
  • next-step hint (docs/ERRORS.md).
• Token-efficient digests — GET /v1/runs/:id/digest (or get_run_digest) returns each job's failing step command, exit code, a bounded output tail, and AI triage in a few KB — context-window friendly, no megabyte logs.
• Near-instant pickup — BYO runners poll every 2s idle / 500ms after a job; managed seats wake immediately over the queue.
• Machine-readable everything — per-step structured results with exit codes and durations; the dashboard is optional.
• No git required — dispatch by SHA or branch with an inline pipeline, or go further: cli run <repo> --source uploads a tarball of the working tree (50 MB cap, path-traversal-guarded on both executors) and runs it server-side with full parity — seats, containers, services — with no commit anywhere. Append --dry-run to run / dispatch (incl. --source, no upload) to plan the fan-out — queued/blocked + reasons, priors, budget — with zero writes.
• Measured, not claimed — npm run bench (against npm run dev or a deployment) reports dispatch → job pickup → terminal latency: on a local worker, p50 ≈ 38 ms / 17 ms / 63 ms. Nothing here waits on a 2–3 minute hosted queue.

# agent inner loop: run the working tree locally, no server, no commit
npm run cli -- local                 # all jobs; warm cache across runs
npm run cli -- local test --file flare.yml

# agent verify loop: dispatch, wait, print the digest (exit 1 on failure)
npm run cli -- run owner/repo "$(git rev-parse HEAD)" --priority 9
npm run cli -- run owner/repo --source --priority 9   # uncommitted tree, server-side
npm run cli -- watch <runId>        # block on an existing run + digest
npm run cli -- dispatch owner/repo main --priority 9   # fire and forget

Coming from GitHub Actions

Drop-in: delete nothing. If a repo has no flare.yml, Flare reads its .github/workflows/*.yml at the commit and runs the matching workflows — on: push / pull_request / workflow_dispatch / schedule are honored, and run: steps, matrices, needs, concurrency, containers, services, actions/cache, and actions/upload-artifact translate as-is. JS/container actions and unsupported expressions are dropped with warnings, never guessed at. Full support matrix + trigger mapping: docs/GITHUB-ACTIONS-COMPAT.md.

Full fidelity: migrate to the native format (better fidelity, richer features like retries and egress allowlists):

npm run cli -- import .github/workflows/ci.yml > flare.yml

Translates runs-on, steps, matrices, needs, concurrency, containers, services, caches, and artifacts; everything unmappable becomes a warning on stderr (exit stays 0) so you see exactly what needs a human eye.

No GitHub App? For public repos, point a plain repo webhook at https://<worker>/webhooks/github with the secret from the dashboard (Settings → Webhooks) — runs trigger with no App installed. The App adds private repos, commit statuses, Check Runs, PR comments, and GitHub login.

Status badges

Public, embeddable, no token needed:

[![flare](https://<worker>/v1/badge.svg?repo=owner/name&branch=main)](https://<worker>/dashboard)

npm run cli -- badge owner/name main prints the snippet. For private repositories, list them under Settings → Status badges so the public endpoint serves unknown instead of leaking pass/fail. For required-checks UX, the GitHub App already posts commit statuses on every run — mark them required in repo Settings → Branches.

AI failure triage

Every failed job is triaged automatically by Workers AI (@cf/meta/llama-3.1-8b-instruct-fp8-fast, inside the 10k-neurons/day free tier): likely cause, culprit file/command, and one concrete fix. It appears on the job in the dashboard and CLI. Forks without the AI binding simply skip triage — nothing breaks.

Notifications

Every finished run emails all registered email users: status, branch, jobs, cost, and the AI triage excerpt on failures. Set the sender in dashboard Settings → Run notifications (the domain must be enabled for Email Sending first); pick all completions, failures only, or off. Env NOTIFY_FROM_EMAIL overrides the dashboard value. Deployments without a sender simply skip — nothing breaks.

Chat webhooks: paste a Slack, Discord, or Mattermost-compatible webhook URL in Settings → Run notifications and the same summary posts there on every finished run — independently of email, so it works even with no sender configured. The URL is write-only and encrypted at rest with the secrets data key.

CLI

npm run cli -- runs                    # list runs
npm run cli -- local [job]             # run flare.yml here (no server, warm cache)
npm run cli -- run <repo> <sha>        # dispatch, wait, print the compact digest (exit 1 on failure)
npm run cli -- run <repo> --source     # upload the working tree and run it (no commit needed)
npm run cli -- run|dispatch ... --dry-run  # plan the fan-out (queued/blocked/budget), zero writes
npm run cli -- watch <runId>           # wait on an existing run + digest
npm run cli -- cancel <runId>          # cancel queued/blocked jobs of a run
npm run cli -- logs <runId>            # jobs, steps, triage, logs
npm run cli -- explain <runId>         # one narrative: verdict, failures, next command
npm run cli -- dispatch <repo> <sha> [--priority N]   # trigger a run
npm run cli -- rerun <runId> <jobId>   # reset a finished job
npm run cli -- flaky <repo>            # per-job failure rates
npm run cli -- bottlenecks <repo>      # slowest checks: p50/p95 run time + queue wait
npm run cli -- quarantine list|add|remove <repo> [test]  # flaky-test quarantine (admin writes)
npm run cli -- tests <runId>           # per-test results and failing tests
npm run cli -- egress <runId>          # per-job egress by host
npm run cli -- queue [labels]          # live queue + projected claim order (admin)
npm run cli -- cache list|purge [prefix]  # cache entries (admin)
npm run cli -- cache stats             # shared warm-cache hit rate (7d)
npm run cli -- usage [days] [repo]     # runs, jobs, compute-minutes for billing
npm run cli -- paused                # repos auto-paused for runaway spend (admin)
npm run cli -- resume <repo>         # resume a paused repo (admin)
npm run cli -- search <query...>       # search all job logs (branch:main level:error ...)
npm run cli -- artifacts <runId>       # list artifacts
npm run cli -- badge <repo> [branch]   # badge snippet
npm run cli -- import <workflow.yml>   # Actions -> flare.yml
npm run cli -- mcp-config              # MCP client config
npm run cli -- devbox ...              # persistent warm dev boxes (local docker)
npm run cli -- connect [repo] [--wire] [--dry-run]  # probe, wire, and verify this repo in one command
npm run cli -- github-jobs [repo]      # ephemeral runner-mode jobs (status, duration, list price)
npm run cli -- login [--url U] [--code C]  # pair this machine (writes .env)
npm run cli -- races [raceId]         # list agent races, or one race board
npm run cli -- repos [name] [path]    # list forge repos, or browse one
npm run cli -- claim <raceId> <agent>  # claim a race lane (forks a workspace)
npm run cli -- verdict <raceId>        # winner ranking + why-it-won rationale

Every command accepts --json: stdout becomes one versioned envelope { version: 1, command, data } (failures keep stderr + exit codes). API failures carry a stable code + next-step hint (docs/ERRORS.md); the CLI prints hint [code] after the error line.

API

• GET /dashboard — dashboard UI (/ redirects here)
• POST /webhooks/github — GitHub App webhook (HMAC verified)
• GET /mcp — MCP server metadata (public); POST /mcp — MCP JSON-RPC
• POST /v1/runs/dispatch — trigger a run by SHA, branch, or tag, optional inline pipeline, priority (0–10), or source (uploaded working tree)
• POST /v1/runs/dispatch/dry-run — plan the fan-out with zero writes (run scope)
• POST /v1/source — upload a gzipped working-tree tarball (≤50 MB); GET /v1/source/:id — fetch it (run scope)
• POST /v1/admin/pair-codes, POST /v1/pair/exchange — mint a pairing code (admin), exchange it for a runner token (public, throttled)
• GET /v1/github/jobs, POST /v1/github/jobs/next — runner-mode job list + JIT claim lane (read / run scope)
• GET /v1/bottlenecks?repo=&days= — slowest checks: p50/p95 run time + queue wait (read scope)
• GET /v1/cache/stats — shared warm-cache hit rate over the trailing 7 days, overall plus per scope (read scope)
• GET|POST /v1/quarantine — list / add / remove quarantined tests (read scope; admin writes)
• GET /v1/runs/:id/tests, GET /v1/runs/:id/egress — per-test results, per-job egress (read scope)
• GET /v1/admin/queue, GET /v1/usage?days= — live queue, billing usage (admin / read scope)
• GET|DELETE /v1/admin/paused — kill-switch state: paused repos with attribution + one-click resume (admin only)
• GET /v1/search/logs?q= — full-text log search (read scope)
• GET /v1/runs/:id/wait?timeout= — block until terminal (1–90s), returns the run + timedOut
• GET|POST|DELETE /v1/admin/secrets — repo secrets, names listed, values write-only (admin only)
• GET /v1/runs?limit=&offset= — list runs, newest first (admin, runner, or readonly token; limit 1–200)
• GET /v1/runs/:id — run + jobs + cost summary (admin, runner, readonly)
• GET /v1/runs/:id/digest — compact agent digest: failing steps, bounded tails, triage (read scope)
• GET /v1/runs/:id/artifacts — list a run's artifacts (read scope)
• GET /v1/jobs/next?labels= — pull next matching queued job (run scope)
• POST /v1/runs/:id/status — runner status callback (admin or runner token)
• POST /v1/runs/:id/jobs/:jobId/rerun — reset a finished job (run scope)
• POST /v1/runs/:id/jobs/:jobId/heartbeat — executor liveness; running jobs quiet 20m+ are requeued (run scope)
• PUT|GET /v1/cache/:key — build cache blobs (run scope)
• PUT|GET /v1/jobs/:jobId/artifacts/:name — artifacts (run to write, read to fetch)
• GET /v1/badge.svg?repo=&branch= — status badge (public)
• GET /v1/flaky?repo=&days= — per-job failure rates (read scope)
• GET /v1/admin/tokens — list access tokens (admin only)
• POST /v1/admin/tokens — issue a token, shown once (admin only; optional repos scoping)
• POST /v1/admin/tokens/:id/revoke — revoke a token (admin only)
• POST /v1/runs/:id/cancel — cancel queued/blocked jobs of a run (running jobs finish naturally)
• POST /v1/admin/reset, POST /v1/admin/reset/confirm — self-serve password reset (public, throttled, single-use 1h link)
• GET /v1/admin/audit — audit log (admin only)
• GET|POST /v1/admin/schedules — list / create cron schedules (admin only)
• POST /v1/admin/schedules/:id — enable or disable a schedule (admin only)
• DELETE /v1/admin/schedules/:id — delete a schedule (admin only)
• POST /v1/admin/generate — natural language → flare.yml (admin only)
• GET|POST /v1/admin/settings — webhook secret, run notifications, badge visibility (admin only)
• GET /v1/admin/users — allowed GitHub users, email users, invites (admin only)
• POST /v1/admin/users|users/email|users/invite — allow/remove users, mint single-use invite links (admin only)
• POST /v1/admin/register — redeem an invite, or self-register by email when open registration is on (public, throttled)
• POST /v1/admin/bootstrap — first-run admin claim (open until claimed, throttled)
• POST /v1/admin/login, POST /v1/admin/logout — email sessions (throttled)
• POST /v1/admin/magic/request, POST /v1/admin/magic/consume — passwordless magic-link login (public, throttled, single-use 15 min; emailed links open a dashboard confirm screen so mail scanners cannot burn them)
• GET|POST /v1/admin/github/* — GitHub App connect + login flows
• GET /v1/admin/status — setup state for the dashboard (public)
• GET /v1/tournaments, GET /v1/tournaments/:id — race list + board: attempts, verdict, ledger (read scope)
• POST /v1/tournaments, POST /v1/tournaments/:id/claims — open a race, claim a lane (run scope)
• GET /v1/repos, GET /v1/repos/:name + /tree, /blob, /commits — browse the Artifacts namespace (read scope)

Cost

The core — webhooks, dispatch, dashboard, D1 history, queues, R2 cache/artifacts — fits Cloudflare's free tier at small-to-medium scale: Workers (100k requests/day), Queues (10k operations/day ≈ 3,300 dispatches/day), D1 (5M rows read + 100k rows written/day, 5 GB storage), R2 (10 GB storage, zero egress). The managed seats executor adds Cloudflare Containers, which need the Workers Paid plan ($5/mo base) — BYO runners stay free. Retention keeps storage honest: finished runs and their artifacts prune after 90 days, cache blobs after 90 days without a hit, all bounded per pass. Every run reports its compute minutes plus the Actions list-price equivalent, so the gap is a number, not a claim. See Workers, Queues, D1, and R2 pricing.

Give it to your agent

Clone the repo and point any coding agent at it — AGENTS.md teaches it the stack, commands, architecture, and conventions. Scaffold a repo in one command with npx flare init (writes a stack-matched flare.yml + an AGENTS.md snippet teaching the verify loop), or install the flare-verify skill in Claude Code / Codex / Cursor — plus the flare-setup skill for one-command onboarding (connect, wiring, executor, verify). npm run setup is fully non-interactive (preview with npm run setup -- --dry-run). The inner loop is npm run check: oxlint on changed files + one type check + only the affected tests, serialized across worktrees (see docs/DEV-SPEED.md); npm run check -- --full plus npm run deploy:dry matches what CI gates on. For Cloudflare access, mint the agent a per-Worker Editor token (plus D1/Queues edit) as described above — never your account-wide credentials. (Cloudflare's new cf CLI, open beta since 2026-09-28, looks promising for agent-driven Cloudflare work; until it stabilizes, wrangler remains this repo's supported path.)

License

MIT — see LICENSE.