How I Set Up Wagtail's Bakerydemo Locally (And What I Learned Along the Way)

Kamala Kiruthi — Thu, 19 Mar 2026 09:26:57 +0000

By M. Kamala Kiruthi — B.Tech CSE with Applied AI, St. Joseph University

I am a first-year engineering student preparing for Google Summer of Code 2026 with the Wagtail organisation. Before writing a single line of proposal, I wanted to actually use Wagtail — not just read about it. So I cloned the bakerydemo repository and set it up on my local machine. This post is a honest walkthrough of what I did, what broke, and what I learned.

What is the Bakerydemo?
The Wagtail bakerydemo is an official demo project built with Wagtail CMS. It simulates a real bakery website — complete with blog posts, bread recipes, gallery pages, and a location finder. It is the go-to project for:

Developers evaluating Wagtail for the first time
Contributors wanting to understand how a real Wagtail project is structured
GSoC/Outreachy applicants (like me!) getting hands-on experience

Step 1 — Cloning the Repository
The first thing I did was clone the repo:
bashgit clone https://github.com/wagtail/bakerydemo.git
cd bakerydemo
Simple enough. The repository is well-organised — you can immediately see the Django app structure with separate folders for blog, breads, gallery, search, and base.

Step 2 — Setting Up a Virtual Environment
I chose to set up without Docker (just Python + venv) to understand the project without extra layers of abstraction.
bashpython -m venv venv
source venv/bin/activate # On Windows: venv\Scripts\activate
pip install -r requirements/dev.txt
This installs all dependencies including Wagtail itself, Django, Pillow (for image handling), and various dev tools. It took a couple of minutes but worked smoothly.

Step 3 — Setting Up the Database
The bakerydemo uses SQLite by default in development, which means zero database configuration. I just ran:
bashpython manage.py migrate
This created all the tables — including Wagtail's own tables for pages, images, documents, and the revision history system. Seeing the migration output was actually a great introduction to how many moving parts Wagtail manages under the hood.

Step 4 — Loading Demo Data
This is where it got interesting. The project ships with fixtures — pre-made JSON files that populate the database with sample content so you are not staring at an empty site.
bashpython manage.py load_initial_data
This single command loaded the homepage, blog posts, bread pages, gallery images, and navigation — everything the demo needs to look like a real site.
What I learned here: Wagtail fixtures are not just Django model data dumps. They include Wagtail-specific structures like StreamField content (which stores rich, flexible page content as JSON blocks), image references, and page tree relationships. Understanding this was a light-bulb moment — it showed me how powerful and flexible Wagtail's content model really is.

Step 5 — Running the Development Server
bashpython manage.py runserver
And just like that — a fully working bakery website running at http://127.0.0.1:8000. 🎉
I spent a good amount of time clicking around both the front-end site and the Wagtail admin (/admin). A few things that stood out immediately:

The page tree — Wagtail organises all content as a tree of pages. Every page has a parent. This is fundamentally different from Django's flat model approach and it clicked for me very quickly once I saw it visually in the admin.
StreamField in action — Editing a bread page in the admin showed me how StreamField works: you can add, remove, and reorder blocks (text, images, quotes, etc.) in any order. It felt like building with LEGO bricks.
Image management — Wagtail has its own image library with automatic renditions (resizing/cropping on demand). No more manually managing image sizes.

What Surprised Me
The admin is genuinely beautiful. I expected a basic Django admin panel. Instead, Wagtail has a polished, modern admin interface that feels like a real product — not an afterthought.
Page models are just Django models. Once I opened bakerydemo/breads/models.py, I realised Wagtail page types are just Django models that extend wagtail.models.Page. All the familiar Django patterns — fields, methods, querysets — still apply. Wagtail layers CMS features on top without replacing what Django already does well.
The fixture system is where the magic (and complexity) lives. Loading real content into a demo site requires carefully constructed fixtures that respect Wagtail's page tree, slug uniqueness, and StreamField structure. This is an area I want to contribute to as part of GSoC 2026.

What's Next for Me
Setting up the bakerydemo was my first real step into Wagtail's world. I am now preparing a GSoC 2026 proposal to work on the Demo Website Redesign project — adding new content fixtures for a second vertical theme (beyond bread!) and improving the demo's visual design.
If you are also exploring Wagtail for the first time, I highly recommend starting with the bakerydemo. It is the fastest way to go from zero to understanding how a production Wagtail project is structured.

Thanks for reading! I am @kamalakiruthi8 on GitHub. Feel free to connect if you are also preparing for GSoC 2026 with Wagtail.

DEV Community: Kamala Kiruthi

How I Set Up Wagtail's Bakerydemo Locally (And What I Learned Along the Way)