Show HN: Django Control Room – All Your Tools Inside the Django Admin (github.com)
- 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?
23 comments
[ 2.7 ms ] story [ 38.7 ms ] threadI think that explains some of the value for this project a bit better
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.
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
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.
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.
I believe keeping the tooling separate and enabling them on demand totally makes sense.
The Django admin is really great. I do wish there could be a bit more extensibility hook points to hook into existing stuff, but I know a loooot of projects that hack stuff into the admin despite that (I think in particular it's a bit futzy to have things like confirmation screens on custom actions).
I think the real power of Django comes from not only having the batteries included, but almost always having the right kind of extension points in terms of methods (or template overrides) that really give you ways to quickly insert the right kinds of customization for your project. The admin existing and working so well for so long is proof of that IMO