Django Web App Hosting

We provide hosting for websites built in Django.

I picked the image above for two reasons: 1) there is a movie called "Django" that seems to have a western theme, and 2) hosting a Django application feels a bit like wrangling large animals and driving them through the plains and up canyons. Wrangling is a lot of work, but In the end, it's all worth it.

It takes courage to build and host a Django site. Just remember what John Wayne says:

Courage is being scared to death, but saddling up anyway.

Will you jump in the saddle?

If you are a developer, then we can help you setup a Git deployment to our servers.

If you are a business owner, then we can build the site for you.

Keypoints

• John Wayne Quotes
• Django is a Great Web Framework
• Multiple Methods for Serving up Django
• Asynchronous is Available
• Our Hosting Environment uses FreeBSD

Django for the Uninitiated

If you haven't been introduced to Django yet, then you might consider giving it a look. From the project docs, "Django is a high-level Python web framework that encourages rapid development and clean, pragmatic design."

There are a number of benefits to using Django, such as easily building related database models, simple URL handling, and complete flexibility.

If I was to give a simple definition of what Django is, I would say, it's a framework to quickly build the database-driven site that you want.

LTS

Since Django is open source, the project website has a nice planned out schedule of releases of the upcoming Django versions, including the Long Term Support (LTS) releases. Currently 4.2.x is the LTS, and that is what I recommend to use. The next LTS release (5.2) is expected in April of 2025, so anything deployed before that time should probably stick with 4.2.

The nice thing about LTS versions of software, is that you can keep the same "version" of something, and it remains compatible with the other components it is tied to, while still receiving security updates.

Serving it Up

The Django documentation is quite nice to refer to when one has a question. You can find all sorts of deployment information on their website. There is two ways to deploy a Django application:

• WSGI (Web Server Gateway Interface)
• ASGI (Asynchronous Server Gateway Interface)

Both methods have various software options for running your Django app. So we'll look at a couple of the options.

uWSGI

uWSGI is the main program I use to deploy Django applications. You might notice that uWSGI implements WSGI, not ASGI. However, this is typically not a problem for most sites I work on, especially since you can specify the amount of worker processes a uWSGI server allows. I do vote for async servers (when appropriately fitted), as there seems to be good evidence that they are effective.

Our servers mainly operate using FreeBSD, and there is a convenient package called uwsgi which offers a service to run Python based applications. We configure and deploy the configuration file for the application on our principal server(s), and then link the incoming proxies to the app.

This is all great, however, there is another part to the equation: the "static" (css, javascript) and "media" (images, pdf's) files, related to the Django site. Depending on the needs of the site, the configuration will look different. Sometimes the files are served up by uWSGI as well, but more preferably, they are served up by the web server as static files. There is also an option to utilize an S3-compatible object storage, such as MinIO or some other service. If that is the case, then the files are stored separately from the website files.

Gunicorn

Gunicorn is a popular method to deploy Django apps. If you're also confused about the name, the package index gives a description:

Gunicorn ‘Green Unicorn’ is a Python WSGI HTTP Server for UNIX. It’s a pre-fork worker model ported from Ruby’s Unicorn project. The Gunicorn server is broadly compatible with various web frameworks, simply implemented, light on server resource usage, and fairly speedy.

The documentation for it strongly recommends using Gunicorn behind a proxy server. Fortunately all of our deployments are behind a proxy server (currently we use Nginx).

Here are some of its features:

• Natively supports WSGI, Django, and Paster
• Automatic worker process management
• Simple Python configuration
• Multiple worker configurations
• Various server hooks for extensibility
• Compatible with Python 3.x >= 3.7

Don't Forget ASGI (Async)

One of the immediate wins when using Python is that many times you have the option to utilize async. "Async" is short for asynchronous, which is a modern programming technique to take advantage of the wait times between multiple tasks, thus potentially speeding up an entire group of tasks.

For asynchronous (ASGI) deployments of Django applications, there is a few options:

• Daphne
• Hypercorn
• Uvicorn

Hosting Environment

I've mentioned in the past, but I'll mention it again; our servers run on FreeBSD (and OpenBSD). FreeBSD is a strong operating system with a traditional Unix feel, yet modern tools. We utilize FreeBSD because of ZFS and Jails. So there is a couple things to point out:

Docker

I have used docker (and podman) for years, and I have deployed databases, Django apps, frontends, VPN servers, redis, and other tools using container runtimes. I got really into it for a time, learning about containerizing even without a runtime like docker or podman.

However, our hosting service doesn't implement Docker very heavily. For our own stuff, instead of "containers", we setup "jails" on FreeBSD servers. Similar concept, but different implementation.

Docker provides a "nice" way to deploy applications. FreeBSD provides a "sane" way to deploy applications. :-)

Regardless, some of our work is on Linux servers, so we keep our containerizing skills close at hand, so we can ninja through the setup for remote servers.

Jails

The concept of a "jail" or "container" may have started with the traditional Unix "chroot" utility. The idea is that you could section off a part of the filesystem, so a process only knows certain things. A "jail" is like a super chroot, and it can have it's own network stack (or not, depending on the setup), its own software libraries, files, etc. A jail feels similar to a virtual machine, yet it doesn't require emulation.

When we deploy jails, we keep them a bit more persistent than a usual Linux container is expected to be. We also provide custom software or libraries along with the Django installation, to provide greater functionality.

Let's Talk Deployment

Whether you are looking to get your django site hosted by us, or if you just need a hand with your current deployment, please reach out to us. Our years of experience operating servers and building Django sites gives us an advantage to quickly assess a deployment, and get all the right moving pieces in the right spots.

Valete!