If you’ve searched “Cloudflare Stream cost per GB” and come away confused, you’re not missing something obvious — the number doesn’t exist. Stream doesn’t bill by the gigabyte. It bills by the minute. That single difference is the reason the math never lines up with how every other cloud storage or bandwidth product prices itself, and it’s why a Cloudflare community thread asking this exact question sits unanswered.
Cloudflare Stream bills per minute, not per GB: roughly $5 per 1,000 minutes stored and $1 per 1,000 minutes delivered, per their public pricing at time of writing. There’s no official per-GB rate to compare it against, because a “minute” of video isn’t a fixed number of bytes — a minute of 4K footage and a minute of 480p footage cost Cloudflare wildly different amounts of storage and bandwidth, yet Stream charges you the same either way. That’s the whole source of the confusion, and it’s worth understanding before you commit to a pricing model for your video infrastructure.
Why “per GB” doesn’t exist for Stream
Every other storage or CDN product you’ve priced — S3, R2, Bunny — bills you for bytes. You store a gigabyte, you pay for a gigabyte. You deliver a gigabyte, you pay for a gigabyte. It’s a direct, physical unit: the meter reads bytes because bytes are what’s actually moving through disks and pipes.
Stream abstracts that away. It charges by the minute of video content, regardless of resolution, bitrate, or codec. A one-minute 1080p clip and a one-minute 4K clip both cost the same on your invoice, even though the 4K clip might be five to ten times the file size. That’s a deliberate simplification — it means you can estimate your bill from content length alone, without knowing anything about encoding settings. But it also means there’s no stable conversion rate from minutes to gigabytes. The exchange rate moves with your content.
The rough mental model, if you need one
If you’re trying to sanity-check a Stream estimate against a per-GB quote from another provider, you need a rule of thumb, not a formula. Adaptive HLS delivery typically runs somewhere in the range of a few hundred kilobits per second at the low end up to several megabits per second for high-resolution renditions, averaged across the bitrate ladder a viewer actually pulls. That puts a “typical” minute of adaptively-streamed video somewhere in the tens of megabytes, with plenty of room to move in either direction depending on resolution mix and how aggressively the encoder compresses.
The point isn’t to nail a precise conversion — it’s to notice that the ratio is never fixed. A catalog of short, high-resolution product demos sits at a very different minutes-to-GB ratio than a catalog of long, lightly-compressed lecture recordings. Any per-GB number you back into from Stream’s per-minute rate is only true for your specific content mix, on that day, with those encoding settings.
When per-minute billing works for you
Per-minute pricing isn’t a bad model — it’s just a different bet, and it pays off in specific situations:
- Short clips. If your average video is under a couple of minutes — product demos, social clips, UGC — you’re paying for very little runtime regardless of resolution, and the per-minute rate stays predictable and small.
- High resolution, low volume. If you need 4K or high-bitrate delivery but don’t publish much of it, per-minute billing effectively caps your storage cost at the same rate as a lower-resolution catalog would pay. A per-GB model would charge you more for the extra bytes; Stream doesn’t.
- Predictable-length content. Webinars, courses, and other formats with a known runtime make Stream’s bill easy to forecast up front — you know the minutes before you upload.
When it works against you
The same mechanism runs in reverse for a different content shape:
- Long, lightly-watched libraries. Archival footage, long-form interviews, or a large back catalog that gets occasional views still accrues storage minutes every month, whether anyone watches or not. A per-GB model charges you for the bytes at rest; a per-minute model charges you for the runtime at rest — and long videos have a lot of runtime.
- High-bitrate content at scale. If your catalog leans toward 4K or high-bitrate masters and you publish a lot of it, you’re not getting the “capped” benefit described above — you’re paying flat per-minute rates on content that would cost less under a model tied to actual bytes.
- Growing catalogs with encoding fees on top. Some per-minute providers (see our breakdown of Mux’s encoding-per-minute model) charge separately for the initial encode, so a growing catalog compounds two line items instead of one. Stream doesn’t charge for encoding, but the storage-minutes line still grows every time you add video and never remove it.
If none of that maps cleanly onto your catalog, the more useful question isn’t “what’s Stream’s per-GB rate” — it’s “does my content behave more like bytes or more like minutes.” For a wider view of how the major providers price video differently by model, we’ve laid out the full comparison across pricing models.
The alternative: pricing that’s actually per GB
rehelios prices the way S3 and R2 do: $0.02 per GB-month stored, $0.005 per GB delivered, encoding included at no charge. There’s no minutes-to-bytes conversion to reason about, because the meter reads bytes directly — the same unit every other piece of your cloud infrastructure already bills in. A large, lightly-watched catalog stays cheap because storage cost tracks actual disk usage, not runtime. A catalog that keeps growing doesn’t add a growing encoding line item, because encoding is free regardless of how many minutes you process in a month.
That’s the same billing model Bunny uses — per-GB storage and delivery is not new. Where rehelios differs from Bunny is the interface on top of that pricing: a REST API, a CLI, and an MCP server that let an AI agent upload, import, and publish video autonomously in a single tool call, without a human approving each step. You can see the full breakdown on the Cloudflare Stream comparison page, including how the per-minute and per-GB models diverge across a few concrete catalog shapes.
If you’re mid-estimate right now, the short version is this: don’t try to force Stream’s per-minute number into a per-GB shape, and don’t assume a per-GB quote from another provider translates cleanly into minutes either. Match the billing model to your content, not the other way around. You can check exact numbers for your own catalog on the pricing page before committing either way.