§00 / Manifest pre-implementation

Offload the expensive half of GitHub Actions onto Cloudflare.

FlareDispatch moves Playwright e2e, acceptance suites, sharded matrices, and security scans off GitHub Actions and onto Cloudflare — billed per vCPU-second on your own account. GHA stays the trigger; runs take the heavy compute.

§01 / Why it pays off

Heavy CI, at the price of raw serverless compute.

01 / Cost

Pay per vCPU-second

Heavy compute is billed at Cloudflare Container rates — per vCPU-second, scale-to-zero between runs — instead of GitHub Actions per-minute. The jobs that dominate your CI bill move to the cheapest place to run them.

02 / Headroom

No platform ceilings

No 6-hour job limit. No 10 GB cache cap. Artifact retention you set, not a fixed 90 days. The limits that push teams onto self-hosted runners simply aren't there.

03 / Fit

Drops into your setup

GitHub Actions stays the trigger and the PR gate. One wrangler deploy into the Cloudflare account you already pay for. Results land as a GitHub Check Run — no new dashboard, no runner fleet to operate.

§02 / Positioning

Every option trades away one of three things. FlareDispatch keeps all three.

Hosted runners are easy but billed per minute with hard ceilings; self-hosted and hybrid runners drop the ceilings but hand you a fleet to operate. FlareDispatch runs on serverless Cloudflare primitives — in the account you already own.

Heavy-CI option Serverless, scale-to-zero compute No 6 h / 10 GB ceilings No runner fleet to operate
GHA hosted runners
Self-hosted runners
Buildkite Agent (hybrid)
FlareDispatch
§03 / The code

Every recipe — toggle the workflow against its typed run.

Playwright e2e suite, sharded across the browser pool. Recommended: Action mode. Full recipe →
# Recipe: browser tests (Playwright e2e) on Cloudflare
#
# Use case: a Playwright suite that is slow and burns GHA minutes. Offload it
# to the shipped `playwright-e2e` run, which shards the suite across the
# Cloudflare Browser Rendering pool. GHA only fires the dispatch (~10 s) and
# the result comes back as a check-run.
#
# Mode: Action mode, fire-and-forget. See specs/04-gha-integration.md.
# Run:  playwright-e2e — see specs/02-runs.md#3-playwright-e2e.

name: e2e
on:
  pull_request:
    paths: ["apps/**", "packages/**"]

jobs:
  browser-tests:
    runs-on: ubuntu-latest
    steps:
      - uses: openhackersclub/flare-dispatch-action@v1
        with:
          run: playwright-e2e
          endpoint: ${{ vars.FLAREDISPATCH_ENDPOINT }}
          hmac-secret: ${{ secrets.FLAREDISPATCH_HMAC }}
          inputs: |
            {
              "repo": "${{ github.repository }}",
              "sha": "${{ github.sha }}",
              "baseURL": "https://staging.example.com",
              "shards": 4,
              "browserMode": "cf-browser-rendering",
              "uploadReport": true
            }

# Branch protection: require the check-run `flare-dispatch/playwright-e2e`,
# not this GHA job — the job succeeds the moment dispatch is accepted.
§04 / Design philosophy

Three bets the design is built on.

  1. §04.01

    Progressive offloading.

    Move CI to Cloudflare one job at a time — the heaviest, most expensive jobs first. GitHub Actions stays the trigger and keeps the cheap jobs; nothing is all-or-nothing.

  2. §04.02

    Runs are typed programs, not YAML.

    A run is an Effect-TS program — Schema-typed inputs and outputs, composable steps, tagged errors, exhaustive matching. Fork it, vendor-edit it, unit-test it without booting a container.

  3. §04.03

    BYOC by construction.

    Every code path assumes the run is deployed in your own Cloudflare account — no multi-tenant operator, no hosted SaaS to trust. The specs are the contract; the runs are yours.

§05 / Read on

Pre-implementation. The specs are the contract.