[wilsonfiifi]

Dokku will allow you to host multiple applications on subdomains for which you can create CNAMEs in your DNS settings. Dokku is more of a mini self hosted Heroku without a dashboard so you'll lose out on cpanel features like email hosting.

But If you're not uncomfortable using docker, you can check out Cloudron [0] which handles email [1] and gives you access to quite a few web apps you can easily install on your server. It supports PHP app deployments [2] out of the box but for Django, you'll have to dig a bit deeper into their docs to learn how to deploy a custom docker based app [3].

[0] https://www.cloudron.io/

[1] https://docs.cloudron.io/email/

[2] https://docs.cloudron.io/apps/lamp/

[3] https://docs.cloudron.io/custom-apps/tutorial/

[robomartin]

BTW, it's not that I am not confortable with Docker. In fact, we use it for development. This is more about time and resources. I run more than one business and a couple of them have more than one domain. We pay for a decent VPS and can host and manage as many email addresses and applications as we want. Yet we have to limit it to PHP (either pure PHP or something like Wordpress). And, BTW, I hate using PHP.

For internal stuff we use Django for everything. Host it locally, etc. We even use Django as the front end for industrial automation applications (which imposes interesting challenges, like maintaining state in the database as well as reliable activity logs and more).

If I were to summarize the difference between doing Django for the web vs. PHP for a business it would go something like this:

PHP: Get almost any server. Setup the domain, emails, setup database, upload code. You are up.

For Django you could do this (some of this is dated, just making a point):

https://uwsgi-docs.readthedocs.io/en/latest/tutorials/Django...

or this:

https://www.gjlondon.com/uncategorized/the-idiomatic-guide-t...

or this:

http://www.robgolding.com/blog/2011/11/12/django-in-producti...

or this:

https://developer.mozilla.org/en-US/docs/Learn/Server-side/D...

In other words, you are way past the beauty and simplicity you got during local development.

And, of course, for most, if not all, of the above, you still have to deal with setting-up business email. Which means you either get the same VPS you got for the PHP case and point the MX record that way or, spend a bunch of money per email address with something like Gmail. Etc.

Django is fantastic. Somehow, someone needs to figure out how to be able to launch the same type of site you might develop locally to a standard VPS just as easily as what is possible on your local development system. Yes, of course, for more advanced sites you are into separate DB, static, application, etc. servers. That's a different use case. I think what people are saying is that there's a great divide between "runserver" and actually being on a server from there without paying more for specialized deployment services.

Another way to look at this that Wordpress will never be challenged at scale if a better tool like Django isn't easily accessible to developers who are not Linux/server experts. I was running Unix before Linux came out and have used Linux in various forms (including early embedded systems applications) since the beginning. If someone like me recoils at the idea of actually deploying Django in the real world I can't imagine what this might feel like to others who might lack the experience.

In other words, I can do the work. I just think it's unnecessarily complex and not enough effort has been expended duplicating the ease of local development for basic to mid-range Django apps at the production server level.

[bjourne]

That's true. Every time I have to launch a new Django site I always have to spend an hour or two reading docs to refresh my memory on how to configure everything. SSL, systemd services, certificates, uwsgi, database setup, permissions, dns, email, etc. Someone could probably make a lot of money by creating some kind of Django+uwsgi+docker+nginx+postgreSQL bundle to make this process as painless as possible.

[robomartin]

Here's one way I look at it. I don't need or want the simplified local development environment. As neat as "runserver" might be, it actually creates a problem, because going from there to production feels like the difference between driving on a lazy country road on a beautiful summer day to driving in the middle of one of the most chaotic cities in the world in a storm.

My humble suggestion would be that this form of easy local development should be deprecated in favor of creating a server-based local development model that translates 100%, without friction, to production servers.

Simple example, I do all my web development work either using a Linux server VM on my Windows machine or a Linux server on our network. These days, running a VM with whatever flavor of Linux isn't a problem for anyone. Django could, out of the box, come with such an arrangement for local development. Perhaps in the form of an Ansible script.

I would want to see at least two development scenarios supported. The first would be as close to bare metal as one might want to get (say, Linode) and the other should be setup to work on something like a GoDaddy multi-hosting VPS.

This would allow for frictionless transition from local development to production deployment for a huge class of sites. Anyone doing anything more complex than that would have the time and maybe even the engineers to devote to designing and deploying a complex infrastructure with multiple kinds of servers, load balancing, etc.

Bottom line is, I think "runserver" is a neat trick but it likely ends up causing far more frustration than might be obvious. I have spoken to a number of people who tried Django, liked it, and moved on in frustration when they hit a brick wall when they had to figure out deployment.

I like to say that people don't go to the hardware store to buy a drill bit. What they are after is a hole. It's the same with websites. Nobody needs a Django website. Nobody. There are a bunch of alternative technologies out there. Which means that if Django makes "getting a hole" difficult, people will just move on. They don't want to become experts in manufacturing drill bits, they just want a hole.