-
Notifications
You must be signed in to change notification settings - Fork 0
Pricing
Rates read from Cloudflare's own pricing pages on 2026-08-03. They change; the sources are linked at the bottom and the arithmetic here is deliberately simple enough to redo in a minute.
Two halves, and only one of them is Cloudflare.
| Where it runs | How the bill behaves | |
|---|---|---|
| App, API, database, storage | Cloudflare Workers, D1, R2 | Small and predictable. Storage dominates. |
| Encoding | A machine you provide | The variable half. Yours to size, and free if you already own the box. |
ffmpeg cannot run on Workers and never will, so a media worker is a container you run somewhere: a spare desktop, a VM, a spot instance that dies without consequence. It claims jobs over HTTP, encodes, uploads, and keeps nothing. If you already have a machine, this half of the bill is zero.
R2 charges nothing for egress. For a review tool that is the whole game: what a delivery platform actually does all day is send video to people watching it. The same traffic on S3 plus CloudFront is usually the largest line on the bill, and here it is not a line at all.
Played bytes go through the Worker, not straight from R2. Both stores hand
out an app-relative /api/v1/media/<key> and the API streams the object back,
so a viewer scrubbing a proxy is spending Worker requests, not just R2 reads.
That is a deliberate design decision -- one code path, both deployment targets, and access control that cannot be bypassed by holding a URL -- and it is the meter most likely to grow with viewers rather than with footage. It is also the one to revisit first if a deployment ever gets expensive: R2 can presign directly, at the cost of that single code path.
Workers (Paid, $5/month base)
| Meter | Included | Beyond |
|---|---|---|
| Requests | 10 million / month | $0.30 per million |
| CPU time | 30 million CPU-ms / month | $0.02 per million CPU-ms |
CPU time, not wall time. Streaming a large object is mostly waiting on the network, which is not billed.
R2
| Meter | Free tier | Beyond |
|---|---|---|
| Storage | 10 GB-month | $0.015 per GB-month |
| Class A (writes, lists) | 1 million / month | $4.50 per million |
| Class B (reads) | 10 million / month | $0.36 per million |
| Egress | unlimited | $0 |
D1
| Meter | Included (Paid) | Beyond |
|---|---|---|
| Rows read | 25 billion / month | $0.001 per million |
| Rows written | 50 million / month | $1.00 per million |
| Storage | 5 GB | $0.75 per GB-month |
D1 is unlikely to appear on your bill. Onelight stores metadata there -- projects, versions, comments, jobs -- and the included allowances are enormous against that.
Storage is originals plus renditions. The original is kept: it is the thing being reviewed, and a proxy is not a master. On top of it a video version gets a proxy ladder (1080p and 540p, plus 2160p when the source is 4K), a poster, a sprite sheet, and waveform data; an HDR source adds two more proxies. Renditions are small next to the original, so the original sets the number.
Class A operations are writes. An upload is one per part, and parts are 16 MiB, so a 40 GB master is about 2,560 of them: $0.012 at the standard rate. Uploads are not where the money goes.
Class B operations are reads, one per range request the Worker makes to serve a scrub or a still.
Worker requests are every API call plus every media read, as above.
Storage is the term you can compute today; the request and CPU terms wait on Benchmarks, which measure what a real session actually asks for. Assumptions are stated so you can replace them with your own.
Assume 100 GB of camera masters per month retained for a year, renditions adding 10% on top.
| Month | Stored | R2 storage cost |
|---|---|---|
| 1 | 110 GB | $1.50 |
| 6 | 660 GB | $9.75 |
| 12 | 1.32 TB | $19.80 |
Add the $5 Workers base and a plausible tens-of-dollars for a small VM if you do not already have a machine to encode on.
For scale: 1 TB stored costs $15 a month, and serving all of it to viewers costs nothing.
Honest gaps, not estimates:
- CPU-ms per media request. Streaming is cheap in CPU terms, but "cheap" is not a number. It decides whether the 30 million included CPU-ms is reached before the 10 million included requests.
- Requests per review session. A reviewer scrubbing a timeline issues range requests, and how many depends on player behaviour rather than on footage. This is the term that scales with an audience.
- GB per hour of footage, by codec and resolution, which turns "hours of material" into a storage number.
- Encoding throughput, which decides how many workers a delivery needs.
All four come from Benchmarks. This page will be updated with measured numbers rather than guesses; anything above that is arithmetic on Cloudflare's published rates is labelled as an assumption.
The Docker deployment has no per-request cost at all: one server, one or more workers, storage on a disk you own. What you pay is the machine and the disk. Onelight runs the same code either way -- the job protocol names storage by key and never assumes a filesystem, which is what lets one build serve both.