Why I Left WordPress Behind for Django, Gunicorn, and Nginx

Recently, I made the decision to overhaul the infrastructure of this blog from WordPress to Django, and I wanted to share some of the technical challenges that came about from this change, and also why we left WordPress behind.

First and foremost, I am a great fan of WordPress because of the reputation that it has. It is easy to use and has a very active community of developers. I originally chose WordPress because AWS Lightsail offered a way to create a blog with just a few clicks, and also because I am familiar with the system.

The issue, however, was that I was a bit unfamiliar with the infrastructure that was running this blog when I initially set it up, and I wanted to have a bit more control over what I was doing so that I could learn more about AWS cloud computing.

That is why I chose to basically do an entirely new iteration of Rootaccess, which you can see now on the website. Getting the new website up and running took me about two days. This included the development stage of the new website and also setting up the infrastructure so that it is live and ready to be seen by readers such as you.

The process to get the new blog live came with a host of problems, some of which were easily resolvable, while others were a bit more complicated. Thankfully, Django has a robust community, and there are a lot of different help articles available. In particular, I used the guideline from

Cloning the code

After I finished development for my blog and had it ready in a way that I felt satisfied with, I uploaded the code to a private GitHub repository so that it would be ready to be pulled onto the production server. I then went into the Ubuntu Server box, created a new directory, and pulled in the code from GitHub so that I had it running and locally available.

Ubuntu Server 22.04 came with Python already installed, along with other tools, so after creating the virtual environment, I was able to install the requirements and open a local test environment, and I confirmed everything to be working as intended.

Setting up the infrastructure

The next challenge that we had was setting up the infrastructure of the blog. I was spoiled by the fact that my WordPress site was pretty much set up with a few clicks. However, I did not have that luxury when it came to setting up the new blog.

Django has many ways to set it up, as you can use Apache or many other variants. What I decided to go with was Gunicorn and Nginx, and the reason behind this was purely based on my interests in learning about Web Server Gateway Interfaces and also Reverse Proxies.

What I like about Gunicorn is that it was not hard at all to set up. You simply need to install it inside the virtual environment, point it at the WSGI file that Django already generates for you, and then run it against a local port to confirm that it can actually serve the application. Once I saw that working, I created a systemd service file so that Gunicorn would start on its own whenever the server boots and restart itself if something went wrong, because babysitting a process is not something I wanted to add to my list. From there, Nginx sits in front of everything as the reverse proxy. It takes the incoming traffic on ports 80 and 443, hands it off to Gunicorn through a socket, and also serves the static files so that Django does not have to worry about them. Getting the permissions right between the two took a bit of trial and error, but once that clicked, everything came together and the blog was live.