CDN for Django
Take staticfiles and media off the Django workers.
Django applications often still serve STATIC_URL and MEDIA_URL from the same origin that runs views. That is wasted worker time under load.
Point STATIC_URL and MEDIA_URL at Cloud CDN. Cache anonymous pages where safe. Bypass admin, authenticated views and POST.
Why teams use Aptranet
What CDN for Django looks like on this network.
Cloud CDN caches and accelerates eligible content on 210+ points of presence, with Origin Shield when the origin must stay out of the way.
collectstatic at the edge
Hashed staticfiles are cached on 210+ PoPs.
MEDIA_URL worldwide
Uploads are cached and can be resized at delivery time.
Admin stays on Django
django-admin and session views are not cached.
How to set it up
A cutover you can validate before DNS moves.
Create the Cloud CDN configuration, prove it on an Aptranet hostname, then point production DNS when the path looks correct.
- 1Set STATIC_URL to the CDN hostname
After collectstatic lands on an origin Cloud CDN can pull.
- 2Do the same for public media
Map MEDIA_URL for publicly readable uploads.
- 3Cache anonymous views optionally
Marketing or docs views can be cached with purge.
- 4Keep CSRF and admin dynamic
Never cache POST or authenticated HTML.
Outcomes
What changes once the hostname is on Aptranet.
- Django staticfiles are global
- Public media is cached at the edge
- Admin and CSRF flows remain on origin
- Workers handle views instead of CSS
Keep reading
Related pages
More CDN use cases on the same Cloud CDN footprint.
Frequently Asked Questions
WhiteNoise can still serve as origin. Cloud CDN caches that result worldwide and offloads the app cluster.
Keep hashed filenames. Long-cache those files and purge unhashed HTML on deploy.
Public, identical GET responses can be cached. Authenticated APIs must bypass cache.
Use the storage hostname as origin or sit Cloud CDN in front of it for the public URL.