Divio Documentation
Contents Menu Expand Light mode Dark mode Auto light/dark mode
Divio Documentation
  • Get started
    • Installation
    • Django
      • 1. Create a new Django application
      • 2. Set up your Divio application locally
      • 3. Deploy your application to the Divio 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 application using Aldryn Django
      • 2. Set up your Divio application locally
      • 3. Make changes and deploy them
      • 4. Configure a more complex application
    • Wagtail
      • 1. Create a new Wagtail Django application
      • 2. Set up your Divio application locally
      • 3. Make changes and deploy them
    • Laravel
      • 1. Create a new PHP/Laravel application
      • 2. Set up your Divio application locally
      • 3. Make changes and deploy them
      • 4. Install an application using Flavours
  • How-to guides
    • Get help and support
    • Update billing and credit card information
    • Retrieve your invoices
    • Upload your SSH public key
    • Enable Beta features
    • Delete your account
    • Rename an organisation
    • Duplicate an application
    • Delete an application
    • Add a collaborator
    • Rename an application
    • Transfer an application to another organisation
    • Use our backup system
    • Clear the Cloudflare cache
    • Configure an application (generic guide)
    • Configure a Django application
    • Configure a Flask application
    • Configure a Gatsby application
    • Start a Django application
    • Start a django CMS application
    • Start a Gatsby application
    • Start a PHP Laravel application
    • Deploy your application to the Divio cloud platform
    • Go-live checklist
    • Set up the Divio local development environment
    • Run a local application in live configuration
    • Configure external Git hosting
    • Use Git to manage your application
    • Set up CI/CD
    • Use the Divio API
    • Manage an application's base image
    • Install system packages
    • Install Python dependencies
    • Create a multi-site Django application using Mirrors
    • Configure Celery
    • Force HTTPS with Express.js
    • Add a Django application to an Aldryn application
    • Configure Django settings using Aldryn
    • Configure external logging
    • Manage access authentication
    • Manage redirects in Django applications
    • Log in to a local Django application
    • Manage uWSGI configuration
    • Fine-tune uWSGI server performance
    • Package an application as an Aldryn addon
    • Update an existing Aldryn addon
    • Interact with your application’s database
    • Interact with your application’s cloud media storage
    • Configure media serving on a custom domain
    • Manage environment variables
    • Upgrade a PostgreSQL service
    • Debug cloud deployment problems
    • Diagnose performance issues
    • Identify and resolve a Python dependency conflict
    • Get help when you have a problem
  • Technical reference
    • Divio CLI
    • Divio API reference
    • The cloud and local shells
    • Divio environment variables
    • Checks, limits and timeouts on the Divio platform
    • The Dockerfile
    • The docker-compose.yml file
    • Working with your application’s media storage
    • Working with your application’s database
    • File compression
    • Sending email
    • Divio application backups
    • Zero-downtime deployment
    • Multi-site applications
    • Mirrors
    • Application development support
    • How we use terms
    • Security
    • Resource usage
    • Leaving Divio
    • The Developer plan
    • Invoice-based billing
    • Divio’s local commands cheatsheet
    • Control panel permissions reference
    • Addon configuration with aldryn_config.py
    • settings.py in Aldryn Django
    • Key addons
  • Background information
    • Environments
    • Metrics (Beta)
    • Domains
    • Service management (Beta)
    • Release commands (Beta)
    • Overview
    • Docker basics
    • IP addresses
    • Cron jobs
    • Maintenance operations
    • Our Python wheels proxy
    • Elasticsearch instances
    • Caching and CDN
    • Configuration using environment variables
    • SSL certificates and HTTPS
    • Application creation options
    • The deployment process
    • Application environments
    • Version control
    • Boilerplates
    • Working with our recommended Django application configuration
    • Why should you pin your Python packages in the requirements.txt file?
    • What is Aldryn?
    • Addons
    • About Aldryn (legacy)
    • Working with Django addons (legacy)
    • Addons list
  v: latest
Versions
latest
Downloads
pdf
On Read the Docs
Project Home
Builds
  • Docs  » 
  • Background information  » 
  • Working with our recommended Django application configuration
Back to top

Working with our recommended Django application configuration#

Our recommended Django application configuration is mentioned in:

  • How to configure an existing Django application for deployment on Divio

  • How to create a Django application with our quickstart repository

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

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:

  • 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.

SECURE_SSL_REDIRECT#

Unless explicitly disabled with a SECURE_SSL_REDIRECT = False environment variable, Django’s SECURE_SSL_REDIRECT will apply.

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.

Next
Why should you pin your Python packages in the requirements.txt file?
Previous
Boilerplates
Copyright © 2023 Divio Technologies AB
On this page
  • Working with our recommended Django application configuration
    • Application container
    • Django server
    • Database
    • Security settings
      • Debug mode
      • Secret key
      • Allowed hosts
      • SECURE_SSL_REDIRECT
    • Static files
    • Media files
    • Database migrations