06 — Cost Estimation

The economic case for FlareDispatch: heavy CI compute billed at Cloudflare serverless rates (per vCPU-second, scale-to-zero) instead of GitHub Actions per-minute rates. This spec lays out the pricing model, worked estimates at two volumes, and a head-to-head with GHA list pricing.

All figures are Workers Paid, current as of 2026-05. Cloudflare pricing changes — treat these as planning estimates, re-check the linked sources before committing a budget.

Pricing model — what you pay for

A FlareDispatch deploy is a single Worker plus its bindings. The cost components:

The dominant variable cost is Containers — that’s where test commands actually execute. Everything else tends to stay within the included quotas for small-to-medium volume.

Source: Workers pricing, Containers pricing, Browser Rendering pricing, R2 pricing, D1 pricing.

Per-execution cost anatomy

A single offload-test-shaped execution (clone → install → test → upload log):

• Worker / Workflow CPU — the step bodies are I/O-bound (spawn container, await exit, write D1). A few hundred CPU-ms per execution. Negligible against the 30M CPU-ms monthly quota.
• Container vCPU-seconds — the real cost. A standard-2 instance (1 vCPU, 6 GiB) running an 8-minute test = ~480 vCPU-s ≈ $0.0096 in vCPU, plus ~$0.0072 GiB-s memory ≈ ~$0.017 per execution before the included quota.
• R2 — log NDJSON is kilobytes; a Playwright report archive is single-digit MB. Storage cost rounds to zero; egress is free.
• D1 — two row writes per step. Free tier.

Rule of thumb: container compute ≈ (vCPU-s + GiB-s) × wall-time, and that’s ~95% of the marginal cost of a run. Browser-heavy runs (playwright-e2e, cdp-acceptance) add Browser Rendering hours on top — see the trade-off table in 02-runs § playwright-e2e.

pie showData
  title Marginal cost of one execution
  "Container compute (vCPU-s + memory)" : 95
  "R2 + D1 + Worker CPU" : 5

Worked estimate — small team

Assumptions: 200 PRs/month, ~8 min average run wall time, 4-shard matrices, standard-2 containers.

Worked estimate — 10× volume

Same shape, 2,000 PRs/month. Container compute scales roughly linearly; Browser Rendering starts to exceed the included 10 browser-hours; R2 storage grows but stays cheap.

Cost scales sub-linearly with volume — the $5 base and the included quotas are fixed, so only the variable components grow:

xychart-beta
  title "FlareDispatch monthly cost by volume (USD, mid-range)"
  x-axis ["200 PRs / mo", "2000 PRs / mo"]
  y-axis "USD per month" 0 --> 100
  bar [12, 75]

Head-to-head with GitHub Actions

GHA bills standard Linux runners at $0.008/minute beyond the plan’s included minutes; larger runners (4–64 vCPU) cost 2–16× that. The jobs FlareDispatch targets — Playwright e2e, acceptance suites, big matrices — are precisely the long, wide ones.

Illustrative: a 4-shard Playwright suite, ~8 min wall time per shard, 200 PRs/month.

xychart-beta
  title "Monthly cost — 200 PRs, 4-shard Playwright suite (USD, list price)"
  x-axis ["GitHub Actions", "FlareDispatch"]
  y-axis "USD per month" 0 --> 60
  bar [52, 12]

The gap widens as suites get longer and wider, because GHA bills wall-clock-minutes-per-shard while CF bills vCPU-seconds with scale-to-zero. For cheap fast jobs (lint, unit) the comparison inverts — GHA’s included minutes make them effectively free — which is exactly why those jobs stay on GHA (see PRD § Non-goals).

This is a list-price comparison, not a benchmark. Actual savings depend on suite shape, runner size, and how much of the GHA included-minutes allowance a team already consumes.

Cost levers

Ways a run author or operator reduces the bill:

• Right-size the container. standard-2 is the default; a lint-only run can drop to basic (1/4 vCPU, 1 GiB). Instance types are listed in 05-byoc § Wrangler config.
• Cache aggressively. The installCached primitive (02-runs § cache, 03-dsl § installCached) skips re-install on R2 cache hits — install time is often a third of a run’s wall time.
• Prefer cf-browser-rendering for short browser tests. It uses the included browser-hours; in-container Playwright trades that for container vCPU-seconds. See 02-runs § playwright-e2e.
• Set R2 lifecycle retention. Logs at 14 days, artifacts at 90, cache at 30 keeps R2 storage flat. Policy in 05-byoc § Retention and cleanup.
• Gate Webhook-mode runs. A run’s gate (04-gha-integration § Webhook mode) skips drafts, bots, and skip-*-labelled PRs so expensive runs don’t fire on every push.
• Declare maxConcurrency. Caps simultaneous shards so a large matrix can’t spike Container vCPU usage past the account aggregate (1,500 vCPU); see 01-architecture § Platform limits.

What to watch

Cost-relevant signals from 05-byoc § What to monitor:

• Container vCPU-minutes trending toward / past the included 375/month — the first overage line to appear.
• Browser Rendering quota past 80% of the included 10 browser-hr — switch short tests away from in-container mode, or accept the $0.09/hr overage.
• R2 storage growth past ~50 GB — revisit lifecycle retention.