imageproxy is a caching image proxy server written in go. It features:
- basic image adjustments like resizing, cropping, and rotation
- access control using allowed hosts list or request signing (HMAC-SHA256)
- support for jpeg, png, webp (decode only), tiff, and gif image formats (including animated gifs)
- caching in-memory, on disk, or with Amazon S3, Google Cloud Storage, Azure Storage, or Redis
- easy deployment, since it's pure go
Personally, I use it primarily to dynamically resize images hosted on my own site (read more in this post). But you can also enable request signing and use it as an SSL proxy for remote images, similar to atmos/camo but with additional image adjustment options.
I aim to keep imageproxy compatible with the two most recent major go releases. I also keep track of the minimum go version that still works (currently go1.18), but that might change at any time. You can see the go versions that are tested against in .github/workflows/tests.yml.
imageproxy URLs are of the form http://localhost/{options}/{remote_url}
.
Options are available for cropping, resizing, rotation, flipping, and digital signatures among a few others. Options for are specified as a comma delimited list of parameters, which can be supplied in any order. Duplicate parameters overwrite previous values.
See the full list of available options at https://pkg.go.dev/willnorris.com/go/imageproxy#ParseOptions.
The URL of the original image to load is specified as the remainder of the path. It may be included in plain text without any encoding, percent-encoded (aka URL encoded), or base64 encoded (URL safe, no padding).
When no encoding is used, any URL query string is treated as part of the remote URL.
For example, given the proxy URL of http://localhost/x/http://example.com/?id=1
,
the remote URL is http://example.com/?id=1
.
When percent-encoding is used, the full URL must be encoded.
Any query string on the proxy URL is NOT included as part of the remote URL.
Percent-encoded URLs must be absolute URLs;
they cannot be relative URLs used with a default base URL.
For example, http://localhost/x/http%3A%2F%2Fexample.com%2F%3Fid%3D1
.
When base64 encoding is used, the full URL must be encoded.
Any query string on the proxy URL is NOT included as part of the remote URL.
Base64 encoded URLs may be relative URLs used with a default base URL.
For example, http://localhost/x/aHR0cDovL2V4YW1wbGUuY29tLz9pZD0x
.
The following live examples demonstrate setting different options on this source image, which measures 1024 by 678 pixels.
The smart crop feature can best be seen by comparing crops of this source image, with and without smart crop enabled.
Options | Meaning | Image |
---|---|---|
150x300 | 150x300px, standard crop | |
150x300,sc | 150x300px, smart crop |
Transformation also works on animated gifs. Here is this source image resized to 200px square and rotated 270 degrees:
Install the package using:
go install willnorris.com/go/imageproxy/cmd/imageproxy@latest
Once installed, ensure $GOPATH/bin
is in your $PATH
, then run the proxy
using:
imageproxy
This will start the proxy on port 8080, without any caching and with no allowed host list (meaning any remote URL can be proxied). Test this by navigating to http://localhost:8080/500/https://octodex.github.com/images/codercat.jpg and you should see a 500px square coder octocat.
By default, the imageproxy command does not cache responses, but caching can be
enabled using the -cache
flag. It supports the following values:
-
memory
- uses an in-memory LRU cache. By default, this is limited to 100mb. To customize the size of the cache or the max age for cached items, use the formatmemory:size:age
where size is measured in mb and age is a duration. For example,memory:200:4h
will create a 200mb cache that will cache items no longer than 4 hours. -
directory on local disk (e.g.
/tmp/imageproxy
) - will cache images on disk -
s3 URL (e.g.
s3://region/bucket-name/optional-path-prefix
) - will cache images on Amazon S3. This requires either an IAM role and instance profile with access to your your bucket orAWS_ACCESS_KEY_ID
andAWS_SECRET_KEY
environmental variables be set. (Additional methods of loading credentials are documented in the aws-sdk-go session package).Additional configuration options (further documented here) may be specified as URL query string parameters, which are mostly useful when working with s3-compatible services:
- "endpoint" - specify an alternate API endpoint
- "disableSSL" - set to "1" to disable SSL when calling the API
- "s3ForcePathStyle" - set to "1" to force the request to use path-style addressing
For example, when working with minio, which doesn't use regions, provide a dummy region value and custom endpoint value:
s3://fake-region/bucket/folder?endpoint=minio:9000&disableSSL=1&s3ForcePathStyle=1
Similarly, for Digital Ocean Spaces, provide a dummy region value and the appropriate endpoint for your space:
s3://fake-region/bucket/folder?endpoint=sfo2.digitaloceanspaces.com
-
gcs URL (e.g.
gcs://bucket-name/optional-path-prefix
) - will cache images on Google Cloud Storage. Authentication is documented in Google's Application Default Credentials docs. -
azure URL (e.g.
azure://container-name/
) - will cache images on Azure Storage. This requiresAZURESTORAGE_ACCOUNT_NAME
andAZURESTORAGE_ACCESS_KEY
environment variables to bet set. -
redis URL (e.g.
redis://hostname/
) - will cache images on the specified redis host. The full URL syntax is defined by the redis URI registration. Rather than specify password in the URI, use theREDIS_PASSWORD
environment variable.
For example, to cache files on disk in the /tmp/imageproxy
directory:
imageproxy -cache /tmp/imageproxy
Reload the codercat URL, and then inspect the contents of
/tmp/imageproxy
. Within the subdirectories, there should be two files, one
for the original full-size codercat image, and one for the resized 500px
version.
Multiple caches can be specified by separating them by spaces or by repeating
the -cache
flag multiple times. The caches will be created in a tiered
fashion. Typically this is used to put a smaller and faster in-memory cache
in front of a larger but slower on-disk cache. For example, the following will
first check an in-memory cache for an image, followed by a gcs bucket:
imageproxy -cache memory -cache gcs://my-bucket/
By default, imageproxy will respect the caching directives in response headers,
including the cache duration and explicit instructions not to cache the response,
such as no-store
and private
cache-control directives.
You can force imageproxy to cache responses, even if they explicitly say not to,
by passing the -forceCache
flag. Note that this is generally not recommended.
A minimum cache duration can be set using the -minCacheDuration
flag. This
will extend the cache duration if the response header indicates a shorter value.
If called without the -forceCache
flag, this will have no effect on responses
with the no-store
or private
directives.
imageproxy -cache /tmp/imageproxy -minCacheDuration 5m
You can limit images to only be accessible for certain hosts in the HTTP referrer header, which can help prevent others from hotlinking to images. It can be enabled by running:
imageproxy -referrers example.com
Reload the codercat URL, and you should now get an error message. You can
specify multiple hosts as a comma separated list, or prefix a host value with
*.
to allow all sub-domains as well.
You can limit the remote hosts that the proxy will fetch images from using the
allowHosts
and denyHosts
flags. This is useful, for example, for locking
the proxy down to your own hosts to prevent others from abusing it. Of course
if you want to support fetching from any host, leave off these flags.
Try it out by running:
imageproxy -allowHosts example.com
Reload the codercat URL, and you should now get an error message. Alternately, try running:
imageproxy -denyHosts octodex.github.com
Reloading the codercat URL will still return an error message.
You can specify multiple hosts as a comma separated list to either flag, or
prefix a host value with *.
to allow or deny all sub-domains. You can
also specify a netblock in CIDR notation (127.0.0.0/8
) -- this is useful for
blocking reserved ranges like 127.0.0.0/8
, 192.168.0.0/16
, etc.
If a host matches both an allowed and denied host, the request will be denied.
You can limit what content types can be proxied by using the contentTypes
flag. By default, this is set to image/*
, meaning that imageproxy will
process any image types. You can specify multiple content types as a comma
separated list, and suffix values with *
to perform a wildcard match. Set the
flag to an empty string to proxy all requests, regardless of content type.
Instead of an allowed host list, you can require that requests be signed. This is useful in preventing abuse when you don't have just a static list of hosts you want to allow. Signatures are generated using HMAC-SHA256 against the remote URL, and url-safe base64 encoding the result:
base64urlencode(hmac.New(sha256, <key>).digest(<remote_url>))
The HMAC key is specified using the signatureKey
flag. If this flag
begins with an "@", the remainder of the value is interpreted as a file on disk
which contains the HMAC key.
Try it out by running:
< D85B div class="highlight highlight-source-shell notranslate position-relative overflow-auto" dir="auto" data-snippet-clipboard-copy-content="imageproxy -signatureKey "secretkey"">imageproxy -signatureKey "secretkey"