ImageKit

Promptfree, for everyone, and the only version there is

Copy the prompt for Claude CodeCopy the prompt for CodexCopy the prompt for Cursor

Copy

Build me the image pipeline I actually need instead of ImageKit.

**The transformations are the easy half and the delivery network is the expensive half.** A cheap network in front of your own resizer gets most of the value; skipping the network entirely does not.

STACK
- Node 20+ with Fastify
- sharp for every transformation
- SQLite through better-sqlite3 for the derivative index
- Object storage for originals and derivatives
- Bunny or Cloudflare in front for delivery — this is the part to buy rather than build
- Caddy in front of the origin

THE URL IS THE API
- /img/<signature>/<width>x<height>/<fit>/<path>.<ext>
- **Sign the parameters, or your origin is a free image-resizing service for the entire internet.** This is the failure that produces a surprise bill, and it is the first thing to write
- An allow-list of widths — a dozen values, not any integer. Unbounded widths mean unbounded renders of the same picture

THE PIPELINE
- Fetch the original once, store it, never modify it
- Derive on first request, write to storage, serve from cache ever after. The second request must never touch sharp
- AVIF, then WebP, then JPEG, chosen from Accept, with `Vary: Accept` set — **forget the Vary header and the network serves AVIF to a browser that cannot read it**
- Strip metadata, keep the colour profile, and honour EXIF orientation before resizing or half your portrait photographs arrive sideways
- Cap dimensions and megapixels on input. A crafted image is a memory exhaustion attack

DOING IT WITHOUT BREAKING THE PAGE
- Emit a srcset and sizes with your allow-listed widths, and set width and height so nothing shifts as it loads
- A tiny blurred placeholder generated at ingest, inline in the HTML
- Never serve an image larger than the container asked for; that is where the bandwidth goes

OPERATIONS
- A render queue with a concurrency cap; sharp is CPU-hungry and an unbounded burst takes the machine down
- **A stampede lock per derivative**: fifty simultaneous requests for one uncached image must produce one render
- Bytes served and renders per day recorded, so a bill or an abuse is visible
- A purge that changes the signature rather than trying to clear a cache you do not control

WHAT MATTERS MOST
Signed parameters and the width allow-list. Without them you have built an open image service on your own hosting bill.