Working with our recommended Django application configuration¶
Our recommended Django application configuration is mentioned in:
The Twelve-factor model adopted for these applications places all configuration in environment variables, so that the application can readily be moved to another host or platform, or set up locally for development. The configuration for:
settings is handled by a few simple code snippets in
settings.py. In each case, the settings will fall back to
safe and secure defaults.
In both local and cloud environments, the application will run in a
web container, using the same image and
exactly the same codebase.
In cloud environments: the
Dockerfile contains a
CMD that starts up Django using the production application
In the local environment: the
command line in
docker-compose.yml starts up Django using the runserver,
CMD in the
Dockerfile. If the
command line is commented out,
docker-compose up will use
the application gateway server locally instead.
In cloud environments: the application will use one of our database clusters.
In the local environment: the application will use a container running the same database.
During the build phase: the database falls back to in-memory SQLite, as there is no database available to connect to, and no configuration variables available from the environment in any case.
In cloud environments: the application will safely fall back to
DEBUG = False.
In the local environment:
.env-local supplies a
DJANGO_DEBUG variable to allow Django to run in debug mode.
In cloud environments: a random
SECRET_KEY variable is always provided and will be used.
In the local environment: where no
SECRET_KEY environment variable is provided, the application will fall back to a
hard-coded key in
In cloud environments:
DOMAIN_ALIASES variable are always provided and will be used.
In the local environment: default values are provided via the
DOMAIN_ALIASES environment variable in
Unless explicitly disabled with a
SECURE_SSL_REDIRECT = False environment variable, Django’s
In cloud environments: the application gateway server and WhiteNoise are used.
In the local environment: static files are served by the Django runserver. When you instead run the application gateway
server locally and enforce
DEBUG = False, it can be tested with WhiteNoise in the local environment.
In cloud environments: file storage and serving is handled by the S3 instance.
In the local environment: the local filesystem is used for storage, and Django’s runserver is used to serve media. If a
DEFAULT_STORAGE_DSN is applied in the
.env-local file, the local server will use the S3
In its current state, database migrations are not executed automatically in cloud deployments. To run migrations
automatically, add a release command:
python manage.py migrate. Alternatively you can run
the command manually in the cloud environment using SSH.