The practical answer is to separate the original from the derivative: put each tenant's source image in private object storage, resize it in a worker or image service, and store the result under a deterministic key. S3, Cloudflare R2, Azure Blob Storage, and an S3-compatible API can all be the durable half of this design; none should be treated as an image-resizing engine by default.

For a logistics platform, I would make that boundary explicit. A driver's avatar is a small object, but a tenant backup may contain millions of objects and a restore must select one known snapshot. The same access-control rule applies to both: private writes, signed reads, tenant-scoped names, and a database record that says which derivative or snapshot is current.

What does object storage actually do for avatar resizing?

It stores bytes and metadata reliably.…