What is Wagtail and who runs it?
Wagtail is an open source CMS built on Django, maintained by the Torchbox team and a wide contributor community. It is free of licence fees. Its editor interface is the reason people pick it: pages are Django models, and StreamField lets editors assemble a page from typed blocks that developers define in Python. As of October 2026 the project’s homepage features the Wagtail 8.0 release.
It works as a conventional CMS that renders templates, and as a headless one through its built-in API, which sits on Django REST Framework.
How does the Wagtail API work?
Add the API app, register endpoints for pages, images and documents, and choose which fields each page model exposes. Pages are then served at /api/v2/pages/, with filtering by page type and pagination. Rich text can come back as stored markup or as display-ready HTML. Access control uses standard DRF authentication, so a token-protected API is a configuration choice, not a rewrite.
The API returns what you list explicitly. That keeps responses predictable, and it also means every new block needs a serializer decision.
Who Wagtail suits
It suits organizations with Python and Django skills that need a large, structured, editor-friendly site: universities, health bodies, public institutions, media groups and corporate sites with many contributors. It handles permissions per page tree, drafts, moderation, scheduled publishing, redirects and multilingual structures well.
It is a weaker fit for a team with no Python, a five page brochure site, or one that wants a hosted service with a vendor SLA. You host Wagtail yourself.
When we would pick something else
- A JavaScript team that wants one language end to end: Payload or Strapi.
- A Laravel shop: Statamic.
- Managed SaaS with no servers to run: Contentful.
- An older Django project that wants only a lightweight page tree: django CMS.
See how it ranks in our list of open source headless CMS platforms.
What we build with Wagtail
- A block library that matches the design system, with validation so editors cannot publish a broken page.
- The API plus a Next.js frontend, with a preview flow so editors see unpublished changes.
- Groups, permissions per section, moderation steps and scheduled publishing.
- Locale trees, translation workflows and hreflang handled in the model.
- Search backends, forms, SSO and downstream systems through Django.
- Content imported from WordPress, Drupal or a custom system, with the page tree and redirects mapped. See our Drupal migration service for how we plan those moves.
How a Wagtail project runs
We map the page tree with editors first: which sections exist, who owns each, and which pages repeat. That tree drives page models, permissions and URL patterns. Block design follows from the design system, with each StreamField block reviewed for editor clarity and for the shape it returns through the API.
We then build against a staging database loaded with real content, test search, translations and redirects, and run Django and Python upgrade checks so the site stays on supported versions. Handover includes a short guide for editors and one for the engineers who maintain it.
Operating Wagtail well
Most trouble on Wagtail sites comes from slow page trees with many children, unindexed queries in templates and unreviewed upgrades. We set query budgets, add caching where editors do not notice it, and schedule upgrades with the release notes and deprecation warnings read in advance.
To add a Django engineer who knows the CMS, see how to hire a Wagtail developer. The wider comparison is on our headless CMS hub.
