Creating a Project Structure for Wagtail + Django

November 29, 2025 Β· 3 min read

Overview of the backend layout and best practices.

Creating a Project Structure for Wagtail + Django

🧱 Backend Project Structure

This document provides an overview of the backend directory structure for the Django + Wagtail project.


πŸ“ Project Layout

backend/
β”‚
β”œβ”€β”€ Dockerfile                          # Docker build instructions for production/deployment
β”œβ”€β”€ manage.py                           # Django CLI: runserver, migrate, createsuperuser, etc.
β”œβ”€β”€ home/                               # Main Wagtail page app
β”‚   β”œβ”€β”€ __init__.py                     # Marks module as a Python package
β”‚   β”œβ”€β”€ apps.py                         # Django AppConfig for "home"
β”‚   β”œβ”€β”€ models.py                       # Wagtail Page models (HomePage, blocks, etc.)
β”‚   β”œβ”€β”€ templates/                      # Templates owned by this app
β”‚   β”‚   └── home_page.html              # Template for HomePage (if not fully headless)
β”‚   β”œβ”€β”€ static/                         # App-specific static assets
β”‚   β”‚   └── css/                        # CSS files for the home app
β”‚   β”œβ”€β”€ migrations/                     # Database schema history for this app
β”‚   β”‚   └── 0001_initial.py             # Initial migration generated by Wagtail scaffold
β”‚   β”‚   └── 0002_create_homepage.py     # Migration generated by for homepage creation
β”‚   └── tests.py                        # Unit tests for the home app
β”œβ”€β”€ search/                             # Simple search app (no models)
β”‚   β”œβ”€β”€ __init__.py                     # Marks module as a Python package
β”‚   β”œβ”€β”€ views.py                        # Search view using Wagtail search backend
β”‚   └── templates/                      # Templates for search results
β”‚       └── results.html                # Template that displays search results
β”‚   # NOTE: no migrations because search has no models
β”‚   # NOTE: no apps.py β€” Django uses default AppConfig
β”‚   # NOTE: no static/ β€” search app contains no assets
β”‚
β”œβ”€β”€ mysite/                             # Core Django project configuration
β”‚   β”œβ”€β”€ __init__.py                     # Marks project module as a Python package
β”‚   β”œβ”€β”€ settings/                       # Modular Django + Wagtail settings
β”‚   β”‚   β”œβ”€β”€ __init__.py                 # Makes settings importable
β”‚   β”‚   β”œβ”€β”€ base.py                     # Shared settings for all environments
β”‚   β”‚   β”œβ”€β”€ dev.py                      # DEBUG, local DB, dev middleware, etc.
β”‚   β”‚   └── production.py               # Security, caching, production toggles
β”‚   β”œβ”€β”€ urls.py                         # Root URL routing (wagtail admin, API, home routes)
β”‚   β”œβ”€β”€ wsgi.py                         # WSGI entrypoint for Gunicorn/apache
β”‚   β”œβ”€β”€ asgi.py                         # ASGI entrypoint for Uvicorn/Daphne (async support)
β”‚   β”œβ”€β”€ static/                         # Project-wide static files (logos, overrides, etc.)
β”‚   └── templates/                      # Global templates (layout, shared UI)
β”‚       └── base.html                   # Main template inherited by others (if not headless)
β”œβ”€β”€ requirements.txt                    # Python dependencies for pip instalL
└── venv/                               # Optional: local virtual environment

πŸ“˜ Overview

This structure follows typical Django best practices, including:

  • Each app (e.g., home/, search/) is isolated with its own templates and migrations.
  • The mysite/ folder contains global project config (settings, URLs, WSGI/ASGI).
  • Dockerfile makes the backend ready for containerized deployments.
  • A dedicated static/ and templates/ folder is included for project-wide front‑end assets.

πŸ“„ Requirements

Install dependencies:

pip install -r requirements.txt

▢️ Running the Project

Start the development server:

python manage.py runserver

πŸ§ͺ Running Tests

python manage.py test