imagor

indeed! most image processing golang services suggest/use jemalloc the top 3 from https://github.com/topics/resize-images (as of 2025-06-13) imaginary: https://github.com/h2non/imaginary/blob/1d4e251cfcd58ea66f83... imgproxy: https://web.archive.org/web/20210412004544/https://docs.imgp... (linked from a discussion in the imaginary repo) imagor: https://github.com/cshum/imagor/blob/f6673fa6656ee8ef17728f2...

I have used https://github.com/cshum/imagor infront of S3 before and liked it, there is many (some commercial) offerings for this

Imagor is a fast, Docker-ready image processing server written in Go, with libvips. The v1 milestone has got more advancements to its internals. At the moment, all existing popular Go + libvips image applications (imgproxy, imaginary, bimg etc.) bridge libvips through buffer. While these are all good with normal web images, the latency and memory overhead can be noticeable when working through large, raw images, as they are all loading the whole image buffer in memory, sequentially. Imagor v1 now bridges libvips through streams (i.e. Go io.Reader/Seeker/Closer). This greatly increases network throughput especially with network sources like HTTPs, S3, GCS, by giving the ability to overlap processing pipelines. With streaming in place, same goes for image Exif metadata. Imagor can try to retrieve data just enough to extract the header, with