Django Control Room: a plugin framework for operational admin panels

Panels as separate packages, found through entry points

Django Control Room is described as a plugin framework for building Django admin tools, called panels, together with a suite of official panels for services like Redis, Celery and caches, plus Django internals like URLs and Signals. Every panel, official or third-party, is a small independent Python package built on the public plugin API in dj-control-room-base.

The mechanism is Python entry points. Install dj-control-room and it discovers compatible panels via entry points, renders them in a centralized dashboard, and gives them a shared design system, a permissions model and admin sidebar integration. That last part is what makes a third-party panel feel like a first-party one: a custom panel behaves like the official ones, which is stated as a feature in its own right.

The installation options show the shape of the ecosystem. The core alone:

# Core only
pip install dj-control-room

# With specific official panels
pip install dj-control-room[redis,cache,urls]

# Or with all official panels
pip install dj-control-room[all]

The extras in pyproject.toml name the five official panel packages with their minimum versions, and the `all` extra is the union of them. So the official panels are genuinely separate distributions, installed as optional dependencies, and each can be pulled on its own if you want one panel and not the framework's opinion about your infrastructure.

The framework package itself is thin in dependency terms. Its declared dependencies are Django, at 4.2 or newer, and dj-control-room-base at 1.6.0 or newer. Everything else is either an optional panel or a development dependency, and the requirements.txt in the repository is more explicit about the split, with the core dependencies, then the testing dependencies, then the build dependencies, then the documentation dependencies, and then the control room panels listed at the end.

Wiring the panels into a project takes three edits

The quick start is short enough to follow exactly, and it shows the three things a Django project has to change.

First, the installed apps. You add dj_control_room_base, which is the required core library, then your panels, then dj_control_room so that they appear under one admin section:

INSTALLED_APPS = [
    # ...
    "dj_control_room_base",
    "dj_redis_panel",
    "dj_cache_panel",
    "dj_urls_panel",
    "dj_control_room",
]

Second, the URLs, which are mounted under the admin prefix:

urlpatterns = [
    path("admin/dj-redis-panel/", include("dj_redis_panel.urls")),
    path("admin/dj-cache-panel/", include("dj_cache_panel.urls")),
    path("admin/dj-urls-panel/", include("dj_urls_panel.urls")),
    path("admin/dj-control-room/", include("dj_control_room.urls")),
    path("admin/", admin.site.urls),
]

Third, the migrations, and then the panel is at http://localhost:8000/admin/dj-control-room/:

python manage.py migrate

Three observations about that sequence. The core library is listed separately from the aggregator, which means the dependency order in INSTALLED_APPS is not arbitrary, since Django loads apps in order and the panels depend on the base. The panel URLs are included explicitly rather than discovered, so a panel is not mounted simply by being installed; it is mounted by being listed, which means a third-party panel is a deliberate addition rather than an automatic one. And the aggregator is mounted last, at its own path under admin, so the control room is a page within the admin rather than a replacement for it.

The documentation set follows the same structure, with pages for Installation, Configuration, Scopes for permission scopes, Theme Adapters, Creating Panels and an API Reference, alongside the official site at djangocontrolroom.com.

What the five official panels actually show

The official panel table is the fastest way to see what the framework is for, because each panel is a small operational tool that would otherwise be a custom admin view.

The Redis Panel monitors connections, inspects keys and views memory usage. The Cache Panel inspects cache entries and views hit and miss ratios. The URLs Panel browses URL patterns and tests resolvers. The Celery Panel monitors workers and tracks task queues. And the Signals Panel inspects Django signals and receivers.

Each has its own package name and its own install command, listed in the table: `pip install dj-redis-panel`, `pip install dj-cache-panel`, `pip install dj-urls-panel`, `pip install dj-celery-panel` and `pip install dj-signals-panel`.

The Signals Panel is the one that will interest a Django developer most, because signals are the part of the framework whose runtime behaviour is hardest to see without instrumentation. Listing the receivers registered for a signal is something you end up writing yourself, usually badly, usually in a shell inside the container.

The Cache and Redis panels overlap, and that overlap is a design hint rather than an oversight. The cache panel is about the hit and miss ratio, which is a question about the caching layer you use, while the Redis panel is about a specific server, its connections, its keys and its memory. A project using django-redis sees both questions, and the framework leaves it to you to install which answers you actually need.

