---
slug: cloudflare-os-xl-05-media
title: Cloudflare OS: images, video and media
canonical: https://miscsubjects.com/a/cloudflare-os-xl-05-media
---

*Part 5 of [Cloudflare OS XL](/a/cloudflare-os-xl), an inventory of the Cloudflare platform this build does not have installed.*

Every article on this site has a hero image. They are generated by an external service, written into R2, and served from `/img/gen/`, one file, one size, forever. A hero on a phone downloads the same object as a hero on a desktop.

That is the whole media stack. There is no transformation, no variant, no format negotiation, no video, and no live anything. Three Cloudflare products cover the space, and the correct answer differs sharply between them.

## Images

Images is Cloudflare's platform for image pipelines: storage, transformation, and delivery through named variants.

The specific thing it fixes here is the one-file-one-size problem. Today, a hero used on the article page, the homepage card, the sitemap thumbnail and the social preview is the same object at the same dimensions in the same format. With Images, the original is stored once and requested at a variant:

```
https://imagedelivery.net/<hash>/<image-id>/hero
https://imagedelivery.net/<hash>/<image-id>/card
https://imagedelivery.net/<hash>/<image-id>/og
```

Format negotiation is automatic — a browser that accepts AVIF gets AVIF — and resizing happens at the edge rather than at generation time.

There is a second, less obvious fit. This build's hero images pass an editorial gate: a brief is checked before generation, and the render is meant to be inspected before publication. That gate currently operates on a prompt and a finished file. Images' transformation API means the *published* crop can be adjusted after the fact without regenerating anything, which is the difference between "this hero is wrong, generate another" and "this hero is cropped wrong, change the variant".

The migration is not free — existing `/img/gen/` URLs are stored in article metadata across 1,171 rows — but it is mechanical, and Images can serve from a remote source, so the transition does not have to be a big-bang re-upload.

**Verdict: install.** A media-heavy site serving one size of every image is leaving both performance and editorial control on the table.

## Stream

Stream is serverless video: upload or push live, get adaptive bitrate encoding, a player, and global delivery.

The build generates video. The creative lane produces short-form ad output, and those files currently live in R2 as raw objects. Serving an MP4 from R2 works, in the sense that a browser will play it. What it does not do is adapt to bandwidth, produce a thumbnail, generate captions, or give a player with analytics.

But the honest assessment is that this is not currently a bottleneck. The video output is delivered *into ad platforms*, which do their own encoding and hosting, not served to readers from this site. Stream would be solving a problem the build does not yet have.

The condition that would change it: the moment video appears on an article page or a wholesale catalogue page as something a reader watches, R2-as-video-host becomes the wrong answer immediately.

**Verdict: later.** Correct product, absent use case. Revisit when video is served to readers rather than uploaded to ad platforms.

## Realtime

Realtime covers live audio and video: RealtimeKit, an SFU for many-participant sessions, and TURN for connectivity.

This build has a voice lane. It records, transcribes, synthesises speech, and sends voice notes. Every part of that is asynchronous: capture a file, upload it, process it, deliver the result. Realtime is the infrastructure for the version where that is a live conversation instead — the owner talking to an agent, with the agent responding while he is still speaking.

That is a genuinely different product from what exists, and it is worth being clear that it is an ambition rather than a gap. The current voice lane is not broken. It is asynchronous by design and the design is fine.

**Verdict: no, for now.** Realtime is the answer to a question this build has not asked. Listing it as an opportunity because it is impressive would be exactly the brochure behaviour this series is meant to avoid.

## The one to do first

If only one thing in this part happens, it is Images, and the reason is not performance.

This build has an editorial law about heroes: the image shows the subject, not the research method. That law is enforced at the write path against the *brief*. What it cannot enforce is the presentation — whether the crop that ends up on the homepage card still shows the subject after being squeezed into a different aspect ratio. Named variants make the crop a declared property of the site rather than an accident of whatever dimensions the generator produced.

## Verdicts

| Product | What it replaces here | Verdict |
| --- | --- | --- |
| Images | One file, one size, one format for every hero on 1,171 articles | **install** |
| Stream | Ad video sitting in R2 as raw objects | **later** — when video is served to readers |
| Realtime | An asynchronous voice lane that works as designed | **no** — for now |

Next: [Part 6 — the edge in front of the Worker](/a/cloudflare-os-xl-06-the-edge-in-front).

