Caching and CDN in Divio applications
Infrastructure-level caching
As well as the caching and CDN (Content Delivery Network) we provide, you can also apply your own.
Caching is generally provided by Cloudflare. Other options can be provided or managed on request.
Infrastructure-level caching is URL-based, and content-unaware - caching does not detect when files have changed.
Media storage caching
Caching for media storage is automatically provided available on all applications and plans, and on Test as well as Live servers. Note that this only includes files served from our media storage services (S3 buckets, Azure Blob storage instances). Resources served by the application instances (HTML, static files) are not cached.
On request we can also provide Cloudflare Polish and Mirage optimisation for images.
Some of the media storage domains we use are not cached, including: sos-ch-dk-2.exo.io, aldryn-media.io, s3.amazonaws.com.
Controlling caching headers
Cloudflare will cache media files according to the Cache-Control header applied to the files. For example:
cache-control: max-age=3600
will set a TTL of one hour (3600 seconds).
Your application can set these headers when managing the file storage.
Application content caching
We can also provide managed caching of application content (including custom page rules) using Cloudflare or other services, on request.
Applying your own caching/CDN
You may also provide your own caching and CDN.
For media files, if you are using our media domain (the default), your applications will automatically use the CDN we provide and this cannot be changed. However, it's also possible to use your own domain (see for example How to configure media serving on a custom domain) for media, in which case you are free to use what you wish.
For other resources (served by the containers) you can set up another CDN, for example using your own Cloudflare account. In such a case you should inform us so that instead of providing a certificate automatically ourselves, you can upload your own manually.
In-application caching
Caching in your application is up to you and the stack you are using. For example, Django applications will typically make use of Django's own caching framework.
Application caching options
What not to use in your code
Caching should rely on a shared store that persists for all containers. For example, caching that relies on a container's local file-system or local memory should not be used, as only that container (and not a container running in parallel, or one instantiated later) will be able to access the items it stores.
In some cases, this can simply lead to inefficiency (not using cached data). In other cases, it could cause malfunction or even data-loss, if two instances are working with inconsistent data.
Database caching
Database caching is shared by all instances of an application server. It's a fast, scalable option, and is suited to most needs.
Third-party caching backends
Other backends, such as Redis (a popular open-source database) can be used as caching backends for Django.
If it suits your needs, you can procure a Redis or other caching instance from a provider and use it with your Divio application.