Deploying static files

See also

For an introduction to the use of django.contrib.staticfiles, seeManaging static files (e.g. images, JavaScript, CSS).

Serving static files in production

The basic outline of putting static files into production is simple: run thecollectstatic command when static files change, then arrange forthe collected static files directory (STATIC_ROOT) to be moved tothe static file server and served. Depending on STATICFILES_STORAGE,files may need to be moved to a new location manually or the post_process methodof the Storage class might take care of that.

Of course, as with all deployment tasks, the devil's in the details. Everyproduction setup will be a bit different, so you'll need to adapt the basicoutline to fit your needs. Below are a few common patterns that might help.

Serving the site and your static files from the same server

If you want to serve your static files from the same server that's alreadyserving your site, the process may look something like:

• Push your code up to the deployment server.
• On the server, run collectstatic to copy all the static filesinto STATIC_ROOT.
• Configure your web server to serve the files in STATIC_ROOTunder the URL STATIC_URL. For example, here'show to do this with Apache and mod_wsgi.You'll probably want to automate this process, especially if you've gotmultiple web servers.

Serving static files from a dedicated server

Most larger Django sites use a separate Web server — i.e., one that's not alsorunning Django — for serving static files. This server often runs a differenttype of web server — faster but less full-featured. Some common choices are:

• Nginx
• A stripped-down version of ApacheConfiguring these servers is out of scope of this document; check eachserver's respective documentation for instructions.

Since your static file server won't be running Django, you'll need to modifythe deployment strategy to look something like:

• When your static files change, run collectstatic locally.
• Push your local STATIC_ROOT up to the static file server into thedirectory that's being served. rsync is acommon choice for this step since it only needs to transfer the bits ofstatic files that have changed.

Serving static files from a cloud service or CDN

Another common tactic is to serve static files from a cloud storage providerlike Amazon's S3 and/or a CDN (content delivery network). This lets youignore the problems of serving static files and can often make forfaster-loading Web pages (especially when using a CDN).

When using these services, the basic workflow would look a bit like the above,except that instead of using rsync to transfer your static files to theserver you'd need to transfer the static files to the storage provider or CDN.

There's any number of ways you might do this, but if the provider has an API acustom file storage backend will make theprocess incredibly simple. If you've written or are using a 3rd party customstorage backend, you can tell collectstatic to use it by settingSTATICFILES_STORAGE to the storage engine.

For example, if you've written an S3 storage backend inmyproject.storage.S3Storage you could use it with:

STATICFILES_STORAGE = 'myproject.storage.S3Storage'

Once that's done, all you have to do is run collectstatic and yourstatic files would be pushed through your storage package up to S3. If youlater needed to switch to a different storage provider, it could be as simpleas changing your STATICFILES_STORAGE setting.

For details on how you'd write one of these backends, see编写一个自定义存储系统. There are 3rd party apps available thatprovide storage backends for many common file storage APIs. A good startingpoint is the overview at djangopackages.org.

Learn more

For complete details on all the settings, commands, template tags, and otherpieces included in django.contrib.staticfiles, see thestaticfiles reference.