ietf-tools/datatracker: the Django application behind datatracker.ietf.org

The front end to the IETF database

The datatracker is described as the day to day front end to the IETF database, for people who work on IETF standards, and the production site is datatracker.ietf.org. It is the place where Internet-Drafts, working groups, document streams, meetings and individual requests are tracked, and it is the tool that a contributor or a working group chair uses every week.

Technically it is a Django application, with the repository structured as a standard Django project, an `ietf/` package for the application code, alongside `client/`, `dev/`, `docker/`, `k8s/`, `patch/`, `playwright/`, `test/` and `bin/` directories and the usual configuration files. The requirements list pins the stack explicitly, with a badge for Python 3.12, Django 4.x, Node.js 26.x and PostgreSQL 17, and the `requirements.txt` constrains Django to `>=4.2.30,<5`.

The licence is BSD-3-Clause, which is worth noting for a project of this kind, since the code is public and the deployed service is a public good.

The versioning is unusually fine grained for a web application, with releases 12.79.1 on 2026-10-02, 12.79.2 on 2026-10-06 and 12.80.0 on 2026-10-09, and the last push to the repository on 2026-10-15. A project that ships a release every few days is a project that is deployed continuously, and that tells you how to read the rest of it.

Docker is the supported path, and the native path is a warning

The README is unusually direct about setup, and the reason is given in one sentence. Datatracker development is performed using Docker containers, a purely native install is possible but is described as very complicated, and it typically takes a first time datatracker developer a full day of setup, where the Docker setup completes in a small number of minutes.

There are two ways in. Many developers use VS Code and its ability to start a project in a set of containers, in which case you start VS Code in your clone and choose Restart in container. Without VS Code, the instruction is to go into the clone and run:

cd docker; ./run

The clone itself has its own advice, because the history is extensive and a full clone is slow and large. Limiting the depth is the fix:

git clone --depth=10 https://github.com/USERNAME/datatracker.git

and for a specific point in time, `--shallow-since=DATE`. Windows developers are pointed at WSL2 from the beginning.

The `docker-compose.yml` in the repository shows what the environment is made of. There is an `app` service built from `docker/app.Dockerfile` whose command is `sleep infinity` so the container does not shut down when the process ends, and which depends on `blobdb`, `blobstore`, `db` and `mq`. The `db` service is the prebuilt database image, `ghcr.io/ietf-tools/datatracker-db:latest`, with a named volume for the PostgreSQL data directory, and there is a `pgadmin` service for browsing the database with a development login.

The test command, and the SQLite era that ended

Once the containers are up, the check that your checkout is sound is a single command in the app container's shell:

ietf/manage.py test --settings=settings_test

The README says all tests should pass, and if any fail, to ask for help at the tools-help address.

The note that follows is a small history lesson. The project recently moved the datatracker onto PostgreSQL, so older documentation suggesting testing with `settings_sqlitetest` will no longer work. That is a sentence worth reading twice if you are following any guide written before the move, and it is a good example of a project documenting its own migration rather than leaving the stale instructions in place.

The testing surface is wider than the Django tests. The table of contents lists running tests under three headings, Python tests, frontend tests and a diff tool, and the repository has a `playwright/` directory and a `test/` directory at the top level. The `package.json` has a `preview` script that builds with the test mode, `vite build --mode test && vite preview --mode test`, which is the shape a frontend test environment usually takes in a Vite project.

For contributors, the process is the standard Git Feature Workflow with a fork first, then a pull request, with bug reports and feature requests raised in the discussions area and accepted tickets converted into issues. There is also a note that some GitHub Actions may be enabled by default in a fork and should be disabled in the Actions settings.

The database arrives as an image, the blobs as minio

Two pieces of local infrastructure have their own story, and both are unusual.

The database comes prebuilt. Nightly database dumps of the datatracker are available as Docker images, `ghcr.io/ietf-tools/datatracker-db:latest`, so a developer does not have to build a schema or load a data set, they pull an image that already contains the production shape of the data. To bring a development database up to the latest version, the documentation says to run the `docker/cleandb` script.

That approach has an obvious advantage for a project with a database this shaped, since the migrations alone would take a new contributor hours to run, and the data is the interesting part when you are working on a feature that involves documents and meetings. The cost is that the data is a snapshot, and a developer has to know the image is the source of truth rather than the migrations.

Blob storage is handled by minio in the dev and test environments, providing local blob storage, with the settings files describing how the app container talks to the blobstore container. If you need to reach minio from outside the containers, you use `docker compose` from the top level directory of the clone to expose it at an ephemeral port:

$ docker compose port blobstore 9001
0.0.0.0:<some ephemeral port>

$ curl -I http://localhost:<some ephemeral port>
HTTP/1.1 200 OK

Minio speaking the S3 API is a good choice, since the production requirements include `boto3` and `django-storages`, so the application code path is the same in development and in production.