The URLs Panel with its resolver testing is the one that pays for itself quickly. Django's URL configuration is a layered include tree, and when a route stops matching, the useful question is which pattern is winning, which is exactly what a browser testing the resolvers against the pattern list would show you.

Scopes, themes and the MCP endpoint

Three parts of the framework go beyond simply hosting a panel, and each is a decision rather than a convenience.

The permissions model is documented under Scopes, and the feature list calls the project secure with package verification and staff-gated access. So a panel is not simply visible to every staff user; access is gated and, as the name suggests, scoped. For a panel that can inspect a cache or a task queue, a coarse staff check is not enough, and a scopes mechanism is the way to give a panel its own permission rather than borrowing the admin's.

The theme adapters handle the other problem a plugin framework has. The shared UI is responsive with dark mode via a common design system, and theme adapters exist for popular admin skins. That is a real consideration if you use a themed admin package: a panel that renders with its own styles will look like a different application, and adapters are the mechanism for making a third-party panel match whatever skin the project already runs.

The AI agent integration is the newest and most consequential. One MCP endpoint aggregates every installed panel's tools, so an agent that can speak MCP gets access to the operational tools of every panel you have installed, in one place. The feature list names it as a bullet and the configuration page has a section for it.

That is a genuinely different security posture from the rest of the framework, and it deserves the scrutiny the rest of the interface does not. The scopes model governs what a human staff user can reach, and an MCP endpoint that aggregates every installed panel's tools potentially exposes the union of those capabilities to whatever agent is pointed at it. The project does not document the default posture for that endpoint in the README, so if you enable it, the first thing to establish is which panels are mounted, what their scopes are, and what the endpoint actually exposes.

A cookiecutter for your own panel, and a Docker setup for the demo

Building a panel is presented as a project you start from a template, and the tooling around that is minimal and conventional.

pip install cookiecutter
cookiecutter https://github.com/django-control-room/cookiecutter-dj-control-room-plugin

Two guides are linked for the rest: Creating Panels, and a build your own panel walkthrough on the official site. The use of cookiecutter rather than a Django app generator is a deliberate choice, since a panel is a package with an entry point rather than an app in a project, and the two are not the same shape.

The repository layout matches. There is a `dj_control_room/` directory for the framework, an `example_project/` directory with the demo, `tests/`, `docs/` with an mkdocs.yml at the root, `CREATING_PANELS.md` at the root as well as the documentation site, and the usual packaging files with a pyproject.toml, a setup.py that is a four line shim, a MANIFEST.in, a Makefile, a pytest.ini and a codecov.yml.

The example project has its own Dockerfile, because the compose file builds the development container from it:

version: "3.9"

services:

  # Development container
  dev:
    build:
      context: .
      dockerfile: example_project/Dockerfile
    ports:
      - "8000:8000"
    volumes:
      - .:/app
    working_dir: /app/example_project
    tty: true
    stdin_open: true
    command: "/bin/bash"

The compose service is the development environment, with the repository mounted at /app, the working directory set to the example project so the Django app is the default, and an interactive shell as the command. The requirements file also lists the panels used by the example project, with dj-redis-panel, dj-cache-panel, dj-celery-panel and dj-urls-panel, and a commented set of cache backends including redis, pymemcache, django-redis and psycopg2-binary, which is how the example is set up to demonstrate the cache panel against more than one backend.

The requirements are Python 3.9 or newer and Django 4.2 or newer, and the classifiers in pyproject.toml list Django from 4.2 through 6.1 and Python from 3.9 through 3.14. The project is MIT licensed, the last push was on 2026-09-30, and the releases are 1.8.1 and 1.8.0 on the same day with 1.7.1 in August.

Editorial conclusion

Adopt Django Control Room if you already run Django and want operational panels for Redis, Celery or your own internals to share one design system and permission model rather than living as separate admin pages. Do not adopt it if you need a single panel and can write one admin view, since the framework adds a dependency and a plugin surface, and check first how the scopes permission model and the MCP endpoint are meant to be used, because the panel tools are exposed through one agent-facing endpoint and that is a decision to make deliberately.

Frequently asked questions

Official sources

1. django-control-room/dj-control-room on GitHub
2. License: MIT
3. Project website
4. README
5. Releases