The basic outline of putting static files into production is simple: run the\ncollectstatic command when static files change, then arrange for\nthe collected static files directory (STATIC_ROOT) to be moved to\nthe static file server and served. Depending on STATICFILES_STORAGE,\nfiles may need to be moved to a new location manually or the post_process method\nof the Storage class might take care of that.
Of course, as with all deployment tasks, the devil’s in the details. Every\nproduction setup will be a bit different, so you’ll need to adapt the basic\noutline to fit your needs. Below are a few common patterns that might help.
\nIf you want to serve your static files from the same server that’s already\nserving your site, the process may look something like:
\nPush your code up to the deployment server.
On the server, run collectstatic to copy all the static files\ninto STATIC_ROOT.
Configure your web server to serve the files in STATIC_ROOT\nunder the URL STATIC_URL. For example, here’s\nhow to do this with Apache and mod_wsgi.
You’ll probably want to automate this process, especially if you’ve got\nmultiple web servers. There’s any number of ways to do this automation, but\none option that many Django developers enjoy is Fabric.
\nBelow, and in the following sections, we’ll show off a few example fabfiles\n(i.e. Fabric scripts) that automate these file deployment options. The syntax\nof a fabfile is fairly straightforward but won’t be covered here; consult\nFabric’s documentation, for a complete\nexplanation of the syntax.
\nSo, a fabfile to deploy static files to a couple of web servers might look\nsomething like:
\nfrom fabric.api import *\n\n# Hosts to deploy onto\nenv.hosts = ['www1.example.com', 'www2.example.com']\n\n# Where your project code lives on the server\nenv.project_root = '/home/www/myproject'\n\ndef deploy_static():\n with cd(env.project_root):\n run('./manage.py collectstatic -v0 --noinput')\nMost larger Django sites use a separate Web server – i.e., one that’s not also\nrunning Django – for serving static files. This server often runs a different\ntype of web server – faster but less full-featured. Some common choices are:
\n\nConfiguring these servers is out of scope of this document; check each\nserver’s respective documentation for instructions.
\nSince your static file server won’t be running Django, you’ll need to modify\nthe deployment strategy to look something like:
\nWhen your static files change, run collectstatic locally.
Push your local STATIC_ROOT up to the static file server into the\ndirectory that’s being served. rsync is a\ncommon choice for this step since it only needs to transfer the bits of\nstatic files that have changed.
Here’s how this might look in a fabfile:
\nfrom fabric.api import *\nfrom fabric.contrib import project\n\n# Where the static files get collected locally. Your STATIC_ROOT setting.\nenv.local_static_root = '/path/to/static'\n\n# Where the static files should go remotely\nenv.remote_static_root = '/home/www/static.example.com'\n\n@roles('static')\ndef deploy_static():\n local('./manage.py collectstatic')\n project.rsync_project(\n remote_dir=env.remote_static_root,\n local_dir=env.local_static_root,\n delete=True,\n )\nAnother common tactic is to serve static files from a cloud storage provider\nlike Amazon’s S3 and/or a CDN (content delivery network). This lets you\nignore the problems of serving static files and can often make for\nfaster-loading Web pages (especially when using a CDN).
\nWhen using these services, the basic workflow would look a bit like the above,\nexcept that instead of using rsync to transfer your static files to the\nserver 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 a\ncustom file storage backend will make the\nprocess incredibly simple. If you’ve written or are using a 3rd party custom\nstorage backend, you can tell collectstatic to use it by setting\nSTATICFILES_STORAGE to the storage engine.
For example, if you’ve written an S3 storage backend in\nmyproject.storage.S3Storage you could use it with:
STATICFILES_STORAGE = 'myproject.storage.S3Storage'\nOnce that’s done, all you have to do is run collectstatic and your\nstatic files would be pushed through your storage package up to S3. If you\nlater needed to switch to a different storage provider, it could be as simple\nas changing your STATICFILES_STORAGE setting.
For details on how you’d write one of these backends, see\nWriting a custom storage system. There are 3rd party apps available that\nprovide storage backends for many common file storage APIs. A good starting\npoint is the overview at djangopackages.com.
\nFor complete details on all the settings, commands, template tags, and other\npieces included in django.contrib.staticfiles, see the\nstaticfiles reference.