Flyimg

URL-based image optimization, honestly reviewed. No marketing fluff, just what you get when you run it yourself.

TL;DR

• What it is: A Dockerized image processing microservice — you pass an image URL with parameters appended, and Flyimg fetches it, converts it, caches it, and serves it. One container to build your own Cloudinary-like pipeline [1].
• Who it’s for: Developers and technical founders paying Cloudinary or imgix bills for basic resize/compress/convert operations who want that cost to disappear.
• Cost savings: Cloudinary paid plans start at $89/mo. Self-hosted Flyimg runs on a $5–10/mo VPS with unlimited transformations [1][2].
• Key strength: Automatically serves AVIF (the most efficient widely-supported format) when the browser accepts it, falling back to WebP and MozJPEG — next-gen format delivery out of the box, zero configuration [1].
• Key weakness: 1,200 GitHub stars is modest for infrastructure software. Small community, AGPL-3.0 license with network-use implications, PHP+ImageMagick stack that trails Go-based alternatives in raw throughput, and no admin dashboard [1].

---

What is Flyimg

Flyimg is a self-hosted image transformation server with a URL-based API. You take a source image URL, prepend your Flyimg instance address and a set of transformation parameters, and Flyimg does the rest — fetching the image, processing it, caching the result, and serving it [1].

The URL pattern is the entire interface:

https://your-flyimg.example.com/upload/w_300,q_90/https://source.example.com/photo.jpg

That URL resizes to 300px wide at 90% quality, serves AVIF if the browser supports it (WebP otherwise), and caches the processed result. The next time the same URL is hit, it serves the cached copy without reprocessing [1].

The README states the pitch plainly: “One Docker container to build your own Cloudinary-like service.” That’s the entire scope — not a DAM, not a creative suite, just fetch-transform-cache-serve [1]. The project is built in PHP on top of ImageMagick, licensed AGPL-3.0, and sits at 1,200 GitHub stars. The team also runs a managed SaaS version at flyimg.io for users who want the outcome without the ops work [2].

---

Why people choose it

The case for Flyimg is almost entirely about cost and control. Image CDN SaaS pricing is opaque, scales with usage, and compounds as traffic grows. Cloudinary, imgix, and Bunny Optimizer all penalize growth.

Versus Cloudinary. Cloudinary’s free tier gives 25 credits per month — where a credit covers roughly 1,000 transformations, 1GB of storage, or 1GB of bandwidth, whichever you exhaust first. Once a site has real traffic, that ceiling hits fast. The Plus plan is $89/mo, Advanced is $224/mo. A media-heavy product with six-figure monthly page views can burn several hundred dollars monthly on image delivery alone [2].

Self-hosted Flyimg undercuts that math entirely. The software is $0. A Hetzner or Contabo VPS starts at $5–6/mo. Transformations are unlimited [1][2].

Versus imgix. imgix has a cleaner developer experience than Cloudinary and a URL-based API that Flyimg closely resembles. imgix charges per master image stored and per gigabyte of bandwidth rendered — a model that punishes large catalogs with real traffic. Flyimg eliminates per-transformation and per-bandwidth pricing entirely [2].

The privacy and data sovereignty angle. Every image URL served through Cloudinary or imgix is logged by third-party infrastructure. For internal tools, confidential product photography, or regulated industries, self-hosting means the image pipeline never leaves your network [1].

What you give up: Cloudinary’s global 500-PoP edge CDN, DAM features, AI tagging, video processing, and years of battle-tested reliability at scale. Flyimg is the stripped version — transformation plus caching, no extras.

---

Features

From the GitHub README and documentation [1][3]:

Format support:

• AVIF — default output when the browser’s Accept header declares support; best compression of any widely-supported format [1]
• WebP — fallback when AVIF isn’t supported [1]
• MozJPEG — Mozilla’s JPEG encoder; roughly 10–20% better compression than libjpeg at equivalent quality [1]
• PNG — lossless output [1]
• GIF — animated image support [1]
• JPEG XL (JXL) — experimental via ImageMagick; force output with o_jxl, tune encoder effort with jxlef_1..9 [1]
• Auto-negotiation — o_auto selects the best supported format based on the request Accept header [1]

Transformation parameters:

• w_ — output width
• h_ — output height
• q_ — quality (0–100)
• Crop, resize, and compression modes via ImageMagick’s parameter set — full list in the documentation [3]

Caching:

• First request fetches and processes; subsequent requests serve from cache [1]
• Cache is filesystem-based, local to the container [1]

Deployment options:

• Docker Hub image: flyimg/flyimg — single docker run command to start [1]
• Custom config via parameters.yml volume mount (source domains, quality defaults, cache TTLs) [1]
• Dev mode: clone → docker build → composer install inside container [1]

What it doesn’t do:

