Wagtail is straightforward to deploy on modern Linux-based distributions, and should run with any of the combinations detailed in Django's deployment documentation <django:howto/deployment/index>
. See the section on performance </advanced_topics/performance>
for the non-Python services we recommend.
Divio Cloud is a Dockerised cloud hosting platform for Python/Django that allows you to launch and deploy Wagtail projects in minutes. With a free account, you can create a Wagtail project. Choose from a:
- site based on the Wagtail Bakery project, or
- brand new Wagtail project (see the how to get started notes).
Divio Cloud also hosts a live Wagtail Bakery demo (no account required).
PythonAnywhere is a Platform-as-a-Service (PaaS) focused on Python hosting and development. It allows developers to quickly develop, host, and scale applications in a cloud environment. Starting with a free plan they also provide MySQL and PostgreSQL databases as well as very flexible and affordable paid plans, so there's all you need to host a Wagtail site. To get quickly up and running you may use the wagtail-pythonanywhere-quickstart.
We know of Wagtail sites running on Heroku, Digital Ocean and elsewhere. If you have successfully installed Wagtail on your platform or infrastructure, please contribute </contributing/index>
your notes to this documentation!
As with all Django projects, static files are not served by the Django application server in production (i.e. outside of the manage.py runserver
command); these need to be handled separately at the web server level. See Django's documentation on deploying static files <django:howto/static-files/deployment>
.
The JavaScript and CSS files used by the Wagtail admin frequently change between releases of Wagtail - it's important to avoid serving outdated versions of these files due to browser or server-side caching, as this can cause hard-to-diagnose issues. We recommend enabling ~django.contrib.staticfiles.storage.ManifestStaticFilesStorage
in the STATICFILES_STORAGE
setting - this ensures that different versions of files are assigned distinct URLs.
Wagtail follows Django's conventions for managing uploaded files <django:topics/files>
, and can be configured to store uploaded images and documents on a cloud storage service such as Amazon S3; this is done through the DEFAULT_FILE_STORAGE setting in conjunction with an add-on package such as django-storages. Be aware that setting up remote storage will not entirely offload file handling tasks from the application server - some Wagtail functionality requires files to be read back by the application server. In particular, documents are served through a Django view in order to enforce permission checks, and original image files need to be read back whenever a new resized rendition is created.
Note that the django-storages Amazon S3 backends (storages.backends.s3boto.S3BotoStorage
and storages.backends.s3boto3.S3Boto3Storage
) do not correctly handle duplicate filenames in their default configuration. When using these backends, AWS_S3_FILE_OVERWRITE
must be set to False
.
If you are also serving Wagtail's static files from remote storage (using Django's STATICFILES_STORAGE setting), you'll need to ensure that it is configured to serve CORS HTTP headers, as current browsers will reject remotely-hosted font files that lack a valid header. For Amazon S3, refer to the documentation Setting Bucket and Object Access Permissions, or (for the storages.backends.s3boto.S3BotoStorage
backend only) add the following to your Django settings:
AWS_HEADERS = {
'Access-Control-Allow-Origin': '*'
}
For other storage services, refer to your provider's documentation, or the documentation for the Django storage backend library you're using.