pierrre/imageserver: five example binaries and one warning banner
Image server toolkit in Go
At a glance
- What is it?
- pierrre/imageserver hands Go developers resize, rotate, crop and caching as swappable backends, then leaves the server, the deployment and the upgrades to them. Its own README already says the repository is no longer maintained, which is the first thing to weigh before importing it.
- Who is it for?
- imageserver suits Go teams that already own their HTTP layer and want resize, rotate, crop and cache assembled from swappable backends, with five runnable examples to start from. It does not suit anyone waiting for a maintained service: nothing has landed in the repository since 2026-07-03, and the lint target is still pinned to golangci-lint v1.17.0 while go.mod asks for go 1.25.0.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 112 days ago.
- What is it written in?
- Mainly Go, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 22, 2026, and from our analysis. They are not legal advice.
Star history
- pierrre/imageserver2,025 ★ · +0
| Repository | 2026-10-13 | 2026-10-22 |
|---|---|---|
| pierrre/imageserver | 2k | 2k |
0 Stars in the last 9 days, measured from the daily GitHub snapshot. Compare with other projects
Editorial analysis
Five example binaries and no server of its own
pierrre/imageserver is a Go package for serving transformed images over HTTP, written for developers who already run a Go HTTP service and want resizing, rotation, cropping and caching as parts they wire together themselves. The top-level layout matches that intent: handler.go, params.go, server.go and image.go sit beside the cache/, graphicsmagick/, http/, image/ and source/ subpackages, and nothing in the tree is a ready service definition.
What the build produces is a set of examples. The Makefile's build target compiles five programs into a build directory, one per example package, and the test target runs go test ./... across the module. No Dockerfile and no packaged artifact appear in the repository, so the unit you deploy is a main package you write yourself against these imports.
That is the trade-off hiding inside the last line of the feature list, fully modular. Every backend is an interface, and nothing binds them together on your behalf.
Graphicsmagick has no module requirement while the other two do
Three resize backends are named: GIFT, nfnt resize and Graphicsmagick. Two of them are ordinary module requirements, github.com/disintegration/gift v1.2.0 and github.com/nfnt/resize at pseudo-version v0.0.0-20180221191011-83c6a9932646. Graphicsmagick appears in neither the require block nor the indirect block of go.mod, even though the repository keeps a graphicsmagick/ package of its own. One feature line therefore mixes an import you vendor with a backend you must supply yourself, and go.mod records only the first kind.
Rotation is counted counterclockwise. An arbitrary angle needs a fill colour for the corners: rotation=45&background=ffaa88 rotates a picture against an explicit background. Gamma correction is a separate switch, gamma_correction=true or gamma_correction=false, and the demo images pair it with width=200 on a JPEG and a PNG.
width, height, mode, rotation and crop are the whole interface
Everything a client can ask for travels in the query string. A lone width value preserves the aspect ratio, width and height together change it, mode=fit fits the picture inside the box, and mode=fill fills the box and crops the overflow. The tables in the README are backed by a live host, imageserver.pierredurand.fr:
https://imageserver.pierredurand.fr/large.jpg?width=200&height=200&mode=fill
https://imageserver.pierredurand.fr/large.jpg?rotation=90&width=200
https://imageserver.pierredurand.fr/huge.jpg?crop=556,111|2156,1711&width=200Crop has its own coordinate grammar, min_x,min_y|max_x,max_y, with a pipe between the two corners, so the same host serves three crops of huge.jpg at 556,111|2156,1711, 956,511|1756,1311 and 1252,799|1460,1022. Animation survives the same path: spaceship.gif?width=300 comes back resized as an animated GIF.
One parameter name breaks the pattern among them: gamma_correction is written as two words joined together, while every other option is a single lowercase word. Those strings are the contract, and params.go is where they are parsed.
Six examples listed, five directories on disk
The example list runs to six entries: Simple, Advanced, Cache, Groupcache, HTTP Source and Mandelbrot. The examples/ directory holds five, advanced/, cache/, groupcache/, httpsource/ and simple/, and the Makefile compiles exactly those five binaries. The sixth bullet points outside this repository, at the mandelbrot package under pierrre/mandelbrot and a demo at mandelbrot.pierredurand.fr that renders a fractal through the pipeline. Anyone who copies the list into a plan ends up chasing a path that does not exist inside imageserver, and the bullet is easy to trust because it looks exactly like the other five.
The demos on the host all run the advanced example, which leaves simple as the only package in the tree with no demonstration behind it.
Four cache backends behind one cache package
The cache/ package exposes four backends: groupcache, Redis, Memcache and an in-memory map. go.mod pins them separately, github.com/golang/groupcache at v0.0.0-20190129154638-5b532d6fd5ef, github.com/go-redis/redis v6.15.2+incompatible, github.com/bradfitz/gomemcache at v0.0.0-20190329173943-551aad21a668, and github.com/pierrre/lrucache at v0.0.0-20150302143820-f5fef5733804 for the in-process path.
A second mismatch sits next to it. The Redis link in the feature list points at github.com/garyburd/redigo, the client library go.mod does not require; the module asks for go-redis/redis instead. Copying the import from the feature list leaves you with a dependency the build never fetched.
Two example programs cover caching, examples/cache and examples/groupcache, so the distributed path has a worked example and the in-memory path is left to the reader.
Sources are an interface too, and HTTP is one of them
The source/ package sits at the top level next to cache/ and image/, and examples/httpsource is a build target of its own, which means the toolkit can pull bytes from an HTTP endpoint rather than from a file path. What it will not do is invent storage for you. There is no S3 client, no database driver and no upload endpoint among the listed top-level entries, so wherever your originals live has to be reachable through something this package already knows how to read.
For a self-contained demonstration of that path the README points outside again, at pierrre/mandelbrot, whose HTTP server example generates the pixels it feeds to the pipeline rather than reading them.
make build compiles five examples and lint is pinned to v1.17.0
Building means running make from a checkout with a Go toolchain, because the Makefile turns each example into a binary under build/:
export GO111MODULE=on
build/example-simple:
go build -o build/example-simple ./examples/simple
build/example-advanced:
go build -o build/example-advanced ./examples/advanced
test:
go test ./...Each target name repeats the output path it produces, so the two shown leave build/example-simple and build/example-advanced behind, and the full build target leaves five programs in build/ once it finishes. The repository sets GO111MODULE=on even though the module itself is defined by go.mod, which asks for go 1.25.0.
Tests sit beside the code: handler_test.go, image_test.go, params_test.go and server_test.go, plus image_benchmark_test.go and params_benchmark_test.go, so the resize and parameter paths carry benchmark coverage in the tree. Lint is a separate target that curls an installer first and then pins golangci-lint v1.17.0, which is far older than the toolchain go.mod targets.
The not-maintained warning next to a 2026-07-03 push
Three facts set the boundary. The README opens with a warning that the repository is not maintained anymore, and the last push was on 2026-07-03, so upstream fixes to anything you inherit are not arriving. The build badge still points at travis-ci with branch=master while the default branch is main, a stale marker worth ignoring. The test-only dependencies tell a third story: pierrre/compare v1.0.2 sits beside onsi/ginkgo v1.8.0 and gomega v1.5.0 in the indirect block, harness versions from an era well before go 1.25.0.
The licence is MIT, so a fork carries no copyleft obligation and no duty beyond keeping the notice in the files.
Neither the README nor the listed top-level entries mention authentication, rate limiting, or a ceiling on width and height, so a request such as `large.jpg?width=200&height=200&mode=fill` is the whole access model on display. Skipping the toolkit is a real option: import github.com/disintegration/gift v1.2.0 and golang.org/x/image v0.41.0 and write the parameter parsing yourself. You give up the cache interfaces, the HTTP source and the tested handlers, and you keep the resize calls without inheriting a dependency its own README calls abandoned.
Editorial conclusion
imageserver suits Go teams that already own their HTTP layer and want resize, rotate, crop and cache assembled from swappable backends, with five runnable examples to start from. It does not suit anyone waiting for a maintained service: nothing has landed in the repository since 2026-07-03, and the lint target is still pinned to golangci-lint v1.17.0 while go.mod asks for go 1.25.0. Before importing it, run make build and go test ./... on your own toolchain, then read examples/advanced/advanced.go end to end and confirm which cache backend you can operate yourself.
Frequently asked questions
How do I build the pierrre/imageserver examples?
Run make from a checkout: the build target compiles five programs into a build directory, one per example package, and the test target runs go test ./.... Targets exist per binary, such as build/example-simple running go build on ./examples/simple.
Which resize backends does imageserver support?
Three: GIFT, nfnt resize and Graphicsmagick. go.mod requires github.com/disintegration/gift v1.2.0 and github.com/nfnt/resize, while Graphicsmagick appears in no require block and has its own graphicsmagick/ package in the repository.
Can imageserver fetch images over HTTP instead of from disk?
Yes, the source/ package abstracts image sources and examples/httpsource is one of the five build targets. Storage systems such as S3 are not among the listed top-level repository entries.
Is pierrre/imageserver still maintained?
The README carries a warning that the repository is not maintained anymore, and the last push was on 2026-07-03. The repository also has no GitHub releases to fall back on.
Which cache backends does imageserver support?
groupcache, Redis, Memcache and an in-memory cache behind the cache/ package, with worked examples in examples/cache and examples/groupcache. go.mod pins go-redis/redis v6.15.2+incompatible, although the README links the older garyburd/redigo client.
What image formats can imageserver convert?
The feature list names JPEG, animated GIF, PNG, BMP and TIFF. The demos show an animated GIF resized with width=300 and returned as an animation.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/pierrre-imageserver)Star history chart for your README
[](https://hysenlabs.com/projects/pierrre-imageserver)