I typically use runserver_plus in development from django-extensions. As a result I am used to seeing the following warning in red when starting the server:
WARNING: This is a development server. Do not use it in a production deployment. Use a production WSGI server instead.
After doing some research it turns out this warning comes from Werkzeug instead of runserver_plus directly.
I would like to suggest that a similar warning gets added to runserver directly to make explicitly clear that runserver is not intended production deployments.
My initial suggestion for the warning would be very similar, with the addition on a link to the docs like so:
WARNING: This is a development server. Do not use it in a production deployment. Use a production WSGI server instead.
For more information on production servers see the documentation: https://docs.djangoproject.com/en/5.0/howto/deployment/
I’ve seen several projects deployed with runserver so I’d welcome this change.
A lot of developers do not read the docs and aren’t aware of this. A lot of ops team are tasked to deploy various technologies and won’t know the intricacies of each.
It’s even worse than that. Just about every “high search result” for “deploy django docker” blogs and tutorials use runserver within the container. So there are a lot of recommendations out there suggesting this is actually a good practice.
I’m really on the fence about that. I understand the basic sentiment - and don’t necessarily disagree. But I think it’s also an issue that a person planning to deploy a Django project for the first time isn’t directly confronted with this.
It seems to me that it would allow the new / first time user to go quite far before seeing it. You may have someone who feels like they’re ready to deploy their code and now they’re just finding out that what they’re planning to do isn’t appropriate.
While the runserver docs make it explicit that you’re not supposed to use Django in production, the deployment docs don’t. Those docs (How to deploy Django | Django documentation | Django, Deployment checklist | Django documentation | Django) address what you can do, but other than the DEBUG setting, don’t address things you should not do. (e.g., they document how you can deploy using gunicorn, uWSGI, or mod_wsgi, but don’t explicitly tell you to avoid using runserver.)
Also, consider when someone is doing a docker deployment as perhaps the first / only time running with DEBUG=False, are they even going to see that message?
Instead of limiting the warning when DEBUG is False, maybe we could have a flag or environment variable for runserver with a name that would stand out to anyone seeing it in a Dockerfile. Something like --hide-unsuitable-for-production.
Was looking into the PR, I propose that we stop suppressing the verbosity argument for runserver and hide the warning when DEBUG=True and --verbosity=0
That way:
the warning is there by default, so they read it during development
developers that are bothered by it can turn it off
the warning is there in production, assuming they set DEBUG=False, even if they were suppressing it locally --verbosity=0
Here’s the scenario I’d like to avoid (and that I’ve been a part of, minus the setting):
Developers create a Dockerfile that uses runserver --verbosity=0 and DEBUG=True because they don’t want to see the warning during development.
Ops are asked to “ship the app”. They know nothing about Django and just focus on getting containers running. They might audit the Dockerfile and are happy with it because nothing stands out as not suitable for production.
runserver and DEBUG=True ends up running in production.
With an argument and/or environment variable with a very explicit name, Ops could see in the Dockerfile that there’s some production related things that they need to dig into.
Also, to go with the principle of least surprise, I think most developers would expect runserver --verbosity=0 to stop logging HTTP requests. Quoting the docs:
Specifies the amount of notification and debug information that a command should print to the console.
My personal preference here would be just to have the warning by default all the time. But I understand that it being highlighted in yellow could be a distraction as a warning from the checks framework or something else.
I am leaning more toward having an just an environment variable to hide this, since it would meet the requirements outline of being visible in an Ops setting, while avoiding the current disagreement on which existing flag to use or create a new one.
