Check your subscription plan¶
In the Control Panel, check the project’s Subscription, and that it includes the technical and support resources it will require once the site is live.
Pin all dependencies in the project, so that future deployments do not introduce unexpected software updates.
Python applications: see pinning all dependencies in Python applications.
Turn off development mode¶
Many frameworks include a development mode that exposes additional information. This should not go into production.
Django applications: this is handled by the
DEBUGsetting. When using our recommended Django project configurations, this will be handled correctly automatically.
If you are using existing domains, prepare them for the switch. Ensure that they have low (less than 60 seconds) TTLs. High TTLs can cause problems when the domains are pointed at the new site, including delays in the automatic provisioning of SSL certificates.
Check that the live domain for the server is set up for the site in the Control Panel.
Check that any domains that should redirect to the primary domain are also set in the Domains setting in the Control Panel.
Set your application to redirect to HTTPS.
Django: Django projects using our recommended configuration, will be apply redirects to HTTPS by default.
Legacy Aldryn projects: enable redirects to HTTPS by setting the SECURE_SSL_REDIRECT environment variable to
Check that any other environment variables required on the Live environment have been set (see: Environment variables).
File serving configuration¶
Check the configuration of static file serving. Files should be appropriately collected, compressed and so on. Hashing static filenames lets you take advantage of caching.
Legacy Aldryn projects: we recommend using the Hash static filenames option.
Check your project’s configuration for any settings that may have been temporarily configured during development.
In the local environment, run the application in a configuration that is as close as possible to the production
configuration. For example, our recommended Docker Compose configurations use development servers for convenience; you
can comment out the
command entry in the
docker-compose.yml file and allow the application to use the
CMD instead, which will use a production server.
See How to run a local application in live configuration for more.
If required, copy database and media content to the Live environment.
Run a deployment of the Live environment.
Check your site as a logged-in user, an anonymous user and in your browser’s private/incognito mode to verify expected behaviour.
Check response times with a tool such Pingdom.
If necessary, allocate more resources to the project via its Subscription and consult the How to fine-tune your server’s performance guide.