A Cloudinary Alternative for Image Storage

Cloudinary's superpower is the transformation URL: /image/upload/w_400,c_fill,f_auto,q_auto/photo.jpg and it resizes, crops, and format-shifts on demand. That engine is worth paying for when your variant set is open-ended — user-driven dimensions, AI auto-cropping, background removal, on-the-fly WebP/AVIF. But as a Cloudinary alternative, plenty of teams don't need a transform engine at all — they need durable storage and a fast URL.

But it has a cost shape that surprises teams: Cloudinary meters 'transformations' and 'credits,' so a redesign that mints a thousand new derived URLs, or a hotlinked image generating fresh transforms, can chew through quota fast. files.link removes that whole axis. It is storage plus CDN, full stop — it serves the exact bytes you upload and never rewrites pixels from URL parameters.

Billing is prepaid credits against storage and delivery only, so rendering a thumbnail costs you nothing on our side because you rendered it before upload. The migration pattern is to materialize the handful of sizes you actually use instead of letting an engine generate an unbounded set. In a Node build or upload pipeline: import sharp from 'sharp'; for (const w of [400, 800, 1600]) { const buf = await sharp(input).resize(w).webp({quality:80}).toBuffer(); variants[w] = await uploadToFilesLink(buf, \photo-${w}.webp\); } where uploadToFilesLink runs the three-call REST upload (POST /v1/files/{folderId} → PUT presigned URL → POST /v1/files/confirm-upload with {ids:[...]}).

Then serve a normal srcset: <img srcset="${variants[400]} 400w, ${variants[800]} 800w, ${variants[1600]} 1600w" sizes="...">. You produce three deterministic files once rather than paying per transform forever. If you genuinely need on-demand transforms but want files.link as the durable, predictably-priced origin, front it with an image-resizing edge worker — Cloudflare Image Resizing, Lambda@Edge, or thumbor.

The worker reads the size/format params, fetches the original from the files.link CDN, transforms, and caches the result at the edge, so you add transforms only where you need them instead of metering every asset. Video splits the same way: Cloudinary transcodes and packages adaptive HLS; files.link stores and serves whatever renditions you upload, so transcode with ffmpeg first and serve the playlist and segments from the CDN.

Be honest about the line: if your variants are arbitrary and user-driven, or you want AI tagging and cropping, Cloudinary's engine earns its keep. If you optimize at build or upload time and just need fast, predictably-priced delivery, files.link is simpler and cheaper. For the full side-by-side, see files.link vs Cloudinary.