imgproxy

imgproxy is a lightweight, high‑performance image processing server designed to replace in‑app resizing logic or heavyweight libraries such as ImageMagick. It exposes a single HTTP endpoint that accepts a compact, signed URL encoding all transformation parameters. On receipt, the server parses the URL, validates a cryptographic signature to guard against tampering, and then streams the transformed image directly from your storage backend (S3, GCS, local filesystem, etc.) to the client. The entire pipeline is built around libvips, a streaming image library that keeps memory usage minimal and achieves processing speeds up to 10× faster than Pillow or ImageMagick on typical workloads.

The core of imgproxy is written in Go, leveraging its native concurrency model and static binaries for easy deployment. The application exposes a RESTful API that accepts query parameters or path segments to specify transformations (resize, crop, rotate, flip, format conversion, quality adjustment). Security is enforced through HMAC‑SHA256 signatures generated with a shared secret; the server validates these before any processing occurs. imgproxy can be run behind any reverse proxy or CDN, and it supports TLS termination upstream to keep the binary simple. The only external dependency is the image processing library libvips (via cgo), which ships with the Docker image or can be installed natively on Linux. No database is required; configuration is purely environment‑variable driven, making the service stateless and horizontally scalable.

• URL‑Based Transformation – All operations are encoded in the request URL (e.g., /w:300/h:200/filters:blur-5/img.jpg).
• Cryptographic Signing – Every URL is signed with a secret key; tampering results in an HTTP 403.
• Multiple Backends – Supports S3, GCS, Azure Blob, MinIO, and local filesystems via a pluggable backend interface.
• Streaming – Images are streamed directly from source to client, never fully materialized in memory.
• Format Conversion – Supports JPEG, PNG, WebP, AVIF, and GIF with quality control.
• Advanced Operations – Cropping, rotation, flipping, masking (via CSS‑like syntax), and color space conversion.
• HTTP Caching Headers – Allows setting Cache-Control and ETag headers; integrates seamlessly with CDN edge caches.

Because it is a single binary, imgproxy can be deployed as a Docker container, a systemd service, or even directly on a bare‑metal server. The Docker image is tiny (~30 MB) and includes the libvips library, making it ideal for CI/CD pipelines or serverless containers. Horizontal scaling is straightforward: each instance is stateless, so you can run a cluster behind an ingress controller or load balancer. For high availability, simply expose the same secret key across all replicas and let the CDN cache responses.

While imgproxy itself is intentionally minimal, its plugin‑friendly design allows developers to extend functionality. Custom backends can be written in Go and registered via the backend interface; similarly, middleware for authentication or logging can be added to the HTTP stack. The API is fully documented in the official docs, and community contributions are encouraged through pull requests. Webhooks are not built‑in, but because the service is stateless and HTTPS‑ready, it can be paired with any webhook system for post‑processing tasks.

Configuration is controlled by environment variables (e.g., IMGPROXY_SECRET, IMGPROXY_S3_BUCKET), making it easy to inject secrets via Docker secrets or Kubernetes ConfigMaps. The documentation is concise, with examples for every transformation and backend. Community support is active on Discord, GitHub Discussions, and social channels; the maintainers respond quickly to issues. The lack of a complex setup means developers can spin up an instance in minutes and immediately start using it as part of their asset pipeline.

• Dynamic Image Resizing for Web Apps – Replace server‑side libraries with a single HTTP call, reducing code churn.
• CDN Edge Optimization – Generate thumbnails on the fly in a CDN edge location, cutting latency.
• Multi‑Platform Mobile Apps – Serve device‑specific image sizes without pre‑generating variants.
• Large Media Workflows – Process user uploads in real time, applying transformations before storage.
• Security‑Sensitive Environments – Keep all image processing in-house to avoid sending data to third‑party services.

• Performance – libvips’ streaming architecture delivers high throughput with low memory footprints.
• Security – Signed URLs prevent unauthorized manipulation; the server runs without external services.
• Simplicity – No database, no heavy dependencies; a single binary suffices.
• Licensing – Open‑source under MIT, allowing unrestricted use in