Flyimg

Flyimg is a self‑hosted, Docker‑centric image processing service that emulates key features of commercial cloud providers such as Cloudinary. From a developer’s standpoint, it exposes a simple HTTP API that accepts a source image URL and a set of transformation parameters (size, quality, format). The service then fetches the source image, applies transformations via ImageMagick and libvips, caches the result on disk or in-memory, and serves it to the client. Because all transformations are performed on‑the‑fly, Flyimg eliminates the need for pre‑processing pipelines and allows developers to deliver optimized assets with minimal latency.

Key Features

• Dynamic format negotiation – o_auto selects AVIF, WebP, or JPEG based on the request’s Accept header.
• Advanced compression – integrates MozJPEG, JPEG XL (via ImageMagick), and AVIF for superior size/quality trade‑offs.
• Transformation syntax – concise w_300,q_90 style keys are parsed into ImageMagick commands.
• Cache‑first serving – once a transformed image is generated, it is stored under a deterministic hash and served from cache on subsequent requests.
• Extensible parameters – the parameters.yml file exposes knobs for caching TTL, storage backend, and default quality.

Technical Stack

The core PHP application orchestrates HTTP requests, parses the transformation string, invokes ImageMagick commands, and manages cache metadata. The heavy lifting of image conversion is delegated to libvips for speed and low memory footprint, with ImageMagick used only for formats that require its advanced filters.

Core Capabilities & API

• Endpoint: GET /upload/{transformations}/{source_url}
  Example: /upload/w_300,q_90/https://flyimg.io/demo-images/Citroen-DS.jpg
  The first segment is a comma‑separated list of transformation keys; the remainder is an absolute URL.
• Supported transformations: w, h, c (crop), q (quality), o_auto, o_jxl, jxlef_1..9.
• Response headers: Content‑Type is set to the negotiated format; caching headers (Cache-Control, ETag) are automatically populated.
• Webhooks: Optional POST hooks can be configured to trigger after image generation, useful for analytics or downstream processing.
• Plugin system: The Symfony bundle architecture allows developers to write custom transformation plugins and register them in services.yaml.

Deployment & Infrastructure

• Self‑hosting: A single Docker container runs the entire stack; no external dependencies are required beyond Docker.
• Scalability: Horizontal scaling is straightforward—run multiple Flyimg instances behind a load balancer. The cache can be shared via Redis to avoid duplicate processing.
• Resource constraints: libvips is memory‑efficient; typical workloads require 1–2 GB RAM per instance for moderate traffic.
• CI/CD: The repository includes GitHub Actions that build and test the image; developers can integrate Flyimg into their pipelines by pulling from Docker Hub or building locally.

Integration & Extensibility

• Custom parameter file: parameters.yml can be overridden at runtime, allowing fine‑tuned cache policies or storage backends without code changes.
• SDKs: While not bundled, the API’s simplicity means developers can wrap it in lightweight SDKs for Node.js, Python, or Go.
• Extensible format support: By adding ImageMagick delegates, new formats (e.g., AVIF) can be enabled without changing the core code.
• Security: The service validates source URLs against a whitelist and imposes size limits to mitigate SSRF and DoS attacks.

Developer Experience

• Documentation: The official site hosts concise guides, parameter reference tables, and example URLs.
• Community: Active GitHub issues and an Open Collective backer list indicate ongoing support.
• Testing: The CI pipeline includes code coverage checks, ensuring reliability for contributors.
• Licensing: MIT license grants unrestricted use and modification, making it attractive for commercial projects.

Use Cases

1. Web applications needing on‑the‑fly image optimization without a CDN; Flyimg can be deployed in the same environment as the app.
2. CMS platforms (e.g., WordPress, Drupal) can forward image URLs to Flyimg via a custom plugin for consistent output.
3. Static site generators that pull remote images can use Flyimg to pre‑process assets during build time.
4. Mobile backends that serve user uploads can offload resizing/compression to Flyimg, reducing bandwidth usage