I use docker extensively, personally. Modern web app frameworks, especially those in python and ruby, are super annoying (imo/ime) to operate on a bare metal host, because how pip/gem install dependencies by default is just a mess that's impossible to isolate. Pre-docker, I had no end of headache where touching any deployed thing broke all the other sites due to dependency garbage. Rbenv/pipenv/etcetc are language-specific, non-trivial band-aids and I don't like wasting brain cycles on them.

Docker makes it so easy to deploy and operate programs that I even use it for ecosystems that don't "need" it, like Java. Also makes backups super easy because it's just backing up the docker volumes.

Agreed, I once worked at a place that used saltstack to manage rails servers and it would take me an entire day to set up a new server with the tools it needs and getting the app running. Now with docker its so trivial to get something running on the server and even multiple versions of ruby for different apps.

It's not necessarily bad, but there's plenty of steps to automate away, with two ideas:

* You can use your production server as a "git server" without basically any overhead

* You can set up scripts that run on git events.

Basically, you can push directly to your production server and then deploy using that those event listeners

Here's a better explainer

https://tqdev.com/2018-deploying-with-git-push-to-production

As for having to reboot your server every time, I have no idea, although that seems like a long time. I'd expect less than a minute, but I don't know much about django

Other comments mention Docker and Kubernetes which feels like overkill for what you describe. Especially Kubernetes.

Check out bitbucket pipelines that trigger on a commit which should be able to build/run any tests, copy the code to your server, and then restart django.

From there you can later build a docker image and copy it to run wherever, etc...

Most decent CI tools will just clone the one branch needed for deploying and build/deploy from there. Cloning it fresh each time can rule out artifacts from past builds having an impact on the current deploy.

I used to do that before the introduction of docker+kubernetes. Once you've incorporated this into your solo workflow, you will never look back.