• No DAM — no asset browser, no tagging, no search interface
• No video processing
• No AI features — no auto-tagging, no content-aware cropping
• No built-in CDN — Cloudflare or another layer required for edge caching
• No admin UI for managing or inspecting the cache

---

Pricing: SaaS vs self-hosted math

Flyimg managed SaaS (flyimg.io): Pricing is not publicly listed on the flyimg.io website — the homepage pitches “Production-ready, fully managed Flyimg SaaS” but routes to a contact flow rather than a pricing page [2]. Budget as you would for any image CDN SaaS and expect to negotiate.

Self-hosted (community edition):

• Software license: $0 (AGPL-3.0) [1]
• VPS: $5–20/mo on Hetzner, Contabo, or DigitalOcean
• Bandwidth: included in most entry VPS plans (typically 1–5TB/mo)

Cloudinary for comparison:

• Free: 25 credits/mo (transformations + storage + bandwidth combined)
• Plus: $89/mo for 225 credits
• Advanced: $224/mo for 600 credits

imgix for comparison:

• Free: 1,000 master images, 20GB bandwidth
• Growth: ~$25/mo for 5,000 images and 100GB bandwidth
• Scales linearly with catalog size and delivery volume

Concrete example:

A product site with 5,000 images, each served in three sizes (thumbnail, medium, large) = 15,000 unique transformations. At 50,000 monthly visits generating 150,000 transformation requests, you’ve blown through Cloudinary’s free tier and you’re at $89/mo minimum. Self-hosted Flyimg on a $6/mo Hetzner VPS with Cloudflare’s free CDN tier in front handles the same workload at $6/mo.

Over 12 months: Cloudinary Plus ≈ $1,068. Flyimg self-hosted ≈ $72 plus your setup time. The math is obvious. The variable is whether you can run a Docker container.

---

Deployment reality check

Two commands get you a running instance [1]:

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

For a production setup, you’ll also need:

• A reverse proxy (nginx or Caddy) handling HTTPS and your domain
• Persistent storage — bind-mount the cache directory so it survives container restarts
• A stable custom domain — Flyimg URLs are embedded in your HTML markup, so the domain must not change
• Cloudflare or another CDN in front — Flyimg’s cache is local to the server; edge caching requires a CDN layer

For custom configuration, copy parameters.yml and mount it as a volume. This is where you set allowed source domains, default quality, cache TTLs, and format overrides [1].

Development setup requires one additional step: after building the image, run composer install inside the container to pull PHP dependencies. The README flags this explicitly as a first-time-only requirement [1].

What can go sideways:

• AGPL-3.0 license. Internal self-hosting for your own products: fine. Building a SaaS product where end users interact with your Flyimg instance over the network: you must release any source modifications under AGPL. This is meaningfully more restrictive than MIT and worth reading carefully before building a commercial product on top of it [1].
• PHP + ImageMagick stack. ImageMagick’s format support is excellent, but throughput per CPU core trails Go-based alternatives. imgproxy and Imaginary (both libvips or Go-native) handle high-volume pipelines significantly faster. For low-to-medium traffic, this won’t matter. For high-volume image APIs, benchmark first.
• No health endpoint documented. Production monitoring requires you to set up your own uptime check against the demo endpoint. There’s no built-in /health route described in the README [1].
• Small community. 1,200 stars means GitHub issues may go unanswered for extended periods. Don’t expect Stack Overflow threads with vetted answers to edge cases.
• No cache management interface. To inspect or clear cached images, you’re working directly with the filesystem or restarting the container.

Realistic time estimate: 15–30 minutes to a working instance for a developer with Docker experience. 2–4 hours for a production setup with HTTPS, custom domain, and CDN. Non-technical founders will need a developer’s help either way.

---

Pros and cons

Pros

• Dead-simple URL API. Append parameters to a URL — no SDK to install, no API key management, no library dependency. Works anywhere you write HTML or render URLs [1].
• AVIF-first by default. Ships next-gen format delivery with zero configuration — the server negotiates automatically based on the browser’s Accept header [1]. Most Cloudinary setups require explicit format selection or additional setup for AVIF.
• Zero per-transformation cost. Unlike Cloudinary, imgix, or Bunny Optimizer, Flyimg doesn’t charge per image rendered. Process a million images per day — cost is VPS compute and bandwidth only [1][2].
• Minimal deployment footprint. One Docker container, no managed database, no worker queue, no Kubernetes required [1].
• Format breadth. AVIF, WebP, MozJPEG, PNG, GIF, and experimental JPEG XL — covers everything a web project is likely to need [1].
• Caching built in. Processed images are stored locally so the same transformation isn’t recomputed on repeat requests [1].

Cons

