Workflows
Orchestration. Every run is a durable Workflow instance with a step timeline.
FlareDispatch is BYOC CI/CD. Heavy jobs — agentic code review, Playwright e2e, acceptance suites, matrix fan-outs, security scans — run on Cloudflare instead of GitHub-hosted runners. Each organization deploys one Dispatcher Worker and one GitHub App into its own Cloudflare account; there is no multi-tenant service.
Workflows
Orchestration. Every run is a durable Workflow instance with a step timeline.
Containers
Execution. Jobs run in sandboxed containers under deny-all egress.
Browser Rendering
Playwright e2e and recorded product demos over CDP.
R2
Cache and artifacts, with tokened log links on every check-run.
A run starts from a GitHub Actions step (flare-dispatch-action HMAC-signs and POSTs the dispatch), a GitHub App webhook (repo events fire runs directly), or a cron schedule. The verdict lands on the pull request as a flare-dispatch/<run> check-run; gate branch protection on that name.
Tag-driven runs use the GitHub App’s push event. New Apps created from the manifest subscribe to it. Existing Apps retain their own event settings: enable Pushes under GitHub App settings → Permissions & events, then save the subscription before expecting tag pushes to dispatch.
Action-mode deployments can retain the App’s event subscriptions and set
GITHUB_WEBHOOK_EVENTS: "check_run,check_suite" in their Worker overlay. Signed
deliveries outside this comma-separated allowlist receive 202 without starting
runs or signalling workflows, so PR webhooks cannot duplicate Action-mode reviews.
Check reruns still work with GITHUB_WEBHOOK_SECRET configured. Omitting the
allowlist accepts all subscribed events; an empty value accepts none.
Runs are written against a layered Effect-TS DSL: capabilities wrap Cloudflare primitives, primitives compose them into build, test and cache steps, and recipes are the named runs a Dispatcher registers. Steps are typed, errors are tagged, and matches are exhaustive.