Package: django-production
django-productionOpinionated one-size-fits-most defaults for running Django to production (or any other deployed environment).Installationpip install django-production
DJANGO_SETTINGS_MODULE=yourproject.settings django-production-applyWhat it doesWhen you install the package, it will install the following dependencies:whitenoise- for serving static filesdjango-environ- for reading settings from environment variablesdjango-webserver[gunicorn]- for running the webserver viamanage.pydjango-alive- for a health check endpoint at/-/alive/Runningdjango-production-applywill append thedjango-productionsettings to your project's settings file and add the healthcheck endpoint to your project'surlpatterns. You can see the settings that are added insettings.py.You should adddjango-productionto your requirements to keep the necessary dependencies in place. Alternatively, once the patch is applied, you're free to move the dependencies into your own requirements file and removedjango-productionaltogether.Running in productionStart the webserver withpython manage.py gunicorn.Set theWEB_CONCURRENCYenvironment variable to the number of gunicorn workers you want to run. Start with 2x the number of CPU cores.Required environment variablesDJANGO_ENV- set toproductionto enable production settingsSECRET_KEY- a secret key for your projectOptional environment variables when usingDJANGO_ENV=productionALLOWED_HOSTS- a comma-separated list of allowed hostsDEBUG- defaults toFalseyou probably don't want to change thatDATABASE_URL- a database URL (seehttps://django-environ.readthedocs.io/en/latest/types.html#environ-env-db-url)CACHE_URLorREDIS_URL- a cache URL (seehttps://django-environ.readthedocs.io/en/latest/types.html#environ-env-cache-url)SECURE_HSTS_INCLUDE_SUBDOMAINS- set this toTrueif your site doesn't have any subdomains that need to use HTTPUnder the hood,django-productionusesdjango-environ'sFileAwareEnvclass to read environment variables. This allows you to append_FILEto any environment variable to load the value from a file. For example,DATABASE_URL_FILE=/var/run/secrets/DATABASE_URLwill load the database URL from that file.AnswersYou didn't ask any questions, but if you did, maybe it would be one of these:Why did you write this?Django takes an un-opinionated approach to how it should be deployed. This makes it harder for new users. Even experienced users probably copy this from project-to-project. This aims to make it easy to get a project ready to deploy. I also hope it will give us a chance to create some consensus around these settings as a community and maybe start folding some of this into Django itself.Why are you writing to my settings file? You could just just do an import.It makes it easier to see the changes. I'm of the opinion that settings files should be as simple as possible. Having the settings right there makes it easier to debug.A one-size-fits-all approach will never work here. I'm shooting for one-size-fits-most. Users are free to make changes however they see fit once the change is applied. It's basically whatstartprojectis already doing.I disagree with the settings/packages you're using.Not a question, but ok. Feel free to submit an issue or pull request with your suggestion and reasoning. We appreciate the feedback and contributions. We may not accept changes that we don't feel fit the spirit of this project (remember, it'sopinionated). If you're unsure, don't hesitate to ask.Publishing a new versionUpdate the version indjango_production/__init__.pyUpdate the changelog inCHANGELOG.mdCommit the changesTag the commit with the version number (git tag -s v0.9.9 -m v0.9.9)Push the commit and tag (git push && git push --tags)Publish to PyPIflit publishTo DoHandle media settings for common object storesEmail settings including non-SMTP backends like SES