13 — Images, Calls, Tunnels, and Browser Rendering

"Other stuff on the platform" was how I filed the cluster of smaller Cloudflare products — Images, Calls, Tunnels, and Browser Rendering — which meant I never knew when each earned its keep. Writing them down separately fixed that. The unifying idea is that each takes a category of work that's painful to do well — image optimization, real-time media, secure origin exposure, headless browser execution — and runs it on Cloudflare's network as a managed service. [1][2][3][4]

The framing that landed is that none of these are general-purpose primitives the way Workers or KV are. They're each a focused solution to a focused problem, and the decision to reach for one is a decision that the problem it solves is one I actually have.

Images: optimization on demand

Cloudflare Images is a managed image pipeline [1]. The source image lives somewhere (uploaded to Images, or in an R2 bucket), and the platform handles the things that are painful to do well:

• Resizing to the dimensions each device actually needs.
• Format conversion — modern formats like WebP and AVIF for browsers that support them, with graceful fallback.
• Compression tuned so the image is small without visible quality loss.

The appeal is that I stop hand-managing derivative images. There's no "generate thumbnail, medium, large at upload time" step; instead, a Worker (or the CDN) requests the variant it needs and Images produces it on demand, caching the result. The source is stored once; the derivatives are produced and cached as needed.

When Images fits, it fits completely. For a site that serves user-generated images, product photos, or any media where "right size, right format, per device" matters, Images replaces a chunk of custom infrastructure.

Calls: real-time audio and video

Cloudflare Calls is the platform for real-time audio and video — video conferencing, voice chat, live interactive broadcasting [2]. It provides the infrastructure that handles the hard parts of real-time media:

• Low-latency routing of audio/video streams between participants, via Cloudflare's edge.
• A Selective Forwarding Unit (SFU) model — rather than every participant sending to every other (mesh, which doesn't scale), each participant sends once to the SFU, which forwards to the others. This is the architecture production conferencing systems use.
• APIs to build the participant experience — joining a session, publishing a track, subscribing to others' tracks.

The thing to internalize is that Calls is the _media routing_ layer, not a finished video-chat UI. I still build the client experience (the buttons, the participant tiles, the controls), but I don't build the network layer that gets one participant's video to the others with sub-second latency. For any application where real-time interaction is the feature — conferencing, collaborative tools, live audio rooms — Calls is the layer that makes it tractable.

Tunnels: expose an origin without opening it

Cloudflare Tunnel (sometimes cloudflared tunnel) flips the usual direction of network exposure [3]. Normally, to expose a service to the internet, I open an inbound port on my firewall and point a domain at it. Tunnel inverts this: a process on my origin (the cloudflared daemon) makes an _outbound_ connection to Cloudflare, and that connection is what Cloudflare uses to route public traffic back to me.

The security payoff is significant. With Tunnel:

• No inbound ports. My origin never accepts inbound connections from the internet. The firewall can stay locked down.
• The origin is never directly addressable. Attackers can't scan it or hit it; the only path in is through Cloudflare.
• Cloudflare's security stack sits in front of it. DDoS protection, WAF rules, access policies all apply before traffic reaches my origin.

The use cases are the ones where "I have a service I want reachable, but I don't want it exposed" — a home-lab service, a self-hosted app on a private network, a staging server behind a corporate firewall. Tunnel makes the origin reachable without making it vulnerable, and the outbound-only model means it works through NATs and firewalls that would block inbound connections.

Browser Rendering: headless Chromium at the edge

Browser Rendering is a managed headless-Chromium service [4] — "headless" meaning a real browser running without a visible window, driven from code. A Worker can drive that browser — navigate to a URL, wait for JavaScript to execute, then extract the result. The three workloads this unlocks:

• PDF generation. Render an HTML template in a real browser, capture the result as a PDF. Better fidelity than HTML-to-PDF libraries that don't run JS or don't have a full layout engine.
• Screenshots. Capture what a page actually looks like after it's rendered, including JS-driven content.
• Pre-rendering for SEO. Take a client-rendered SPA, execute the JavaScript in a real browser, capture the resulting HTML, and serve _that_ to crawlers that don't run JS. This is the "server-side rendering as a service" pattern without changing the app's architecture.

The reason this is a product rather than a DIY task is that running a headless browser at scale is operationally painful — memory-hungry, slow to start, awkward to pool. Browser Rendering runs the pool on Cloudflare's network and exposes it through a Worker binding, so the Worker gets a browser session without owning the infrastructure.

How these relate to the rest of the platform

A pattern across all four: each one is accessed through the same Workers-and-bindings model as everything else. A Worker sits in front of Images to handle auth and caching; a Worker coordinates Calls sessions; a Worker terminates the public end of a Tunnel and applies logic; a Worker drives Browser Rendering. The specialized services are layers behind Workers, not separate stacks — which is why composing them (a Worker that takes a screenshot via Browser Rendering, optimizes it via Images, stores it in R2) is just code, not an integration project.

How I use this

The decision rule per product:

• Images — for any site serving images where size/format/per-device matters. Replaces hand-rolled derivative generation.
• Calls — only when real-time audio/video is an actual feature. Don't reach for it for one-way video delivery (that's Stream).
• Tunnels — when I need to expose a private service without opening inbound ports. A security and networking tool, not a compute product.
• Browser Rendering — for PDFs, screenshots, and SEO pre-rendering where a real browser is the only thing that produces correct output.

Each earns its complexity only when the specific problem it solves is a problem I have. The temptation to use them speculatively is the thing I watch for — most applications need at most one of these, and several need none.

References

[1] Cloudflare, "Images — Cloudflare Docs," Cloudflare Docs, 2024. [Online]. Available: https://developers.cloudflare.com/images/

[2] Cloudflare, "Cloudflare Calls," Cloudflare Docs, 2024. [Online]. Available: https://developers.cloudflare.com/calls/

[3] Cloudflare, "Cloudflare Tunnel — Cloudflare Zero Trust," Cloudflare Docs, 2024. [Online]. Available: https://developers.cloudflare.com/cloudflare-one/connections/connect-networks/

[4] Cloudflare, "Browser Rendering," Cloudflare Docs, 2024. [Online]. Available: https://developers.cloudflare.com/browser-rendering/