Introduction to Production Deployment#
This guide will walk you through the steps necessary to deploy Arches in a production environment. This guide assumes that you have already installed Arches and have a working Arches installation. If you have not yet installed Arches, please see the Installing Core Arches. We recommend review of Django’s recommended checklist for production deployments in order to better understand how to deploy your Arches instances in production environments.
Set DEBUG = False#
Most importantly, you should never run Arches in production with DEBUG = True
. Open your settings.py
file (or settings_local.py
) and set DEBUG = False
(just add that line if necessary).
Turning off the Django debug mode will:
Suppress the verbose Django error messages in favor of a standard 404 or 500 error page.
You will now find Django error messages printed in your
arches.log
file.Important
Make sure you have
500.htm
and404.htm
files in your project’s templates directory!Cause Django to stop serving static files.
You must set up a real webserver, like Apache or Nginx, to serve your app. See Serving Arches with Apache.
Add Allowed Hosts and CSRF Trusted Origins to Settings#
ALLOWED_HOSTS
acts as a critical safeguard against HTTP Host header attacks, ensuring that your Arches application only responds to valid hostnames. On the other hand, CSRF_TRUSTED_ORIGINS
is instrumental in fortifying your application against Cross-Site Request Forgery (CSRF) attacks by specifying trusted origins for the submission of forms. Both of these settings are required for Arches to work properly in production. These settings are described in more detail in the Django documentation.
Allowed Hosts: In
settings.py
(sometimes set viasettings_local.py
) you will need to add multiple items to the list ofALLOWED_HOSTS
. Consider the following example:
ALLOWED_HOSTS = ["my-arches-site.org", "localhost", "127.0.0.1",]
In that example, “my-arches-site.org” is the public domain name. But the items “localhost”, “127.0.0.1” are all local network locations where Arches is deployed. You may need all of these for Arches to work properly.
CSRF Trusted Origins: Django 4.0, a dependency of Arches 7.5 introduced a new setting for security purposes. In the
settings.py
(sometimes set viasettings_local.py
) you will need to add multiple items to the list ofCSRF_TRUSTED_ORIGINS
. If you don’t include this, users will encounter CSRF error (403) then they attempt to login. See the Django documentation for details. Note the following items (with thehttps://
prefix):
CSRF_TRUSTED_ORIGINS = ["https://my-arches-site.org", "https://www.my-arches-site.org",]
Build Production Frontend Assets#
In deploying Arches in production, have a choice in how you bundle frontend assets (CSS, Javascript, etc).
You can use yarn build_development
followed by manage.py collectstatic
to provide unminified frontend bundles.
These will be larger files, so there will be a hit with respect to network performance.
Alternatively, you can build production assets for the frontend, which will be minified and therefore faster for
clients to download. To make production frontend assets, use the manage.py build_production
management command
(this combines both yarn build_production
and manage.py collectstatic
). Please note however, you will need
at least 8GB of RAM for the production frontend asset build itself (and much more if you’re also running the
database and backend Arches server on the same host), and you will need lots of time. Depending on your system
specifics, this can take multiple hours to complete.