Missing documentation: deploying Django in production behind a proxy.

[Klaas van Schelven]

When Django is deployed behind a proxy (with https), various settings _must_ be set for your site to work correctly. Currently, there is no single place where these settings are documented. That is, they are mentioned in the general docs for settings (with a warning "only do this when behind a proxy) but there is no page "how to set up Django behind a proxy", which means to do this you must now puzzle various Stack Overflow / blog posts together.

The variables that I could find are SECURE_PROXY_SSL_HEADER, USE_X_FORWARDED_HOST and USE_X_FORWARDED_PORT (if the port is not included in the host), but there may be more.

[Sarah Boyce]

There's need talk that the Django docs should better help with deployment, so I would happily review PRs on this.

[Wassef Ben Ahmed]

I wrote a small guide to a bare minimum production deployment of Django on a VPS.
It covers most things needed from pointing a domain to an IP address to generating self-signed certs.

should I try removing any Django-unrelated parts and push it as a PR?
If so: any suggestions on parts that shouldn't be included? or recommendation on what to focus on?

Link to guide: ​https://dev.to/wassef911/deploying-django-in-production-b1p

also related ticket https://code.djangoproject.com/ticket/35451

---
closes thing I found online, is: ​https://www.digitalocean.com/community/tutorials/how-to-set-up-django-with-postgres-nginx-and-gunicorn-on-ubuntu
although it's not really focusing on making the deployment a "production" but to just get things running...

[Sarah Boyce]

Please either link the PR or make sure the PR title has the prefix "Fixed #35450 --" so that it will be linked automatically when you set "Has patch" to "Yes"

[Mariusz Felisiak]

Replying to Sarah Boyce:

There's need talk that the Django docs should better help with deployment, so I would happily review PRs on this.

There is so many different deployment options that, IMO, Django documentation is not appropriate place to cover them. We've rejected many such tickets in the past. They will outdate really fast, must be opinionated, won't work for everybody, create a maintenance burden, and can create many further reports about security issues, missing options etc. I'm strongly against accepting either #35450 or #35451.

[Sarah Boyce]

Replying to Mariusz Felisiak:

There is so many different deployment options that, IMO, Django documentation is not appropriate place to cover them. We've rejected many such tickets in the past. They will outdate really fast, must be opinionated, won't work for everybody, create a maintenance burden, and can create many further reports about security issues, missing options etc.

Good points thank you for raising👍

Klaas/Wassef, I see that FastAPI has an ​External Links and Articles section on their website which includes some articles on deployment. From a maintenance perspective this is much simpler, allows adding many opinions/voices on this topic, and means we can keep Django's official documentation limited to hold information that is unique to Django.
As Mariusz has said, the Django documentation may not be the appropriate place to document this.

As previous suggestions have been rejected, this ticket would require a change of documentation approach, and hence we need a discussion on the ​Django forum and consensus that we should include this in Django's official documentation. This discussion would need to address the concerns raised in this ticket.
However, I would recommend investigating other approaches here which do not impact the official docs.

[Klaas van Schelven]

Despite being the original raiser of this issue, I do not have a strong opinion about it, and I can largely follow the reasoning of keeping the maintenance burden low etc.

A further 2c I'd like to add is that such a philosophy does seem to be slightly at odds with the status quo, in which the docs do have various (outdated?) articles on deployment.

[Sarah Boyce]

Replying to Klaas van Schelven:

A further 2c I'd like to add is that such a philosophy does seem to be slightly at odds with the status quo, in which the docs do have various (outdated?) articles on deployment.

It's a good point, we should perhaps make an audit of these and weigh up the value of keeping them vs retiring them, especially if keeping them up-to-date is difficult