Image Foundry
A self-hostable image transformation server (resize, crop, filter by URL, like imgix) that also translates image URLs between eight competing image-CDN formats, with multi-cloud sources and signed URLs.
- 8 CDN dialects
- translated in real time
- Multi-cloud
- S3, GCS, Azure and compatibles
- 685 tests
- a genuinely-built engine, well covered
The problem
Image CDNs like imgix, Cloudinary and Cloudflare Images are convenient but each has its own URL dialect, its own pricing, and its own lock-in. Image Foundry is a self-hostable engine that does the same on-the-fly transformations — and can translate URLs between the big CDNs' formats, so switching providers doesn't mean rewriting every image URL.
What it does
Point it at an image with transformation instructions in the URL — resize, crop, format, filters — and it processes and returns the result, powered by the same high-performance image library the big services use. It can pull the source image from local disk, any HTTP URL, or S3, Google Cloud and Azure storage (and S3-compatible providers like R2 and MinIO).
Its most distinctive feature is 'the Bridge': real-time translation between eight image-CDN URL dialects, so a URL written for one provider can be served by another. It also does face-aware cropping and auto-blur with a real detection model, background removal with a segmentation model, signed and optionally expiring URLs, and exposes proper metrics — plus a large, unlaunched multi-tenant SaaS layer around the core engine.
Key features
On-the-fly transforms by URL
Resize, crop, convert and filter an image straight from its URL, so a site serves exactly the image variant it needs without pre-generating dozens of sizes.
The Bridge: translate between CDN dialects
A URL written for imgix, Cloudinary, ImageKit, Thumbor and more can be served by this engine, so moving off a provider — or supporting several — doesn't mean rewriting every image URL.
Pull from anywhere
Source images can live on local disk, any URL, or S3, Google Cloud or Azure storage, so it drops into whatever infrastructure a team already uses.
Face-aware cropping and background removal
Real detection and segmentation models mean crops keep faces in frame and backgrounds can be removed automatically, not just naive centre-crops.
Signed, expiring URLs
Transformations can be cryptographically signed and time-limited, so a public image endpoint can't be abused as a free transform-anything service.
Where it stands
A large, well-tested personal engine that runs locally — but not confirmed deployed anywhere public, and its multi-tenant SaaS layer (including billing copy) is built-but-unlaunched. Treat it as a strong prototype, not a live service.
Under the hood — for the technically-minded
How it's built
It's a Fastify service in TypeScript built around the sharp/libvips image pipeline, with pluggable source adapters for the major clouds behind one interface. The Bridge is a URL-dialect translation layer that parses one provider's parameters and re-expresses them as the engine's own. URL signing uses HMAC with constant-time comparison, and a self-rolled exporter publishes Prometheus-format metrics.
The 'fetch from anywhere' capability is deliberately hardened against being turned into an attack tool: a safe-fetch wrapper blocks internal hosts and unsafe redirects and caps response size, and path handling is symlink-safe — so a server that will fetch and transform arbitrary images can't be tricked into reaching internal services or the local filesystem.
The hard problems
Speaking every CDN's dialect
Each image CDN encodes transformations differently in its URLs. The Bridge parses one provider's parameters and faithfully re-expresses them in another's — the single most distinctive piece of engineering, and what turns a transform server into a migration and interop tool.
A 'fetch anything' server that can't be weaponised
An engine that fetches and transforms images from arbitrary URLs is a classic server-side-request-forgery risk. It's hardened deliberately — internal hosts and unsafe redirects blocked, response sizes capped, symlink-safe paths — so the convenience of fetching from anywhere doesn't open a hole into internal infrastructure.
Honest about which features use ML
The face auto-blur uses real face detection (bounding boxes); a separate real segmentation model does background removal; and the headline 'privacy filter' blurs a manually-specified rectangle with no ML at all. Each is described for exactly what it is, rather than lumped together as one magic feature.
Built with
- Fastify
- sharp
- TensorFlow.js
- S3/GCS/Azure
Building something in this space?
Work with us →