• Small community (1,200 stars). Compare to imgproxy (~9,000 stars) or Thumbor (~10,000 stars), which have larger communities, more third-party tutorials, and more documented production deployments [GitHub].
• AGPL-3.0 license. Restricts commercial SaaS use cases more than MIT or Apache. Requires releasing modifications if your product exposes Flyimg as a networked service to others [1].
• PHP + ImageMagick throughput ceiling. Not the right tool for high-volume image pipelines where processing speed per core matters. Go-based alternatives like imgproxy or Imaginary outperform it significantly at volume.
• No admin UI. No cache dashboard, no visibility into storage usage, no interface to inspect or flush cached assets. Management is command-line and filesystem.
• Managed SaaS pricing not disclosed. flyimg.io doesn’t publish a pricing page, making it difficult to compare against Cloudinary on equal terms if you want the managed option [2].
• No built-in CDN. Cloudinary includes global edge caching in its pricing. Flyimg requires you to layer Cloudflare or another CDN on top for comparable edge distribution.
• Essentially no independent third-party reviews. The project doesn’t appear in self-hosted review roundups with detailed real-world performance data. Validation is primarily the README and official website.

---

Who should use this / who shouldn’t

Use Flyimg if:

• You’re paying Cloudinary or imgix for resize, compress, and convert operations — nothing more — and want that recurring cost eliminated.
• You have a developer available to set up and maintain a Docker container.
• Your transformations are simple: resize, compress, format convert. No AI features, no video, no complex pipelines.
• You want AVIF and WebP output automatically without building a custom processing pipeline.
• AGPL-3.0 is acceptable for your licensing situation.

Consider imgproxy instead if:

• Throughput matters — imgproxy is Go-based, libvips-backed, and substantially faster per core for high-volume pipelines.
• You need watermarking, signed URLs, or more advanced transformation options.
• You want a more actively developed project with commercial support options.

Consider Thumbor instead if:

• You need smart cropping with face detection.
• MIT license is a hard requirement (Thumbor is MIT; Flyimg is AGPL-3.0).
• Your team is Python-based and wants to contribute to or customize the internals.

Stay on Cloudinary if:

• You need a global CDN, DAM features, video processing, or AI-powered tagging.
• Your team is non-technical and can’t manage a Linux server or Docker container.
• You need SLA-backed uptime guarantees and 24/7 vendor support.
• Compliance requirements prohibit self-hosted infrastructure.

---

Alternatives worth considering

• imgproxy — Go-based, libvips-backed, significantly faster than Flyimg for high-throughput workloads. ~9,000 GitHub stars. Source-available license with a commercial tier. The production-serious choice for image-heavy APIs.
• Thumbor — Python-based, MIT licensed, mature, with smart cropping and face detection. ~10,000 GitHub stars. More complex to deploy.
• Imaginary — Go-based HTTP microservice backed by libvips (very fast), MIT licensed, minimal configuration. Used internally at scale by large organizations.
• Cloudinary — The managed alternative. Full-featured (DAM, video, AI), global CDN, expensive at volume, closed-source SaaS.
• imgix — Cleaner developer experience than Cloudinary, URL-based API similar to Flyimg’s. Per-image and per-bandwidth pricing. Closed-source SaaS.
• Bunny.net Image Optimizer — $9.50/mo add-on to Bunny CDN. Easiest managed option for sites already on Bunny. No self-hosting required.
• Sharp (Node.js) + custom caching — If you already run Node.js servers, Sharp is the fastest JavaScript image processing library. Integrating it directly eliminates the network hop to a separate service, at the cost of more custom glue code.

---

Bottom line

Flyimg does one narrow job and does it with minimal friction: accept an image URL with transformation parameters, process it, cache it, and serve it in the most efficient format the browser supports. If that’s what you’re paying Cloudinary or imgix for, Flyimg can replace the bill with a $6/mo VPS and an afternoon of setup.

The honest caveats are worth stating plainly: 1,200 GitHub stars means limited community support and limited external validation of real-world reliability; the PHP+ImageMagick stack isn’t the fastest option for high-volume pipelines; AGPL-3.0 requires attention for SaaS builders; and you’ll need a CDN in front for edge caching since Flyimg caches locally only.

For a developer-run product paying $50–$200/mo in Cloudinary bills for basic image transformations, the switch math is clear. For high-volume image APIs where throughput per core matters, benchmark imgproxy before committing to Flyimg. For non-technical founders without developer resources, the managed flyimg.io service exists — but get pricing before assuming it competes with Cloudinary on cost.

If the self-hosting setup is the blocker, that’s exactly what upready.dev deploys for clients. One-time fee, done, you own the infrastructure.

---

Sources

1. Flyimg GitHub Repository — README, source code, and configuration reference (1,200 stars, AGPL-3.0 license). https://github.com/flyimg/flyimg
2. Flyimg Official Website — “Effortless image optimization for your business.” https://flyimg.io
3. Flyimg Documentation. https://docs.flyimg.io
4. Flyimg Live Demo. https://demo.flyimg.io