Remove all

LOADING ...

Content

How to Run a Django Server: 4 Methods for Development and Production

17.10.2025

4 minutes

142

Tags:

Django

Server

Hosting

Introduction

Depending on where and why, you can run the Django server in different ways. For example, we wouldn't run the Django server directly if we were deploying a site to a hosting server or VPS.

Also, to test the server's operation under conditions as close as possible to those experienced when deploying to a live server (DEBUG=False) + (ALLOWED_HOSTS=("localhost",)), you need to use completely different techniques for running the server.

In this article, I'll discuss how to run the Django server in various ways.

Normal server startup for development

This is how the Django server is launched, serving static files and responding to browser requests. By default, it does all this through port 8000, and the command looks like this:

python manage.py runserver

There is only one positional argument, the port number. It can be specified immediately after runserver:

python manage.py runserver 7000

Thus, our server will process only those requests that go to port 7000 and to the local address - http://localhost:7000.

How can changing the port for the development server be useful? It gives you some flexibility in integrating other applications or extensions. For example, there's a VSCode extension that automatically reloads a web page if it's changed. To do this, you'll need to tinker with ports and proxies.

If your Django project is built and configured correctly, but doesn't yet have its own view handlers, you should see something like this:

Or this, if you already have your own views and routing, plus correctly configured STATIC_URL and MEDIA_URL:

The point is all static files are received and served.

Starting the server to check the deployment readiness on the server

What I mean by this is, imagine this: you want to add and configure your own handlers and templates for 404 and 500 pages. But we all know what pages we'll get if we have a server error or a page not found:

And when we put the server into production mode, i.e., DEBUG=False plus ALLOWED_HOSTS=("*"), we'll get a page that we've pre-configured to display 404 and 500 errors, but without styles or scripts. This is what you'll see in the developer console:

The documentation states that when the server switches to production mode, Django stops processing and returning static data. And rightly so, this is the job of a web server like Apache or Nginx.

To continue processing static data while the Django server is running, you need to start the server like this:

python manage.py runserver --insecure

Now you can develop your own 400 and 500 pages without having to set up a real server :)

Running a Django server on shared hosting

To run on real web servers, Django doesn't need to be launched manually. For this purpose, every Django application supports special interfaces for working with them. These are:

WSGI (Web Server Gateway Interface) — It is a standard interface for synchronous communication between web servers and Python web applications, allowing them to work together.

ASGI (Asynchronous Server Gateway Interface) — It is a standard interface for Python web servers and applications that enables communication between them and supports both synchronous and asynchronous request processing.

Setting up Django applications for web servers can vary depending on the hosting provider, but wsgi.py will typically look something like this:

import os import sys activate_this = os.path.expanduser('~/bddt3.site/venv/bin/activate_this.py') exec(open(activate_this).read(), {'__file__': activate_this}) sys.path.insert(1, os.path.expanduser('~/bddt3.site/public_html/source/Website')) from django.core.wsgi import get_wsgi_application os.environ.setdefault('DJANGO_SETTINGS_MODULE', 'Website.settings') application = get_wsgi_application()

I can't speak for ASGI, I haven't worked with it yet.

Running a Django server on a VPS

To run a Django server on a VPS, you will need to first configure a web server such as Apache or Nginx so that they can handle requests to the server on a specific port:

server { listen 80; server_name bddt3.space; location /static { root /home/site/bddt3.space; } location /media { root /home/site/bddt3.space; } location / { proxy_set_header Host bddt3.space; proxy_pass http://unix:/tmp/bddt3.space.socket; } }

Example of configuring an nginx server for the HTTP protocol

Or, more recommended, use port 443, we are living in 2025 after all:

server { listen 443 ssl; server_name HOST_PLACE_SETUP; ssl_certificate /etc/letsencrypt/live/bddt3.space/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/bddt3.space/privkey.pem; location /static { root /home/USER_PLACE_SETUP/HOST_PLACE_SETUP; } location /media { root /home/USER_PLACE_SETUP/HOST_PLACE_SETUP; } location / { proxy_set_header Host HOST_PLACE_SETUP; proxy_pass http://unix:/tmp/HOST_PLACE_SETUP.socket; } }

Plus a permanent redirect from port 80:

server { l isten 80; server_name HOST_PLACE_SETUP; location / { return 301 https://HOST_PLACE_SETUP$request_uri; } }

After that, you need to pass these requests to your Django application. To do this, it must be running. There also needs to be something that can connect web servers (Apache, Nginx) to your application. These are also called web server gateways, like Phusion Passenger or Gunicorn.

Since the server may reboot from time to time, the appropriate daemon/service is created when the server starts/reboots:

[Unit] Description=Gunicorn server for HOST_PLACE_SETUP [Service] Restart=on-failure User=USER_PLACE_SETUP WorkingDirectory=/home/USER_PLACE_SETUP/HOST_PLACE_SETUP/source/Website ExecStart= /home/USER_PLACE_SETUP/HOST_PLACE_SETUP/venv/bin/gunicorn --bind unix:/tmp/HOST_PLACE_SETUP.socket Website.wsgi:application [Install] WantedBy=multi-user.target

This script has substitution variables HOST_PLACE_SETUP and USER_PLACE_SETUP.

This is an example that connects an Nginx web server and a Django application via Gunicorn using unix sockets.

Conclusion

In this article, we looked at four possible ways to launch a Django server.

The first is a standard development run.
The second is a production server with static file support, also for development.
The third is a completely different approach to launching a Django server, using the WSGI and ASGI interfaces.
And the fourth method describes how to do the same thing, but with greater control and the use of reverse proxies.

If I've missed any special cases or examples that could be added to this article, I'd appreciate your comments and suggestions. （￣︶￣）↗　