Wagtail Production Checklist

Problem statement

Wagtail sites are Django sites with extra moving parts: editors uploading large images, renditions generated on demand, a search index, page trees across one or more Sites, scheduled publishing, and frontend caches that must be purged when editors publish. Generic Django checklists miss these, and they are exactly where Wagtail sites break after launch: preview links pointing at localhost, slow first page views while renditions generate, stale cached pages after publishing, and lost images after a redeploy.

1. Set WAGTAILADMIN_BASE_URL and configure each Site's hostname and port in the admin.
2. Store original images and renditions in persistent storage (object storage in containers); pre-generate common renditions.
3. Use a production search backend (PostgreSQL full-text via the database backend, or Elasticsearch/OpenSearch) and rebuild the index on deploy when models change.
4. Configure frontend cache invalidation (Cloudflare, CloudFront, or Varnish) so publishing purges cached pages.
5. Protect the Wagtail admin (2FA, named accounts, ideally not public) and review group permissions.
6. Run publish_scheduled regularly, back up media with the database, and keep Wagtail upgrades routine.

Checklist

Sites and URLs

• WAGTAILADMIN_BASE_URL = "https://example.com" so emails and preview links use the right host.
• Each Site in Settings → Sites has the correct hostname, port (443 behind HTTPS), and root page.
• ALLOWED_HOSTS and CSRF_TRUSTED_ORIGINS include every Site's hostname.
• Redirects app (wagtail.contrib.redirects) used for moved pages.

Images and documents

• Media storage is persistent: object storage (django-storages) in containers and PaaS, or a backed-up volume.
• Renditions use the same storage; consider pre-generating common sizes after upload to avoid slow first views.
• WAGTAILIMAGES_MAX_UPLOAD_SIZE and image pixel limits set; WebP/AVIF output where supported ({% image ... format-webp %}).
• Document serving method chosen (WAGTAILDOCS_SERVE_METHOD) for private documents with permission checks.

Search

• WAGTAILSEARCH_BACKENDS uses the database backend (PostgreSQL full-text) or Elasticsearch/OpenSearch.
• python manage.py update_index runs after deploys that change indexed fields, and periodically if needed.
• Search queries logged or analysed via wagtail.contrib.search_promotions if editors manage promoted results.

Caching and performance

• Frontend cache invalidation configured (wagtail.contrib.frontend_cache) for your CDN or proxy.
• Cache-Control headers set for public pages; logged-in editors bypass the cache.
• Template fragment caching for menus and footers, invalidated on publish (via signals).
• Database queries in page templates reviewed (prefetch related images and snippets).

Admin and editorial

• Wagtail admin protected with 2FA (for example wagtail-2fa or django-otp) and not exposed more than needed.
• Groups and page permissions reviewed; no shared editor accounts.
• python manage.py publish_scheduled runs every few minutes (timer, Beat, or CronJob) with a heartbeat.
• Workflow and moderation emails tested with the production email backend.

Backups and upgrades

• Database and media (originals; renditions can be regenerated) backed up and restore-tested.
• Wagtail and Django upgraded on a schedule, reading release notes for migration changes.

Explanation

Wagtail builds a content management layer on Django: a page tree mapped to Sites, an image library with on-demand renditions, search integration, and editorial workflows. Each piece has production settings beyond Django's own. URLs depend on Site records and the admin base URL; images and renditions need persistent, shared storage; search needs a real backend and an up-to-date index; caches must be invalidated when content changes; and scheduled publishing needs a periodic job. Verifying these turns a working Wagtail install into a reliable publishing platform.

Edge cases / notes

• Multi-site installs need each hostname on the certificate and in ALLOWED_HOSTS.
• Headless Wagtail (API plus a separate frontend) needs CORS and cache purging on the frontend too.
• Large image libraries benefit from an image CDN for resizing instead of generating many renditions.
• wagtail-localize or wagtail.contrib.simple_translation add translation workflows to plan for.

Next steps

• Deploy it with Deploy Wagtail to Production.
• Optimise images with Serve Optimised Images and Thumbnails From Django.

FAQ

What is WAGTAILADMIN_BASE_URL used for?

Building links in admin notifications and emails; set it to your public HTTPS URL.

Why do Wagtail images disappear after redeploying?

They were stored on the container's ephemeral disk. Use object storage or a persistent volume.

Which search backend should Wagtail use in production?

The database backend with PostgreSQL for most sites; Elasticsearch or OpenSearch for large or advanced search needs.

How do I publish scheduled pages in Wagtail?

Run python manage.py publish_scheduled every few minutes with a scheduler.