Flyimg is a Dockerized, self-hostable image processing service that resizes, crops and compresses images on the fly, serving them in optimized formats such as AVIF, WebP, MozJPEG, PNG and GIF, and it is aimed at developers and teams who want a Cloudinary-style image delivery pipeline running on their own infrastructure.

What it is

Flyimg is an open-source application written in PHP and licensed under AGPL-3.0. It runs as a single Docker container built around ImageMagick, with nginx and php-fpm started inside the container by s6-overlay and listening on port 80. The project is distributed as the Docker image flyimg/flyimg, and its own README describes it as "one Docker container to build your own Cloudinary-like service." Alongside the self-hosted option, the project also offers a fully managed Flyimg SaaS, so the same feature set is available either as software you operate or as a hosted service.

The concrete problem it solves is image transformation and delivery without a hand-rolled pipeline or a third-party dependency. Rather than pre-generating every size and format a site might need, or wiring up a separate resize worker and cache, a developer appends transformation options to a URL path, and Flyimg fetches the source image, converts it, stores the result, caches it and serves it. Subsequent requests for the same transformation are answered from cache. This replaces the stack of resize scripts, conversion jobs and cache layers that would otherwise have to be assembled and maintained around ImageMagick, and it exposes that work as a predictable HTTP interface.

Key capabilities

• URL-driven transformations using the /upload/ path prefix followed by option and value pairs, for example /upload/w_130,h_113,q_90/ before the source image URL, with options separated by commas such as w_250,q_50.
• Automatic format negotiation through o_auto, which selects a format based on the request's Accept header, generating AVIF by default when the browser supports it.
• Additional output formats including WebP, MozJPEG, PNG and GIF, giving coverage for both modern and legacy clients.
• JPEG XL (JXL) output via ImageMagick when enabled, which can be forced with o_jxl and tuned with encoder effort values from jxlef_1 to jxlef_9.
• An efficient caching system that stores converted images and serves the cached version on repeat requests.
• Configuration through config/parameters.yml, which can be mounted as a volume to override the defaults without rebuilding the image.
• Face detection is listed among the project's topics, alongside image processing, resizing and cropping capabilities.

Who uses it and how

• Teams that need a self-hosted image optimization endpoint and prefer to keep transformed assets on their own infrastructure rather than in a third-party service.
• Developers evaluating or prototyping transformations against the public demo at https://demo.flyimg.io/, which exposes the resize, crop and compression features without any setup.
• Local development and custom builds, where the repository is cloned, the image is built with docker build -t flyimg ., and composer install is run inside the container on first use.
• Operators on Mac, Windows or Ubuntu, which the README lists as the tested environments, with Docker Machine optionally used to create a virtual environment.
• Organizations that would rather not run containers at all and instead consume the managed Flyimg service described in the README as production-ready and fully managed.

Getting started

The quickest route is to pull and run the published image with docker pull flyimg/flyimg followed by docker run -itd -p 8080:80 flyimg/flyimg, after which http://127.0.0.1:8080/ should return a "Hello from Flyimg!" message. Custom settings are applied by copying config/parameters.yml locally and mounting it into the container at /var/www/html/config/parameters.yml.

How it compares

The README frames Flyimg explicitly as a way to build your own Cloudinary-like service, which places it in the same functional territory as Cloudinary while remaining software you run yourself. The differences the project supports are ones of control: Flyimg is AGPL-3.0 licensed and self-hosted by default, so the transformed images and cache live on the operator's own machine, whereas a managed product handles that infrastructure on the vendor's side. For teams that want the hosted model, the project's own managed SaaS is offered as an alternative to self-hosting the same application.

When to use it — and when not to

A self-hoster must be prepared to operate a Docker container running nginx, php-fpm and ImageMagick, to manage the parameters file, and to provide storage for the cache that the service writes to. Teams that cannot accept the obligations of an AGPL-3.0 licence, or that have no interest in running and upgrading containers, should consider the managed Flyimg service or a different approach entirely. It is also worth noting that the README excerpt covers installation, transformation syntax and configuration but does not detail cache storage backends or multi-node deployment, so anyone planning a large distributed setup should consult the full documentation at https://docs.flyimg.io before committing.

<!-- https://flyimg.io/demo-images/Citroen-DS.jpg -->
<img
  src="https://demo.flyimg.io/upload/w_300,q_90/https://flyimg.io/demo-images/Citroen-DS.jpg"
/>

docker pull flyimg/flyimg

docker run -itd -p 8080:80 flyimg/flyimg

docker run -itd -p 8080:80 -v $(pwd)/parameters.yml:/var/www/html/config/parameters.yml flyimg/flyimg

git clone https://github.com/flyimg/flyimg.git

docker build -t flyimg .

docker exec -it flyimg composer install

docker run -itd -p 8080:80 -v $(pwd):/var/www/html --name flyimg flyimg

docker run -itd -p 8080:80 -v $PWD:/var/www/html --name flyimg flyimg