A front end mid-migration: Vite and Vue 3, plus Parcel and jQuery

The front end is where the datatracker is most visibly a project in progress, and the `package.json` scripts show both stacks running side by side.

"dev": "vite",
"build": "vite build",
"preview": "vite build --mode test && vite preview --mode test",
"legacy:dev": "parcel",
"legacy:build": "parcel build"

The current stack is Vite with Vue 3, with `vue-router` and `pinia` for state, `naive-ui` for components and `bootstrap` 5.3.8 also present, and the legacy stack is Parcel with jQuery 3.7.1. The README's front end section documents both, with the Parcel part explicitly labelled legacy, and the `legacy:` prefix on the scripts is the mechanism that keeps them apart while the migration proceeds.

The feature set of the front end is broad, which is a good proxy for what the application does. There is FullCalendar including an iCalendar bridge and a Luxon time grid, Chart.js with an autocolour plugin and a zoom plugin, Highcharts, d3, lodash, moment and Luxon for time handling, sortablejs for drag and drop, select2 with a Bootstrap 5 theme for the classic selects, shepherd.js for guided tours, browser-fs-access for file system access in the browser, ical.js, and zxcvbn for password strength estimation.

The other front end topics in the table of contents are operational rather than technical: serving static files via a CDN, handling of external JavaScript and CSS components, handling of internal static files, changes to template files, and deployment. A public site that serves third party scripts has to decide what it trusts, and those headings are where that policy is written down.

The dependency list is a map of the application

Reading `requirements.txt` tells you what the datatracker does more quickly than any feature list could.

It is a Django 4 application with the Django REST Framework and django-tastypie, which means it exposes a REST API as well as serving server rendered pages, and drf-spectacular for OpenAPI schema generation with drf-standardized-errors for a consistent error format. Authentication runs through `django-oidc-provider`, pinned to exactly 0.8.2 with the comment that 0.8.3 changes the logout flow and claim return, which is a precise example of a dependency held back for a behavioural reason rather than a security one.

Asynchronous work runs on Celery, with django-celery-beat for periodic tasks and django-celery-results, and the compose file has a `mq` service for the broker. `django-simple-history` records model history, which for a document tracking system is how the record of who changed a draft's state is kept. `django-storages` with `boto3` handles the S3 backed blob storage, and `django-csp` and `django-cors-headers` are the content security policy and CORS configuration.

There are a few pins with notes. `bleach` is marked as deprecated but still supported. `defusedxml` is there for TastyPie when using XML, with a note that it is not a declared dependency. `cryptography` is for the account migration password envelope. `html2text` is used only to clean the comment field of the secretariat and specification requests.

And `django-vite` plus the Vite integration is the Django side of the front end migration, with `django-widget-tweaks` and `django-markup` for template rendering. The `vzic/` and `svn-history/` directories at the top level hint at the older parts of the IETF infrastructure that the project still carries.

Where this is the wrong project

The first wrong case is treating it as a reusable document management system. The data model is the IETF's own, with drafts, working groups, sessions, streams and requests, and the workflows encoded in the application are the ones the IETF runs. A team that wants a generic document tracker will find that the interesting code is inseparable from the domain, and that the frontend, the templates and the JavaScript are all part of the same application rather than a library you can install.

The second wrong case is expecting a package. The repository is a Django project, not a distributed library, and there is no `pip install datatracker` in the ordinary sense. The deployment story is a container, a Kubernetes directory, and a nightly database image.

The third is the operational weight. The README says it plainly, that a native install takes a first time developer a full day and the Docker setup takes minutes, and that means you need Docker, a database image, a blob store, a message queue and a front end toolchain before you can run a single test. For a project whose purpose is standards work, that is a fair trade. For a smaller team with a simpler tracking problem, it is a lot of machinery.

The fourth is the migration state. With a Vue 3 and Vite front end running next to a legacy Parcel and jQuery one, a contributor has to work out which half they are touching before they start, and the code they read may be scheduled to change. The `patch/` and `dev/` directories in the tree suggest a workflow for that, but the ambiguity is real.

Editorial conclusion

Adopt the datatracker source if you work on IETF standards tooling, want to run a private instance of the document and meeting tracker, or want to read a well run Django and Vue 3 project that a large standards body depends on every day. Do not adopt it as a general purpose document management system, since its data model is the IETF's own workflow of drafts, working groups, sessions and documents, and the Django project is not packaged as a reusable library. Verify first that you can run the Docker development environment, because the README says a native install typically takes a first time developer a full day, and that your PostgreSQL setup matches, since the project has moved off SQLite and the older `settings_sqlitetest` no longer works.

Frequently asked questions

Official sources

1. ietf-tools/datatracker on GitHub
2. License: BSD-3-Clause
3. Project website
4. README
5. Releases