Andrew Miller

The Setup: APIs Are Everywhere We'll start with a quick tour of what "API" really means—not just REST, but Python imports, command-line interfaces, and the configuration files we use every day. Django's settings.py is arguably its most-used API: the interface through which we configure databases, middleware, installed apps, and everything else. And manage.py commands are APIs too—contracts between Django and developers about how to run, migrate, and manage projects. This reframing sets up the core question: if runserver is an API, what is it communicating? And is that message actually helpful? The Problem: Django's Deployment Cliff Deployment breaks down into three parts: setting up the environment, getting code there, and running processes. Django provides great documentation, but when it comes to actually running your app in production, you're on your own. Even the name runserver is misleading—it doesn't say "development." It just says "run the server," and for a beginner, that sounds like the whole story. Many miss the jump entirely—not realising a different approach is needed for production. And when they do, configuring Gunicorn, Uvicorn, or Celery workers is daunting—and can feel like a betrayal of the "batteries included" promise. We can add warnings and documentation, but that can add noise and not signal. The reception of adding the warning "do not use in production" to runserver has been mixed and if I'm honest it's a poor solution and quick fix to a larger problem. That's coming from me—the one who proposed and implemented it! If the API design itself is confusing, no amount of documentation or warnings will fix that. A Possible Solution: django-prodserver I've built and published django-prodserver, a package that brings a production process configuration API into the familiar manage.py interface, configured through settings.py, where it belongs. A PRODUCTION_PROCESSES dictionary lets you name and define your processes, with backends for popular WSGI/ASGI servers and background workers. Swap backends by changing one line. The package also includes a devserver command—mirroring the symmetry we might want in Django itself. Live Demo I'll take an existing project deployed on a Dokku VPS and show what changes when prodserver enters the picture. The goal is to make the "aha" moment tangible: this is what a cleaner deployment API could feel like. The Bigger Picture: What Could Django Provide? We can't just change `runserver, Django's stability guarantees mean experimenting with core commands is risky. That's actually a good thing. But packages like django-prodserver give us a safe space to try ideas in the open. What naming makes sense? What hooks should Django expose for the ecosystem to build on? Could this eventually lead to production server support in core? I'll share some thoughts and invite the community to shape what comes next for prodserver and more broadly for designing new APIs through the experimental API feature that has been proposed. Takeaways Attendees will leave with: - A new way of thinking about Django's CLI and settings as API surfaces - Practical knowledge of django-prodserver they can use today - Ideas for how the community can shape Django's deployment future - Considerations for API design and how the experimental APIs proposal could open new paths for Django's development