1. Home
  2. Docs
  3. Engineering
  4. Image Processing Service: Cloudimage

Image Processing Service: Cloudimage

Current Option: Cloudimage

We have a lifetime Cloudimage CDN + image transformation deal with 40 GB of cache and 100 GB of traffic. If our traffic grows, please stack more AppSumo codes.

We use Cloudimage for image transformation, optimization, responsive images, and CDN for images. For web-based serving, both public and private images use reponsive JS provided by Cloudimage, with private images previously signed using AWS S3 API.

CNAME records

For verification:

 – `` CNAME `“
 – `` CNAME ``
 – `` CNAME ``
 – `` CNAME ``
 – `` CNAME ``


Using Cloudimage Transformations

We use Cloudimage not only as a CDN, but also for transformations.

sc_thumb (legacy)
Original photo (Strapi)
Automatic gravity
Face only (may enlarge the image)


Self-hosted Options

  1. Thumbor
    • although no built-in support for S3-compatible protocol as retrieval & result storage, only filesystem. There is third-party plugin including AWS for images, DigitalOcean Spaces for result, and MongoDB for metadata:
    • combination between DigitalOcean Spaces + MongoDB metadata may allow to skip Thumbor entirely when result is already generated
  2. imaginary. Performance-wise it seems to be much faster than Thumbor, due to both use of go and libvips.
    • by adding CloudFront, perhaps the “store result” is no longer necessary, because then we won’t need to pay storage of results. This seems to be better in the long-run anyway, because CDN has algorithm to evict old cache entries. If a result image is never requested, it doesn’t make sense to store it anyway (and pay for its storage).
    • since we rely on CDN and not result storage, the client app is simpler because there is no logic to check result image exists.
    • when we surpass $20 in CloudFront costs, we can move to CloudFlare Pro ($20) or even Business ($200) instead. Judge.
    • due to this, it’ll be much more efficient to host this on AWS Lightsail (Singapore) with pure Docker/Compose (not MicroK8s). Also, no need to worry about LetsEncrypt TLS as origin is HTTP and CloudFront handles the HTTPS.
  3. Strapi’s File Upload
    • strapi-provider-upload-aws-s3
    • GraphQL support
    • supports authentication
    • can be deployed serverless
    • with conventional File Upload, the image is sent to Strapi first before sending to S3. An optimized workflow may modify this a bit by:
      1. AWS S3 has lifecycle set up to automatically delete files in temporary S3 path after x time. or we do a daily housekeeping job.
      2. client given a temporary token to upload directly to a temporary S3 path and has
      3. client uploads the entry/document/metadata including the temporary S3 path
      4. server then downloads the temporary S3 path
      5. after processing is done, server may: move the temporary file, OR delete the temporary file
  4. Imbo (MIT license, PHP). Unfortunately, last commit was 2016. 🙁 is an image “server” that can be used to add/get/delete images using a RESTful HTTP API. There is also support for adding meta data to the images stored in Imbo. The main idea behind Imbo is to have a place to store high quality original images and to use the API to fetch variations of the images. Imbo will resize, rotate and crop (amongst other transformations) images on the fly so you won’t have to store all the different variations.
  5. ImageResizer (ASP.NET)

Open Source Digital Asset Management: (may or may not support S3)

  1. Pimcore
  2. Phraseanet. GPLv3.
  3. Razuna



  1. Image Processing Microservice: Imaginary first, fronted by CloudFront. Use Cloudimage.
  2. Image Repository Microservice: Later on, deploy image repository powered by Strapi. Which will work together with image processing for delivery.


How can we help?