Deployment

Contents

1. Deploying
2. Serving Static Files
3. Serving User Uploaded Files

Deploying

This template may be deployed however you wish, we recommend you read Django's documentation on deploying.

Gunicorn is included in requirements.txt already, and deploying through gunicorn with a reverse proxy such as Nginx is our recommended approach. The template is fully configured to be deployed under a subdirectory of your website through a reverse proxy, provided that the SCRIPT_NAME header is set. You may also set the path prefix explicitly in the settings file with FORCE_SCRIPT_NAME.

Serving static files

Static files are configured to be served under the static/ path, and are expected to be in a folder called static in the django project root (adjacent to manage.py). In production, you should run python manage.py collectstatic to move all static files into the static folder, and configure your web server to serve them directly. Read more about managing static files in Django in the docs.

Serving user uploaded files

User-uploaded files are handled differently in Django than static files. We recommend you read the pages on Django file uploads and the security of user-uploaded content before proceeding.

This template is configured to expect user-uploaded content to be served at media/, per the MEDIA_URL setting (you are free to change this, for example to an off-domain URL). User-uploaded content will be put in the folder defined by MEDIA_ROOT, which defaults to /var/www/media/ and should almost certainly be configured for your server. Whatever you set it to, make sure the folder exists and is accessible by Django.

Some user-uploaded content, such as resumes, should not be served to the general public. Others, such as pictures of hardware, should be. Hence, we recommend the following:

• Upload all public-facing files with the prefix uploads/, so that they end up at media/uploads/. Configure your web server to serve this folder, e.g. /var/www/media/uploads/, to media/uploads/ under your domain.
• Upload all private files to another prefix, e.g. resumes/, so that they end up at e.g. media/resumes/. For any users that should be able to see these files (such as staff members in this case), have a view that validates the user's permission, then reads in the data from disk and returns it directly in the HTTP response. Keep in mind that there are performance downsides to this approach.