Self-hosting image optimization: the honest tradeoffs

The default advice for images is a managed service — Cloudinary, imgix, and friends. That advice is often correct, and this is not a “SaaS bad” post. It’s an honest look at the tradeoff, from a project that sits on the self-hosted side of it.

What the managed services genuinely give you

• No ops. No servers, no encoder toolchains, no CDN to configure. It works the day you sign up.
• Transforms at the edge, globally. Resize, crop, format-negotiate on the fly, cached in hundreds of points of presence. Hard to match without real infrastructure.
• Someone else owns the hard parts — new formats, encoder bugs, scaling under a traffic spike.

For a small team without infrastructure people, that is worth paying for. Don’t self-host to prove a point.

Where the managed model gets expensive — and not just in money

The friction shows up along three axes as you grow:

• Cost that scales with success. Managed image services meter on some mix of transformations, stored assets, and bandwidth. Your bill grows with your traffic, and the unit economics are set by the vendor, not you. A hobby project is free; a popular one is a line item that only goes up.
• Your images leave your control. Every asset — and every user upload — passes through and is cached on a third party’s infrastructure. For some products that is a privacy, compliance, or contractual problem, not a preference.
• You optimize their way. You get the quality knobs the vendor exposes. If you want to target a perceptual quality per image rather than a fixed setting (the difference between shipping consistent quality and shipping a guess), you get what the platform offers.

None of these is a reason to leave on day one. All of them are reasons the calculus flips at some scale.

The self-hosted options are real now

Self-hosting used to mean gluing ImageMagick to a cache and hoping. The current tools are solid:

• imgproxy and Thumbor — on-the-fly resize/transform servers you run.
• wsrv.nl (images.weserv.nl) — an open-source image CDN you can self-host.
• Patu — an optimization API you host, quality-targeted by perceptual score, with a CDN layer.

You put a CDN in front of any of them and you have the managed experience, on your own compute, with a cost that’s your server bill instead of a per-image meter.

What self-hosting actually costs

Honesty cuts both ways. Self-hosting is not free-as-in-effort:

• You run it. Uptime, scaling under load, the CDN, and keeping the encoder toolchain current are now yours.
• You need a cache. Optimizing well is CPU-heavy — a quality search over a large photo isn’t cheap. Re-encoding the same asset on every request is the classic self-hosted mistake; the whole model depends on encoding once and serving from cache/CDN.
• You own the edge cases. A corrupt upload, a pathological image, a new format — no vendor absorbs those for you.

The reward is a predictable cost that doesn’t scale with your traffic, data that never leaves infrastructure you control, and the freedom to optimize exactly how you want.

How to actually decide

• No infra team, images are incidental to the product → managed. It’s the right call, unapologetically.
• Images are core, traffic is real, or the per-image bill has started to hurt → self-host, with a cache and a CDN.
• User uploads you can’t send to a third party, or a specific quality bar you want to hold → self-host, and it’s less a cost decision than a control one.

Patu exists for the second and third cases: the same result a managed service gives you — AVIF-first, quality-targeted, behind a CDN — on infrastructure you run, priced like software instead of like a meter. Whether that’s the right trade is genuinely yours to make; this post is here so you make it with the real tradeoffs in front of you, not the marketing version.

Patu is open about being one option among several; the projects linked above are the real alternatives, and the right choice depends on your team, traffic and data constraints, not on which post you read last.