Mozilla Bedrock: the Django and Webpack codebase behind mozilla.org

Bedrock's role in the mozilla.org publishing stack

Bedrock is the code name and repository for mozilla.org. Its stated purpose is making mozilla.org open source and allowing contributions through GitHub. The intended users are engineers and contributors who need to modify the site, including people looking for a first bug through Mozilla's contributing documentation. This is not presented as a reusable website framework or a package intended for installation by unrelated applications.

The repository's top-level structure makes that scope visible. Directories such as `bedrock/`, `pages/` implied by the Ruff configuration, `media/`, `l10n/`, `locale/`, `root_files/`, `wsgi/`, `data/`, and `profiling/` indicate a full site application rather than a small frontend component. The presence of localization directories is particularly relevant for a multilingual public website. The README links to project-specific documentation at Mozilla's documentation site, while general Django behavior is expected to be understood through the Django documentation.

That distinction matters for adoption. A team that wants a blank Django project can start from a general Django project. A team that wants to contribute a change to mozilla.org needs Mozilla's application conventions, content files, templates, localization setup, and deployment assumptions. Bedrock's value comes from those site-specific conventions, not from being a minimal starting point.

Django application structure and request handling

The README identifies Bedrock as a Django project, and the repository includes `manage.py`, `wsgi/`, a `bedrock/` package, tests, and Python configuration. `pyproject.toml` configures Ruff for Python 3.13, with Django-specific lint rules through the `DJ` selector and import ordering that recognizes `bedrock`, `lib`, and `pages` as first-party packages. These details indicate that Python application code is managed as part of a conventional Django codebase rather than as a collection of standalone scripts.

The Docker Compose description is more specific about runtime topology. Its `app` service runs `python manage.py runserver 0.0.0.0:8080`. The `assets` service runs `npm run watch`, and its comment says this service is the primary server because it proxies the Django app while Webpack watches for file changes. The Compose file also defines Postgres, Redis, and a worker service. This indicates that local page serving, asset compilation, database access, caching or queueing infrastructure, and background work are separate concerns in the development environment.

The repository's Dockerfile reinforces the split. It defines a Python dependency builder using `python:3.13-slim-bookworm`, an assets builder using `node:24-slim`, and an application container. The application image installs Python dependencies and copies the Django application, scripts, WSGI files, media, and supporting configuration. The visible architecture is therefore a multi-stage build with compiled frontend assets and a Django service, not a simple HTML directory served by a static file host.

Webpack asset compilation and JavaScript dependencies

Bedrock's frontend build is managed through npm and Webpack. `package.json` declares `private: true`, version `0.1.0`, and a dependency list that includes Babel, Sass, Webpack, Sentry's browser package, and several `@mozmeao` packages for consent, cookies, Do Not Track, and traffic control. The dependency names show that browser behavior is part of the site's implementation, while the build toolchain handles modules, stylesheets, minification, and development serving.

The asset builder in the Dockerfile copies `package.json` and `package-lock.json`, runs `npm ci --verbose`, copies frontend configuration and media, then runs `npm run build --verbose`. This is a deterministic dependency installation based on the lockfile rather than a loose update of package versions. The Compose `assets` service uses the resulting asset environment to run `npm run watch` during development.

The `webpack.config.js`, `webpack.static.config.js`, and `webpack.test.config.js` files show that the repository distinguishes several build contexts. The `scripts` section also includes `start`, which runs Django and the frontend watcher concurrently. Bedrock consequently requires contributors to understand both sides of the build. A change to a Django template can still depend on asset compilation, and a JavaScript or Sass change is not merely a source edit; it passes through project-specific Webpack configuration and quality tooling.

Local Docker Compose development for a first page

The repository provides Docker Compose files for a multi-service development environment, but the README does not give a complete installation tutorial. The commands below are taken directly from `docker-compose.yml` and describe the services and commands used by that setup. Before using them, a developer still needs the repository's documented environment files, especially `docker/envfiles/local.env` and `.env`, because the Compose configuration references both.

The app service starts Django on port 8080:

python manage.py runserver 0.0.0.0:8080

The assets service runs the frontend watcher:

npm run watch

The Compose file maps the app to host port 8080, maps the asset service across ports 8000 to 8010, and exposes Postgres on port 5432. Redis has no host port mapping in the shown configuration. The expected local result is a Django development server plus a Webpack development service, with project code mounted from the host into the containers. The repository comments state that the assets service proxies the Django app, so developers should consult the complete Compose setup and its documentation for the exact browser entry point.

The package script offers a local alternative for a prepared environment:

npm start

That script runs `python manage.py runserver 0.0.0.0:8080` and `npm run watch` concurrently. It is useful once dependencies, environment variables, and supporting services are already available. The README does not claim that this single command provisions Postgres, Redis, or the worker.

Testing, linting, and production release maintenance

The repository contains `tests/`, `.coveragerc`, `codecov.yml`, `eslint.config.js`, `.stylelintrc`, `.prettierrc.json`, `.pre-commit-config.yaml`, and `setup.cfg`. These files indicate separate Python and frontend quality workflows. The package scripts include `lint-js` and `lint-css`, while the Python configuration enables Ruff checks for Django rules, style, imports, and quoting. The presence of test runners such as `jasmine-browser-runner`, `jasmine-core`, and `sinon` in `package.json` also points to browser-side unit testing support.

Maintenance is current according to the repository facts. It is not archived, and its last push was on 2026-10-15. The listed production releases include 2026-10-13, 2026-10-08.2, and 2026-10-08.1. These dates indicate a project with recent production changes, although the README does not describe a release policy or guarantee compatibility for external adopters.

The MPL-2.0 license applies to the software. That matters for contributors and organizations reviewing reuse, but this article does not provide legal advice. The repository's `LICENSE`, contribution documentation, and any Mozilla-specific licensing procedures should be reviewed before copying code into another product.

Where Bedrock is the wrong choice

Bedrock is a poor fit for a small static site, a single-page JavaScript application, or a generic Django service that should start from a minimal template. Its dependency and service layout assumes a substantial publishing system. The Compose file includes Postgres, Redis, a worker, localization directories, Webpack, and multiple Docker build stages. A team that needs only a few HTML pages would carry operational and maintenance work that the README does not justify.

It is also not a drop-in library. `package.json` marks the npm package as private, and the repository is organized around mozilla.org. There is no documented public API in the README for embedding Bedrock in another product. The actual alternative is therefore architectural: use a generic Django project or a static site generator when the requirement is a small independent site, and use Bedrock when the requirement is to work inside Mozilla's mozilla.org codebase.

Editorial conclusion

Bedrock is a sensible adoption target for engineers contributing to mozilla.org or studying a large Django site with Webpack assets. It is a poor fit as a generic Django starter because the npm package is private and the codebase is mozilla.org-specific, and organized around production services. Verify the local environment, database and worker requirements, asset workflow, and MPL-2.0 implications before changing it.

Frequently asked questions

Official sources

1. License: MPL-2.0
2. mozilla/bedrock on GitHub
3. Project website
4. README
5. Releases