Proposal: Rename `runserver` command to `devserver` and add a `prodserver` management command

As the title suggests I have related proposals that could be proposed separately, but make more sense to discuss together.


While helping another newcomer to django and noticing that they had used runserver in their production hosting environment, I wondered if the name of runserver could be clearer to beginners in terms of the intention of its use.

The solution is me is two-fold:

  1. Rename runserver to devserver or similar (run_devserver), the key would be to have dev or similar in the name somewhere. This makes it explicit that the command is for a development environment and not production.
  2. Introduce a prodserver or similarly named command to run a configured wsgi/asgi server or other commands via settings. Initially, this could be done via subprocess or expanded to call the relevant Python APIs in the wsgi/asgi servers. The goal here is to provide a common interface for running Django in production but doesn’t limit calling a wsgi/asgi server directly. Additionally, I don’t believe this should necessarily cover all possible use cases to run Django in production but provide an easy starting point for newcomers.

This could easily be split into two separate tracks of work.

For the rename, it would be adding devserver (or similar) in addition to runserver, then deprecating runserver with the normal deprecation policy.

The prodserver command can easily be tested as a third-party package, to begin with, however, having the goal of a clear way to run development and production ought to be eventually available by default out of the box. A DEP is also likely required here to ensure that all desirable use cases are covered.

I will likely give the prodserver package a go in the next week or so.



Before you start your own package you might wanna look at GitHub - lincolnloop/django-production: production settings for Django and maybe contribute there instead?




I was vaguely aware of that repo and briefly looking at it this proposal is closer to one of its dependencies - GitHub - lincolnloop/django-webserver: Production webservers as a Django management command so I may start there instead of from scratch.



+1 good points, good plan.

I love the concept of “here is something to get you started.” (in this case, started = deployed)
and they can/will adjust things as needed later when they run into problems. In this case, I suspect most people don’t need ‘fancy’ deployment (large scale, jython, other niches) and so something simple will be fine.

Renaming this does make sense to me - even in my limited exposure to user support - I regularly see people thinking this is how they’re always meant to run their application.

Since looking at django-webserver (dependency of django-production)

I have outlined a few more thoughts here: What would a prodserver do? - Software Crafts

I have produced a proof of concept repo here: GitHub - nanorepublica/django-prodserver

I still have the long list of required things (docs, tests, pypi etc) before it is ready to be used.

That said happy for issues/comments on this idea.

Note this was heavily inspired by the django-webserver package.

1 Like

Searching existing issues reveals this open ticket which is some what related: #21978 (Add optional gunicorn support to runserver) – Django

I have created a ticket for the first part: #35258 (Rename the 'runserver' management command to 'devserver' to be more explicit that it is intended for development only) – Django

Ticket for the second part will come soon.

I’m a strong -1 for renaming runserver. I think you’re creating a lot of work for some percentage of the user-base for no benefit to them - and, IMO, minimal benefit to those coming along in the future.

Aside from all the tutorials, books, and other educational material becoming obsolete, you also have third-party tooling that overrides the runserver command for its own purposes (e.g., Channels), and all the scripts and other tooling built on using runserver as its base (e.g., running and debugging Django in Visual Studio Code.) This change invalidates every workspace file that anyone has ever created and modified for every Django project that gets upgraded to a release with this change in it.

I think that this, like some other historical decisions, fits into the category of being too-well entrenched to make it worth changing.


Thanks, Ken, I was expecting a response like this at some point and expected sooner as well.

It could be that both commands could exist and runserver doesn’t get deprecated or has a much longer deprecation, but neither sounds appealing.

What would be your opinion on the second part of the proposal of adding the prodserver command?

Oh, I’m probably a 0 on that. I don’t have any objection to including it, but I don’t have any environment where I could see using it. I use either supervisord or a systemd control file to run the Django processes for any system running a persistent process. Running a production web server from a command shell just seems like an invitation to a whole host of problems.


Actually, continuing to think about this, I’m going to revise my opinion to be a -1 for this as well.

I can think of two questions I have answered here in the past that would have raised issues along those lines.

One person asked why their project stopped running when they ran ./ runserver & and then logged off, and another person asked why it would be a bad idea to run their server in a screen session.

I think that having a script to run a production server is just going to encourage this type of thinking.

I can see some value in bundling or making a default production-quality server available, but I worry about the message that it sends by encouraging its use directly from the command line.


I’m also -1 for both proposals. IMO this will create unnecessary noise, citing the docs:

Now’s a good time to note: don’t use this server in anything resembling a production environment. It’s intended only for use while developing. (We’re in the business of making web frameworks, not web servers.)

1 Like

I’m also -1 on both proposals for the same reasons as Ken and Mariusz. A production grade web server is its own project, especially when you start considering things like WSGI and ASGI support, TLS, performance, … The landscape is always changing too, for example this week I learned about nginx unit. I think if there’s any management command to launch a configured production-grade server, it’s better in a third-party package so it can evolve separately and Django isn’t stuck maintaining it.

1 Like

Thanks all for your responses. I will continue to publish the third-party package, but consider this proposal likely dead at this point.

A couple of process/community questions as this is my first proposal and would like to understand the community dynamics better:

  1. This post has been around for a couple of weeks, what triggered you to respond recently? I guess it was me creating a ticket.
  2. Was this a reasonable time to wait before creating a ticket or should I have waited longer?
  3. From the ticket, what is considered a “strong consensus”? (I realised there is a longer post about this in terms of reframing DEP 1)


I tend to avoid offering an opinion on a lot of things because I still feel like I work in more “niche” areas than most, and a lot of what is proposed doesn’t affect me either way. If something doesn’t jump out at me right away as being a problem, I tend to ignore the proposal because I don’t see much value in me offering a lot of “+/-0” opinions.

Quite honestly, I didn’t give this the thought it deserved. I recognized that the docs and tutorials would need to be changed - I didn’t think of third-party materials at all. So if anything, the delay is my fault for not giving your proposal the consideration it required.

I had mentally set your proposal aside, being a solid “-0” by thinking that I’d have to change a couple scripts, and so considered it a “minor annoyance” that I could live with.

So why now? Your recent post was a reminder of the proposal. It wasn’t the ticket per-se, but seeing the post itself reminded me that this was something “in progress”. That, combined with a couple of recent topics here in the forum, is what got me thinking about it some more - making me realize that my opinion on “runserver” is stronger than a “-0”.


Thanks, Ken, I appreciate the response!

If this helps, I feel you followed the process exactly as you should have.

As a baby step, maybe let’s add to this: FAQ: Contributing code | Django documentation | Django with the questions you’re asking and link it in the feature request docs.

This can have some recommendations (around cross promoting in other sub communities such as Discord, Mastodon etc) as well as some expectation management (around time, maybe that “concensus” is not concretely defined).

The question “what is concensus” or “how do I gather concensus” imo classes as a frequently asked question.

1 Like

Thanks, Sarah, that is good to know!

I will have a look at contributing to that FAQ page when I have some spare time.

1 Like