logoalt Hacker News

Show HN: Django Control Room – All Your Tools Inside the Django Admin

85 pointsby yassi_devtoday at 2:31 PM44 commentsview on HN

Over the past year I’ve been building a set of operational panels for Django:

- Redis inspection - cache visibility - Celery task introspection - URL discovery and testing

All of these tools have been built inside the Django admin.

Instead of jumping between tools like Flower, redis-cli, Swagger, or external services, I wanted something that sits where I’m already working.

I’ve grouped these under a single umbrella: Django Control Room.

The idea is pretty simple: the Django admin already gives you authentication, permissions, and a familiar interface. It can also act as an operational layer for your app.

Each panel is just a small Django app with a simple interface, so it’s easy to build your own and plug it in.

I’m working on more panels (signals, errors, etc.) and also thinking about how far this pattern can go.

Curious how others think about this. Does it make sense to consolidate this kind of tooling inside the admin, or do you prefer keeping it separate?


Comments

yassi_devtoday at 2:48 PM

I've built an official website for this project here: https://djangocontrolroom.com/

I think that explains some of the value for this project a bit better

show 2 replies
ashwindharnetoday at 6:57 PM

Looks great -- always wished the admin panel came with more configurable bells and whistles. I've been exploring Quarkus recently (https://quarkus.io/), and it has a Dev UI with a similar extensible "panels" pattern. It's a bit different than Django since it's not for running in prod, but nonetheless it's pretty helpful.

sort of a tangent, but quarkus also has a concept of "dev services" that are monitorable via the dev UI. It uses Testcontainers to start and autowire runtime deps (postgres, redis, keycloak, etc.). Pretty pleasant experience to get the whole stack spun up and observable alongside the dev server.

nehalemtoday at 8:07 PM

I like this a lot. What I would love to see is a panel to run management commands and see their output. Would be great in services like Google Cloud Run where you cannot access a shell anymore like you could on Heroku.

show 1 reply
simonwtoday at 5:52 PM

I like the way each panel is its own separate package on PyPI and the system picks them up via setuptools entry points. It's a neat implementation of a plugin pattern.

show 1 reply
giancarlostorotoday at 6:42 PM

Django Admin definitely needs extensions like this. I hope someday they make it a stronger more capable Admin UI. Their own docs if I remember correctly tell you to build your own UI if you're hitting limits with the admin UI itself, which is fine, but there's so much OOTB that works nicely for the admin UI.

I like the spirit of this, and could see Django heavy shops wanting to add bits and pieces that display tooling / services they care about in Django admin.

show 1 reply
blorenztoday at 6:56 PM

I love the sentiment and ambition in this! The Django admin is a core reason why I still choose Django over other solutions. I tell my team that the Django admin CRUD is our backstop when we encounter issues in our frontend UI. Thank you for tooling it out more!

show 1 reply
greenie_beanstoday at 8:07 PM

love this!! thanks for sharing. this might help me a lot.

jnpnjtoday at 6:31 PM

Lovely. I wonder how many people did similar things in their own django instances because the lack of embedded monitor is often a source of friction.

show 1 reply
butterlettucetoday at 6:13 PM

Tell your parents i said thank you for making you exist.

show 1 reply
drchaimtoday at 4:38 PM

Good idea. If you add a kind of skill/prompt you’ll get a lot of other components from the community ;)

show 1 reply
johsoletoday at 7:37 PM

Nice work.

dec0dedab0detoday at 3:31 PM

i like it, but I think i would rather have a proxy, or atleast an auth redirect to those different tools.

I used to have flower at myapp.com/flower using an auth redirect in nginx to a simple view in django that made sure it was an admin user. I think if you can make that setup easier to leverage existing tools that would be nicer than rebuilding everything.

show 1 reply
izzie1234today at 5:07 PM

I love this idea. I see the AI era having 2 competing views when building something new:

1. Build X with pure <language of choice>. Why? LLMs will have less context needed, and onboarding engineers would be easier since there’ll be less overhead and opinionated frameworks knowledge required

2. Build X using well establish frameworks. Painful in the beginning since you’ll not only need language knowledge, but framework knowledge. The upshot, is scaling and maintainability

I love that this ecosystem will heavily pressure teams to consider (2) more and more — solving the very real “AI slop” problem

show 1 reply
HFerrahoglutoday at 7:45 PM

looks good.

rick1290today at 7:48 PM

love it

dzongatoday at 4:49 PM

this is pretty dope

show 1 reply
raphaelmolly8today at 5:00 PM

[dead]

raphaelmolly8today at 5:01 PM

[dead]

genie3iotoday at 3:30 PM

[dead]

FEELmyAGItoday at 4:42 PM

[flagged]

show 3 replies