[peterpostman]

A couple of years ago(2014) I made my first Python website and really enjoyed, however when it was time to put it onlin I quickly discovered that setting up hosting and configuring it was as large a task in getting to know pip, env, unicorn, apache2 and a plethora of other software to host it, is this still the case? Becaue this is what keeps me of hosting websites with python.

[illnewsthat]

I had similar issues with Django where I felt that running on localhost was fine, but getting it production ready was a headache.

Huge shoutout to dokku[1] which I used on my latest deployment and it makes it super easy. Lets encrypt support was the easiest I've seen and you redeploy with git push.

[1] https://dokku.com/docs/getting-started/installation/

[dopeboy]

This was a huge pain for me in the past to the point that I started maintaining a boilerplate to avoid it [0]. But I've heard so many good things about dokku that I think I'll give them a try soon.

0 - https://github.com/dopeboy/django-react-docker-heroku

[robomartin]

Interesting.

How does dokku work with regards to mixed multi-hosting (Apache virtual hosting) on a server?

For example, you have five sites, three are PHP and two are Django. Can it deal with that?

Also a neat "for free" feature of CPanel hosting is that you get super easy email hosting. This can save a lot of money for small and medium businesses. While some would be interested in using Django on these systems, it is in a range between painful and impossible.

This means that you have to now switch to a single-app/domain-per-server scenario (like, Heroku) which is expensive. And then spend more money to host your email elsewhere.

Frankly, this has been one of the largest sources of friction for me with Django. I love the framework and would like to use it exclusively but the transition from local development to deployment can be daunting.

[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.

[illnewsthat]

I am definitely not a dokku expert (for that I would recommend reaching out to their Slack channel[1] - a lot of great support for an open source project).

But in an attempt to answer your questions:

- Yes, you can host multiple sites on one server in dokku.

- That's a good point, I'm sure a lot of people like that about CPanel hosting. Maybe something like this poste.io implementation[2] would be what you are looking for?

- Dokku has the benefits of heroku but without the vendor lock in/pricing. Pick your preferred VPS host that runs for a few dollars a month and you are set.

[1] https://dokku.com/docs/getting-started/where-to-get-help/#th...

[2] https://github.com/D1ceWard/dokku-posteio

[ahmedfromtunis]

I was in a similar position a few years ago too, until I forced myself to learn Docker.

Now, all my projects are started from the same building blocks: Docker + Django + Gunicorn + Nginx + Postgres. And I love it.

Now I have traefic at the top of My to-learn list so that I can host multiple projects in the same VPS.

Last weekend I learned to use 11ty — the first static site generator I managed to grasp — and I'll entend to use that for projects that don't need this level of "complexity".

[codethief]

> Now I have traefic at the top of My to-learn list so that I can host multiple projects in the same VPS.

Traefik is very cool! Just please don't fall into this trap here, like everyone else: https://github.com/traefik/traefik/issues/4174

[williamdclt]

If you don't want to go the docker route, there's a few Django boilerplates around with an Ansible configuration

[bjourne]

> Now I have traefic at the top of My to-learn list so that I can host multiple projects in the same VPS.

Why do you need that? Nginx dispatches based on the domain name so you can easily host multiple Django sites on the same vps. I use the same tech stack as you except with uwsgi instead of Gunicorn.

[Sileni]

At least with pip and env, you'd have a hard time doing general tasks in python without getting to know them anyway.

You can also shortcut a lot of that with a hosting service like Heroku, which takes on a lot of the mental overhead for you.

You've made me curious to ask, what programming environments don't have a significant learning curve when you get to the hosting portion, short of a "no-code" hosting solution?

[chipotle_coyote]

PHP. Deploying small-to-medium PHP projects to production has historically been "move these files to your web root, initialize/seed your database if you have one, and that's it." It's really easy to underestimate how valuable that is in certain contexts, and how much that's contributed to PHP virtually owning the low end of the market.

My assumption was always that other languages would find a way to get closer to that model -- never quite to that level for various technical considerations, but close. I'm not sure any really have, save, as you noted, through dedicated hosting services. Fortunately, though, modern PHP frameworks have come to the rescue by becoming far more difficult and fiddly, to the point where both Symfony and Laravel's online tutorials begin with installing Docker.

[hallman76]

> You've made me curious to ask, what programming environments don't have a significant learning curve when you get to the hosting portion, short of a "no-code" hosting solution?

With java you can deploy a "fat jar" - a single executable that contains everything it needs, including the web server. You start the jar, it binds to a port, and you're done.

[EmilStenstrom]

I recognize this from some years ago, but it's not an issue any longer, as long as you go to a modern host (ie. Heroku). The old "optimized for PHP"-hosts still make things hard of course...

[number6]

Having set up some php servers myself: it's not a lot harder to host a python app. It is mostly the that hosters have optimized for php but you could do the same for python

[canadapups]

I just migrated to PythonAnywhere.com and it was a breeze. They also have browser access to command line, REPL, Jupyter notebooks too.

[airstrike]

You can always shortcut things by using Docker

[collyw]

Adding an extra layer doesn't make things simpler. It may make it easier to do a second time, but the initial set up is just the same.

[dangerbird2]

You'll still have to configure gunicorn or another production-ready (w|a)sgi server to serve the app out of the container, but it's much easier to manage dependencies for django in a containerized environment. It's even easier if you use a deterministic package manager like pipenv or poetry instead of old requirements.txt files