Cloudinary
Last updated: Sep 23, 2026
Rationale
Cloudinary is the service we use for hosting, transforming and delivering the images and videos of our websites and applications. Every logo, illustration and screenshot our sites show is uploaded once to Cloudinary and served from its CDN, so the sites themselves ship no media.
The main reasons why we chose it over other alternatives are:
- It is SaaS oriented. Uploading a file is all it takes to get a globally cached URL, without managing buckets, distributions or image pipelines.
- It applies transformations on the fly through the URL, such as resizing, cropping and automatic format selection, so a single upload serves every size and format a page needs.
- It provides SDKs for React, including lazy loading and placeholder plugins, which our design system wraps in a reusable image component.
- It supports authenticated delivery, where an asset is served only through a signed URL, letting us keep the media of internal pages private while public pages stay cacheable.
- It supports public identifiers organized in folders, so assets are referenced by a stable name rather than by a storage location.
Alternatives
No alternatives are currently being considered, as Cloudinary only hosts the public media of our sites, and the files our platform stores for customers live in S3.
Usage
We use Cloudinary for:
- Serving every image in this documentation site, including the assets of internal pages, which are stored as authenticated media and proxied through a signed URL after the reader's access has been checked.
- Serving the illustrations, logos and previews of our design system's components, through an image component that delivers WebP by default, and of the desktop applications built with it.
- Serving the logos and images of the platform's front end, its login page and its integrations with issue trackers and repositories.
- Serving the favicon and images of our public websites.
We do not use Cloudinary for:
- Storing the files, evidence and reports of our customers, which we keep in S3.
- Serving the static code of our sites, which we do with CloudFront and Cloudflare (see Public hosting).