CODEWITHSUNDEEP
djangodjango-staticfiles
dl8
dl8

Reputation: 1270

Why is django's development automatic static file server not suitable for production?

As stated in: https://docs.djangoproject.com/en/dev/howto/static-files/

When DEBUG is set to True, the server automatically serves the static file, but it states:

This method is grossly inefficient and probably insecure, so it is unsuitable for production.

But what exactly is inefficient and insecure about it? I just have a small-ish project on Heroku that I haven't set to "production" mode yet and I'm wondering what are the exact downsides.

Upvotes: 5

Views: 691

Answers (2)

Leonardo.Z
Leonardo.Z

Reputation: 9791

Kenneth (the author of requests, employed by Heroku) has a different opinion (source):

In reality, serving static files through Python/Django is fine for production — those requests are no different than dynamic ones.

Performance will be fantastic, but not as good as nginx.

If you're that heavily concerned about efficiency then you shouldn't be hosting those files on your server anyway, you'd be pushing them to an CDN like S3+Cloudfront and the like.

Another benefit to this approach is development:production parity.

And on heroku, you can't use Nginx to server static files, actually you can't do it on most other PaaS too, I got the same problem on cloud foundry last year. But there is a workaround:

On Heroku, your application directly responds to HTTP requests, instead of going through an additional web server like Apache or Nginx.

We recommend most applications serve their assets strait from Django or a CDN.

Django doesn't recommend serving static files in production because of the design of its static file handler.

Luckily, there is a library called DJ-Static which makes uses a production-ready WSGI asset server.

I've written up a guide for Django and Static Assets here: https://devcenter.heroku.com/articles/django-assets

Read the following discussions for more details:

Serving static files for a Django app

serving static files via gunicorn

Upvotes: 6

Paulo Scardine
Paulo Scardine

Reputation: 77251

Performance related reasons:

  • web servers are orders of magnitude better at serving static files.
  • AFAIK the development server is mono-threaded and can respond only one request at time, concurrent requests will block (most browsers make 4 concurrent requests trying to download assets in parallel).

Security related reasons:

  • using the app to serve static content is overkill (simplification is good for security)
  • the developers like to be on the safe side, so it is kind of a disclaimer
  • debug mode exposes a lot of information about the server

Django started in the news publishing industry where in general there is enough traffic to justify serving static content from a dedicated web server, probably the original developers have a bias for this arrangement.

That said, there are projects that replace the default development server by a more robust implementation based on gunicorn or tornado.

Upvotes: 7

Related Questions