wsrv.nl images is a self-hostable image processing and caching server for developers who want to resize, convert, and proxy remote images from their own infrastructure instead of depending on a third-party image CDN.

What it is

This project is the open-source code behind wsrv.nl, formerly images.weserv.nl — a service that fetches images from anywhere on the web, processes them on request, and serves them back over HTTP. Written in C++ and released under the BSD 3-Clause License, it is built directly on two core dependencies: libvips, which performs the image handling and manipulation, and nginx, which serves as the web server, forward proxy, and HTTP cache. It runs on Linux and is designed to be deployed on your own server(s), whether as a single instance or as part of a larger stack.

The concrete problem it solves is that applications often need resized, converted, or otherwise transformed versions of images hosted on arbitrary remote URLs, and doing that work yourself means standing up image processing libraries, a caching layer, and a proxy in front of them. This project packages that whole pipeline — fetching a remote image, applying transformations through its API, and returning the result with appropriate caching — into a deployable service, backed by supporting infrastructure such as Cloudflare for CDN caching and IP-blocking, Valkey for rate limiting, and OpenDNS for DNS-filtering.

Key capabilities

• Serves as a forward proxy that fetches images from remote URLs and returns processed results, with nginx handling both the web server and HTTP cache roles.
• Performs image handling and manipulation through libvips, covering resizing, conversion, and other transformations defined by its API parameters.
• Applies rate limiting through Valkey, and DNS-filtering through OpenDNS.
• Provides CDN caching and IP-blocking via Cloudflare integration.
• Deploys through Docker, with dedicated Docker installation instructions and compose configuration in the docker/README.md file.
• Ships with an API reference and a wiki documenting how to call the service.
• Tracks bugs, support tickets, and feature requests through a public GitHub issue tracker.

Who uses it and how

• Teams that want to offload image resizing from their application servers by pointing image URLs at a dedicated, self-run image endpoint.
• Operators who already run nginx and want the proxy, cache, and processing layers combined into one deployable service rather than assembled separately.
• Self-hosters with compliance or data-ownership requirements who need image transformation without sending traffic through an external image CDN.
• Contributors and integrators working against the public API reference and wiki, using the GitHub issue tracker to file bugs and request features.

Getting started

Deployment is handled through Docker, following the installation instructions in docker/README.md, with the wiki and API reference covering usage once the service is running.

How it compares

The source code is openly licensed under the BSD 3-Clause License and runs entirely on your own server(s), so the images you fetch, process, and cache remain under your control with no per-image cost model. That self-hosted, licence-transparent posture is the main axis on which it differs from hosted image CDN services, where processing happens on someone else's infrastructure under their terms.

When to use it — and when not

A self-hoster must operate and maintain a real stack: Linux, nginx, libvips, a Docker deployment, plus Valkey for rate limiting and DNS/CDN layers such as OpenDNS and Cloudflare if those features are wanted, so it is not a drop-in choice for someone seeking a single binary. The project's own materials note that the README is deliberately sparse, deferring to a separate wiki and API reference, and the licence is BSD 3-Clause rather than a copyleft one — worth checking if your project requires reciprocal licensing terms.