Static files for Python apps behind CDNs: WhiteNoise

(Note: this post presumes you have, or want, a CDN in front of your site, which not everybody does. If you are satisfied without one, this post may be moot for you.)

I recently came across WhiteNoise, “Radically simplified static file serving for Python web apps”.

The basic proposition: serve static files in a way that will make the most of your CDN, while also reducing the complexity of your server setup.

To paraphrase the project’s Infrequently Asked Questions:

Q: You’re telling me to serve static files with Python OMG wat?!
A: Your CDN will serve the static files. This is just an easy way to hand them over.

Anybody who sets up a production Python app has to think about how their static files are served. Maybe they’ll be served by the same Apache/Nginx instance that serves as reverse proxy to your app? Separate static file server? Maybe you’ll put them all in S3? Send them straight to your CDN? Regardless, you have some decisions to make and some infrastructure to maintain.

Assuming a CDN, those options all feel more operationally complex to me than the WhiteNoise approach, except maybe “send the files straight to your CDN”.

(WhiteNoise’s philosophy – leveraging your CDN without setting up standalone static file serving – reminds me of the Varnish HTTP cache system. Varnish leverages operating system virtual memory facilities in a smart way, rather than reinventing them.)

“Especially useful on Heroku, OpenShift and other PaaS providers”, the docs note. This appeals to me since dpaste.com is hosted on a PaaS (PythonAnywhere). One of the reasons I made the switch to PA from self-hosting on a VPS was to be able to think less about infrastructure.

I may try this out on dpaste.com (as part of a general effort I’m calling “If traffic increased 10x or 100x overnight, could you handle it?”). For now I’m using PA’s provided static file serving, but when I want the more granular control over expiry and/or compression I will be looking to WhiteNoise.