Author here. Apologize for the late response, as I only realized it was on HN a few days after. Thanks for posting it!
A bit of our background: we have been a long time user of Thumbor, with millions of images serving under it and applications built around the Thumbor syntax. However Thumbor is not quite in active development anymore. Support is getting stale, and its stable version is still using Python 2.
So we started to look to alternatives. We wanted to keep the Thumbor syntax as it is a pretty good one, and we want no disruption to our existing image urls being created, and applications that built around it. So we wanted a drop-in replacement. We studied closely with Imaginary and Imgproxy which both are made with Go and libvips. Imgproxy is a pretty solid one, but we are not happy it is charging for premium, even for common features like Chained pipelines (a.k.a filters). Imaginary is very popular, but the feature parity gap is pretty large between Imaginary and Thumbor, with ongoing memory issues and the author seems not interested in maintaining it recently. And most importantly, neither of both sides are interested in adopting Thumbor's URL syntax. And building a proxy around them would be a half baked solution, as their high level APIs are unlikely meet the Thumbor's feature parity. And so we decided to do the hard work and here it is.
We have already implemented all features we need and it is working great for us in production. The S3 Loader/Storage is battle tested, but the file store is not though. We do acknowledge it has a long way to go to meet the Thumbor's feature parity. But this is just our first step and of course we wanna keep pushing it.
I don't see any documentation around libvps that claims it's safe to run on untrusted inputs, so you might want to run this thing in gVisor or a dedicated VM if that's your plan.
(I also looked for fuzz tests up the chain; libvips -> govips -> imagor, and didn't find any.)
quite. inside docker, on a VPS with only other instances of that container running, uploading to an S3 bucket using IAM write-only privs, and the instance gets automatically cycled every hour.
Great to see more players in this space, especially re-using the thumbor syntax. Curious how much of a feature-parity is there between Imagor and thumbor though? (particularly with some of the plugins)
Context/disclaimer: I've been maintaining the docker image for thumbor[0] (not maintaining thumbor itself, although I work with the thumbor team occasionally). Thumbor works great for us at my company, but it's still python 2.x based. There's some work to transition to python 3.x, but it seems[1] like there are not enough resources or drive to push this forward? and thumbor 7 does not (yet) have feature parity with thumbor 6.
I'm yet to find something that has feature-parity with thumbor though... But it definitely feels like high time for a some new blood in this space. Especially compared against some of the cloud options out there, like Cloudflare Images, especially since they seem to be also lacking some crucial features[2].
It would be great to see a cache layer in front of S3, in my experience fetching the original image from S3 will be slower than the actual resizing (regardless of the library used) and that happens at least once.
So ideally something like:
1. upload to s3
2. manipulate image to a friendly size (ie. 2048x2048)
3. write the image to an LRU cache (ie. memcached)
Typically Cloudfront would sit in front of this service and either serve the requested resource from cache or forward the request to the origin (Imagor) if missing from cache.
What would you all use if you had to deploy something like this today? I see here at least thumbor and imaginary mentioned as alternatives, which would you choose and why?
imgproxy looks amazing, but some features (e.g. pipeline) are locked behind Pro as far as I can tell? (and I guess Pro isn't open-source, or not free).
disclaimer: I maintain the docker images for thumbor[0]
It looks Imagor can save/cache the resulting files in S3. If so that’s a great benefit since Imaginary does not support it and you have to use a CDN.
Do I understand it correctly that Imagor can transform the image from URL and store the results to S3 and next time the same image is requested it is not transformed again but returned from S3?
"ready to be containerized using Docker" is one of the stupidest software brags I've seen all year. Virtually any Linux software at all is "ready to be run in a container". It's a giant red flag saying "I don't really get containers but this phrase should get a ton of GitHub stars and maybe I can turn that into getting hired by a FAANG"
A bit of our background: we have been a long time user of Thumbor, with millions of images serving under it and applications built around the Thumbor syntax. However Thumbor is not quite in active development anymore. Support is getting stale, and its stable version is still using Python 2.
So we started to look to alternatives. We wanted to keep the Thumbor syntax as it is a pretty good one, and we want no disruption to our existing image urls being created, and applications that built around it. So we wanted a drop-in replacement. We studied closely with Imaginary and Imgproxy which both are made with Go and libvips. Imgproxy is a pretty solid one, but we are not happy it is charging for premium, even for common features like Chained pipelines (a.k.a filters). Imaginary is very popular, but the feature parity gap is pretty large between Imaginary and Thumbor, with ongoing memory issues and the author seems not interested in maintaining it recently. And most importantly, neither of both sides are interested in adopting Thumbor's URL syntax. And building a proxy around them would be a half baked solution, as their high level APIs are unlikely meet the Thumbor's feature parity. And so we decided to do the hard work and here it is.
We have already implemented all features we need and it is working great for us in production. The S3 Loader/Storage is battle tested, but the file store is not though. We do acknowledge it has a long way to go to meet the Thumbor's feature parity. But this is just our first step and of course we wanna keep pushing it.