• Product
  • Services
  • Developers
  • Pricing
  • Sign in
  • Sign up for free
Contents Menu Expand
Divio Developer Handbook
  • Get started
    • Installation
      • Why is the local development environment so important?
      • Before you start
      • Install Docker and Docker Compose
      • Install the Divio CLI package
      • Log in
      • Add your public SSH key to the Control Panel
      • On to the next step
    • Django
      • 1. Create a new Django project
      • 2. Set up your project locally
      • 3. Deploy your application to the cloud
      • 4. Add and configure a Postgres database
      • 5. Configure static file serving
      • 6. Add and configure media storage
      • 7. Apply some refinements
    • Aldryn
      • 1. Create a new Django project using Aldryn Django
      • 2. Set up your project locally
      • 3. Make changes and deploy them
      • 4. Configure a more complex application
    • Wagtail
      • 1. Create a new Wagtail Django project
      • 2. Set up your project locally
      • 3. Make changes and deploy them
    • Laravel
      • 1. Create a new PHP/Laravel project
      • 2. Set up your project locally
      • 3. Make changes and deploy them
      • 4. Install an application using Flavours
  • How-to guides
    • Working in the local development environment
      • Set up the Divio local development environment
      • Run the local server in Live configuration
    • Deploy an existing web application
      • Deploy an application (generic guide)
      • Deploy a Django application
      • Deploy a Flask application
      • Deploy a Gatsby application
    • Create a new web application
      • Create a Django application
      • Create a django CMS application
      • Create a Gatsby application
    • Building your Docker application
      • Manage a project's base image
      • Install system packages
    • Platform-specific guides
      • Install Python dependencies
      • Create a multi-site Django project using Mirrors
      • Go-live checklist for Django projects
      • Add a Django application to an Aldryn project
      • Configure Django settings using Aldryn
      • Configure external logging
      • Configure Celery
      • Manage access authentication
      • Manage redirects in Django projects
      • Log in to a local Django project
      • Manage uWSGI configuration
      • Fine-tune uWSGI server performance
      • Package an application as an Aldryn addon
      • Update an existing Aldryn addon
      • Force HTTPS with Express.js
    • Managing a project’s resources
      • Interact with your project’s database
      • Interact with your project’s cloud media storage
      • Manage environment variables
    • Adding new functionality to a project
      • Set up Sass CSS compilation
      • Configure Application Performance Monitoring
      • Configure media serving on a custom domain
    • Development workflow
      • Configure external Git hosting
      • Use Git to manage your project
      • Set up CI/CD
      • Use the Divio API
    • Troubleshooting
      • Debug cloud deployment problems
      • Diagnose performance issues
      • Identify and resolve a Python dependency conflict
      • Get help when you have a problem
  • Technical reference
    • Divio software components
      • Divio CLI
      • Divio API reference
      • The cloud and local shells
      • Divio environment variables
    • Divio infrastructure
      • Checks, limits and timeouts on the Divio platform
    • Docker commands and configuration
      • Docker commands
      • The Dockerfile
      • The docker-compose.yml file
    • Python/Django application configuration
      • The settings.py file
    • Coding in Divio applications
      • Working with your project’s media storage
      • Working with your project’s database
      • File compression
      • Sending email
    • Addons
      • Addon configuration with aldryn_config.py
      • Aldryn Django (core Django)
      • Aldryn SSO (authentication)
      • Aldryn Addons (addon integration)
    • Quick reference
      • Local commands cheatsheet
  • Background information
    • Cloud management
      • Environments
      • Metrics (Beta)
      • Service management (Beta)
      • Release commands (Beta)
    • Our infrastructure
      • Overview
      • Docker basics
      • IP addresses
      • Cron jobs
      • Maintenance operations
      • Our Python wheels proxy
      • Elasticsearch instances
    • How it works on Divio
      • HTTP redirects
      • Caching and CDN
      • Configuration using environment variables
    • Projects
      • Project creation options
      • The deployment process
      • Anatomy of a Divio project
      • Project environments
      • Version control
      • Boilerplates
      • Multi-site projects on Divio
    • Recommended project configurations
      • Working with our recommended Django project configuration
    • Aldryn Django and addons
      • What is Aldryn, and why use it?
      • Anatomy of a Divio addon
      • How settings are handled in Django addons
      • Django addons and templates
      • Django addons list
  • Docs  » 
  • Background information  » 
  • Working with our recommended Django project configuration

Working with our recommended Django project configuration¶

Our recommended Django project configuration is described in:

  • How to deploy a Django application on Divio

  • How to deploy a Django application with our quickstart repository

  • How to deploy a django CMS application with our quickstart repository

The Twelve-factor model adopted for these projects places all configuration in environment variables, so that the project can readily be moved to another host or platform, or set up locally for development. The configuration for:

  • security

  • database

  • media

  • static files

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.

Application container¶

In both local and cloud environments, the application will run in a web container, using the same image and exactly the same codebase.

Django server¶

In cloud environments: the Dockerfile contains a CMD that starts up Django using the production application gateway server.

In the local environment: the command line in docker-compose.yml starts up Django using the runserver, overriding the CMD in the Dockerfile. If the command line is commented out, docker-compose up will use the application gateway server locally instead.

Database¶

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.

Security settings¶

Debug mode¶

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.

Secret key¶

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 settings.py.

Allowed hosts¶

In cloud environments: DOMAIN and 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 .env-local.

Static files¶

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.

Media files¶

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 cloud environment’s DEFAULT_STORAGE_DSN is applied in the .env-local file, the local server will use the S3 instance instead.

Database migrations¶

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.

Copyright © 2017-2021, Divio. Revision 44a13e89. Edit on GitHub
In this page
  • Working with our recommended Django project configuration
    • Application container
    • Django server
    • Database
    • Security settings
      • Debug mode
      • Secret key
      • Allowed hosts
    • Static files
    • Media files
    • Database migrations