The KissCache Caching Server background image

The KissCache Caching Server

Rémi Duraffort

Linaro has recently developed and open-sourced KissCache, a simple and stupid caching server built on the KISS principle: Keep It Simple Stupid.

Unlike classical proxies like Squid that transparently intercept traffic, in order to use KissCache one must explicitly prefix the requested URL by the URL of the local KissCache instance. KissCache will download the requested resource in the background while streaming it to the client.

If many clients are requesting the same resource, KissCache will download it only once and stream the content to every client.

Use case

At Linaro we use KissCache in our CI system to cache build artefacts (kernel, rootfs, ramdisk, dtb).

For instance, when LKFT is validating a Linux kernel LTS release-candidate, it will submit many jobs to LAVA to be executed on a variety of hardware platforms. These jobs will run in parallel, using many of the same artefacts. Thanks to KissCache, our CI system will download each resource only once, saving network bandwidth.


In the last month, Linaro’s KissCache deployment handled more than 160k requests, serving 32TB of data while only downloading 1TB from outside of the Linaro lab. When artefacts are hosted on a system where network bandwidth is charged per unit (such as Amazon S3), this can amount to several thousands of dollars in savings per month (as is the case in Linaro.)


Linaro has long used Squid in the Linaro embedded device Lab, but it has struggled to meet our requirements to:

  • download each resource only once when requesting the same URL in parallel
  • cache https resources

Configuring any proxy to handle https resources is fairly difficult and requires working around the security features of SSL certificates. When a client requests while using a proxy, the proxy would need to provide a valid SSL certificate for ‘’. This will break usual assumptions about SSL certificates as only ‘’ should be able to generate such certificates.

In order to generate a valid certificate for ‘’, a site admin could:

  • generate a root certificate
  • install it on each client
  • configure the proxy to sign every requested domain with this root certificate

The client would accept this fake certificate since it is signed by a known root certificate.

While this is a working solution, if the root certificate is stolen, an attacker would be able to set up a man-in-the-middle attack on every local SSL connection.

KissCache does not need to implement such an SSL hack since the client is directly connected to the KissCache instance that can return its own SSL certificate.

KissCache Usage

To quickly create a local instance of KissCache do the following:

git clone cd KissCache
docker-compose build
docker-compose up

The instance will be available at http://localhost:8001.

You can now use this KissCache instance by prefixing the URL:


KissCache workers will download the resource and stream it back to you.



By default, KissCache will keep each URL for 10 days. The admin may update the default value while users can specify the duration in the request URL.


Every hour, KissCache will automatically delete resources that are outdated.


By default, KissCache will use 2 GB of disk space. When the quota is full, KissCache will return a 507 (Insufficient Storage) error for every new request.

If the quota usage is above 75%, KissCache will drop enough resources to lower the quota usage below 75%. KissCache will drop the least recently used resources first.

Access Restriction

KissCache access can be restricted to a given network. Only IPs from a specific subnet would be able to fetch resources while the web interface will remain visible to anyone.


KissCache is licenced under the MIT licence.

The source code is available on GitLab. Feel free to create an issue or to send a merge request.