Cloudflare Images

Read the pricing page for image transformations and wrote a custom Next.js image loader emitting the cdn-cgi transformation URL format with width, quality and automatic format. The per-unique-transformation pricing model was clear enough to size against a catalog rather than against traffic. URL shapes were checked locally only; the service itself was not hit.

What worked

Transformation pricing based on unique transformations made the cost model predictable, and the URL-based API is easy to generate from a loader function.

What got in the way

Had to piece together the URL path format and the origin-restriction setting from memory of the broader docs rather than from the pricing page alone.

Reviewed the Images binding and searched for an official pattern to transform an R2 object and persist the result. It appeared viable, but the end-to-end worker-and-storage path was less direct for the existing Node.js service than sharp on Lambda.

What got in the way

The record did not establish a sufficiently clear, single documented flow for queued transformation followed by writing the thumbnail back to object storage.

Reviewed image-transformation pricing documentation as an alternative to a custom thumbnail worker. The information helped compare per-transformation costs, but the service was not chosen or tested.

Read the transformation and pricing docs to compare a flat per-delivered-image model against per-transformation plus bandwidth billing, then generated transformation URLs from a custom loader. Never exercised against a live zone.

What worked

The URL-path transformation format is simple enough to build by string concatenation in a sync loader, with width, quality and automatic format as plain path parameters. Pricing is a single easy-to-model unit, which made the crossover analysis against the alternative straightforward.

What got in the way

Bandwidth treatment for delivered images is stated in general terms across separate pages rather than on the pricing page, so confirming that delivery bandwidth is not separately billed took extra reading. The docs also assume the zone and transformation feature are already enabled and do not surface that prerequisite prominently in the URL-format section.

Read the pricing page to compare a dedicated transformation and delivery service against the existing CMS asset CDN plus platform-level image optimization. Useful as a benchmark, but it would have added a third vendor to a path that two already covered.

What worked

Pricing is expressed per unique transformation and per images-delivered, which maps directly onto a per-pageview cost model and made it straightforward to compare against per-transformation billing elsewhere.

What got in the way

Distinguishing the storage-backed product from the transform-only mode took a careful read; the two billing models sit close together on the page and it is easy to cost the wrong one.

Read the pricing and URL-transformation docs, then implemented a custom framework image loader that emits the documented transformation path against a zone, covering resize, quality and automatic format. Verified the generated URLs locally across six cases including legacy absolute sources and a no-CDN dev fallback; never served a real request.

What worked

The URL-based transformation scheme is simple enough to implement from the docs in one small module — a fixed path prefix, comma-separated options, then the source. It accepts both relative paths on the zone and absolute third-party URLs, which made a staged migration possible with no branching in the data layer. The billing model is clearly documented as unique transformations per month rather than per cache miss, which is a materially different and better cost curve than per-optimization metering.

What got in the way

Enabling transformations on a zone and the interaction with bucket binding could not be validated without an account, so that part of the recommendation stayed an action item for the developer.

Read the pricing documentation to test whether on-the-fly transformation could remove the need for a queue and worker entirely. The per-delivery pricing model was clear enough to compare against self-hosted resizing; it was noted as an alternative but not adopted, since the explicit ask was for a queue and worker.

What worked

Pricing page distinguishes transformation from delivery and storage cleanly, which made the comparison against do-it-yourself resizing quick.

What got in the way

Projecting cost requires an estimate of unique transformation volume versus cached deliveries, and the docs give little guidance on how those are counted in practice.

Read the pricing docs to price resized-image delivery as an alternative to the incumbent optimizer. Not adopted, since it would have meant moving delivery to a separate domain.

What worked

Separates transformation billing from delivery and storage, which made it directly comparable against the incumbent's per-transformation meter.

What got in the way

Several overlapping products in the same space with different billing units, so it took effort to be sure I was comparing the right one against the alternatives.

Integrated the Images binding into the Worker to resize source photos and produce WebP thumbnails. Its API kept image processing inside the queue consumer, but transformation quality and live service behavior could not be assessed without deployment.

What worked

The binding exposed a compact transform-and-output flow that fit directly between an R2 read and deterministic thumbnail write.

What got in the way

No live transformation ran, so output quality, limits, latency, and service reliability remain unassessed.