Care to elaborate?
As far as I can tell debian (stable) provides an execution environment that’ sufficient for discourse without docker. And some (most?) cheap VPS boxes don’t allow you to run docker, but will give you 20- GiB of disk space and 2GiB RAM. I’ve one of those and my (low-traffic) discourse installation runs happily there.
Which procedure are we talking about?
If Docker is involved, the whole thing is completely independent from the host’s package manager and package sources.
The one from https://github.com/discourse/discourse/blob/master/docs/INSTALL-ubuntu.md with s/ubuntu/debian/.
Ah ok. Yeah, the use of rvm in that manual mitigates the lack of a more recent Ruby in Debian.
But then there’s
nginx 1.2 and postgresql 9.1 works fine here with discourse. And I pinned redis-server from debian testing.
Then you’re missing out on a lot of performance improvements, especially with regard to TLS handshakes, that nginx has received since that version.
Sure, if your forum is small enough, you can certainly do without, and if nothing else, Debian ist excellent at backporting security fixes to outdated versions. 
Yep, that perfectly fulfills my use case: Discourse without Docker and with minimal maintenance effort.
That’s just BS, sorry. I run it on Debian (inside Docker), it works very well; there are some things you need to consider.
Generalizations are a bit problematic if they’re coming on this strongly…
I think @codinghorror objects to the hugely conservative release cycle practiced by debian, its just way too slow for our liking.
not sure if you can get aufs going on debian, device mapper is a disaster on docker and not sure what release of btrfs you would be on, but I doubt it is recent. no chance of getting overlayfs imo. Not sure how you are getting a decent docker install.
All the templates are open source, no magic included
We use runit and unicorn, unicorn forks out sidekiq
As I said: it requires a piece of extra work to pull a more recent backported kernel, but with that, it works just fine!
Nice, thanks for the link to the old manual, and the script! 
I guess I could also use Docker, but as long as there is no ‘How to integrate discourse_docker into an existing system with a normal webserver’ tutorial, this method is far simpler for me.
Just wanted to chime in to clear things up: I run packager.io, so I can confirm that Discourse is still maintained. What Packager does is simple: it takes an app, applies one of the Heroku buildpacks on it, and package that into a deb/rpm for any number of the Linux distributions we support.
So you basically end up with what you would get on Heroku (i.e. processes are launched based on your Procfile, using the exact ruby version and gems specified in your Gemfile), but on your server(s). The package also ships with init scripts, logrotate, crons, etc.
For other dependencies, we rely on the system dependencies provided by the package manager of the distribution (i.e. we don’t package the world).
That being said, I can understand why Discourse went the docker route, especially if the alternative was a manual/roll-your-own install.
I just setup my first Discourse installation on DO using Ubuntu and Docker and I have to say it was painless. I have read on this forum that some people have Discourse configured with Nginx. I don’t use Nginx and while setting up Discourse I don’t remember installing Apache. So my question is… how are my web requests being handled? Also, does using Nginx make Discourse run more efficiently?
NGINX → Unicorn Master → Unicorn Worker
Than what 
… in general NGINX is more efficient than Apache and to get stuff like long polling working on Apache it takes some hoop jumping