Sergei Aleksandrovich

There is one big problem with deploying to Lambda. imgproxy uses many shared libs that can't be statically linked like GLib. Amazon Linux comes with built-in GLib that may be...

It is not a problem to include the required libraries right to the function archive. The problem is that Lambda sets the [environment variables](https://docs.aws.amazon.com/en_us/lambda/latest/dg/current-supported-versions.html#lambda-environment-variables) to use built-in libs at the...

I did build imgproxy on this image and ran it successfully on the local Lambda (https://docs.aws.amazon.com/en_us/serverless-application-model/latest/developerguide/sam-cli-command-reference-sam-local-invoke.html). But this still looks like very unstable solution. If Amazon would ever upgrade GLib...

I still think that Fargate is a way more suitable serverless solution for imgproxy than Lambda.

Lambda has some downsides that make it not the best solution for imgproxy: 1. Cold start requires downloading and starting a Docker image which creates unneeded delays. 2. imgproxy has...

> A container download never comes into the picture, where did you see that? Well, if you need to run a Docker container, you need to have its image. if...

Hey Rudin! Encoding of AVIF is extremely slow. There's nothing we can do with it as we already use the fastest AVIF encoder. So if you're going to use AVIF,...

You can try to increase `IMGPROXY_AVIF_SPEED` or use a better CPU, yet saving big images to AVIF may be a problem.

The latest Docker images use libaom instead of rav1e since libaom improved its encoding speed quite a lot. The AVIF encoding should be much faster now, especially with `IMGPROXY_AVIF_SPEED=8`.

Hey @PixelsCommander! I test imgproxy by sequentially requesting 1000+ images, so there shouldn't be any leaks or buffer overflows. I may suggest the following things happening here: imgproxy instance has...