Cloudinary
Last updated: Nov 3, 2026
Rationale
Fluid Attacks uses Cloudinary to host, transform, and deliver the images and videos of its websites and applications. Fluid Attacks uploads each logo, illustration, and screenshot of its sites to Cloudinary one time, and Cloudinary serves it from its CDN. Thus, the sites do not ship media.
These are the primary reasons why Fluid Attacks selected it and not other alternatives:
- It is SaaS oriented. You upload a file and you get a URL with a global cache. You do not manage buckets, distributions, or image pipelines.
- It applies transformations on the fly through the URL, for example, resizing, cropping, and automatic format selection. Thus, one upload serves all the sizes and formats that a page must have.
- It gives SDKs for React, with lazy loading and placeholder plugins. The design system of Fluid Attacks puts these SDKs in a reusable image component.
- It supports authenticated delivery. With it, an asset is available only through a signed URL. Thus, Fluid Attacks can keep the media of internal pages private, and public pages continue to be cacheable.
- It supports public identifiers in folders. Thus, you identify assets with a stable name and not with a storage location.
Alternatives
At this time, Fluid Attacks does not examine alternatives. Cloudinary hosts only the public media of the sites of Fluid Attacks, and the files that the platform keeps for customers are in S3.
Usage
Fluid Attacks uses Cloudinary for these tasks:
- To serve each image in this documentation site, and also the assets of internal pages. Cloudinary keeps these assets as authenticated media, and the site serves them through a signed URL after it examines the access of the reader.
- To serve the illustrations, logos, and previews of the components of the design system of Fluid Attacks, through an image component that delivers WebP by default, and of the desktop applications that use this design system.
- To serve the logos and images of the front end of the platform, its login page, and its integrations with issue trackers and repositories.
- To serve the favicon and images of the public websites of Fluid Attacks.
Fluid Attacks does not use Cloudinary for these tasks:
- To keep the files, evidence, and reports of its customers. Fluid Attacks keeps them in S3.
- To serve the static code of its sites. Fluid Attacks does this with CloudFront and Cloudflare (read Public hosting).