Web Development · Tutorial
Full-Stack Setup: Python, Django, and React
Step-by-step guide to configuring a complete full-stack development environment with Python, Django backend, and React frontend.
Anurag Verma
5 min read · Updated Sep 3, 2026
Sponsored
Welcome to a comprehensive guide on setting up your full-stack development environment with Python, Django, and React. This article is designed to provide step-by-step instructions to budding programmers and experienced developers alike. Let’s dive right in!
Step 1: Installing Python and Django
Python is a versatile language that’s great for back-end web development. Django, a Python-based framework, makes it easy to build solid and scalable web applications. If you haven’t already installed these tools, here’s how to do it.
-
Visit the official Python website and install the latest stable release. Django 5.x requires Python 3.10 or newer (see Django’s own installation requirements), so do not reach for an older interpreter just because a tutorial mentions one.
-
We recommend using a virtual environment for your Python projects to avoid dependency conflicts. Python’s built-in
venvmodule makes this a breeze. Here’s how to create a new virtual environment:
python3 -m venv myenv
-
To activate the virtual environment:
-
On Windows:
myenv\Scripts\activate -
On Unix or MacOS:
source myenv/bin/activate
-
-
With your virtual environment activated, install Django using pip, Python’s package manager:
pip install django
Step 2: Creating a Django Project
Now that we have Django installed, let’s create a new Django project:
django-admin startproject ProgrammersPost
You can replace “ProgrammersPost” with your preferred project name.
Step 3: Installing Node.js and npm
Node.js is a runtime that allows you to run JavaScript on your server, while npm is a package manager for JavaScript. To install these:
-
Visit the official Node.js website and install the current LTS release. Node 14 reached end of life in April 2023, so anything on that line no longer receives security patches.
-
Verify your installation by running the following commands in your terminal:
node -v
npm -v
Step 4: Creating a React Application
React is a popular JavaScript library for building user interfaces, especially single-page applications. Follow these steps to create a new React application:
- Create React App is deprecated and the React team removed it from the official docs, so scaffold with Vite instead. There is nothing to install globally:
npm create vite@latest programmerspost-client -- --template react
- Next, create a new React application:
cd programmerspost-client && npm install
Replace “programmerspost-client” with your preferred app name.
Step 5: Connecting Django and React
At this point Django and React exist as two unconnected projects. They run as separate processes on separate ports in development, Django on 8000, Vite on 5173, and the browser blocks a request from one to the other as cross-origin unless you tell it otherwise. That’s a CORS error, and it’s the next thing every fresh Django + React setup runs into.
Install django-cors-headers in the Django project:
pip install django-cors-headers
Add it to INSTALLED_APPS and MIDDLEWARE in settings.py, then allow the Vite dev server’s origin:
INSTALLED_APPS = [
# ...
"corsheaders",
]
MIDDLEWARE = [
"corsheaders.middleware.CorsMiddleware",
# ... keep this above CommonMiddleware
]
CORS_ALLOWED_ORIGINS = [
"http://localhost:5173",
]
On the React side, point requests at Django’s port instead of a relative path, since the two apps are not sharing one:
fetch("http://localhost:8000/api/hello/")
.then((res) => res.json())
.then((data) => console.log(data));
If you’re building the API itself rather than just calling it, Django REST Framework versus FastAPI is worth reading before you commit to a serializer layer. And if Vite’s config or plugin ecosystem is new to you, the modern Vite and Vitest toolchain covers what changed since Create React App.
In production, the CORS problem usually disappears rather than needing a more permanent fix: either Django serves React’s built static files directly, so there’s only one origin, or both sit behind the same reverse proxy domain. CORS is a development-only headache for most Django + React setups, not something you carry into deployment.
Running Both Servers Without Two Terminal Tabs
Day to day, you need Django and Vite running at the same time, which means either two terminal tabs or one process that starts both. The concurrently npm package handles the second option well enough for local development:
npm install --save-dev concurrently
"scripts": {
"dev": "concurrently \"python manage.py runserver\" \"npm run dev --prefix ../programmerspost-client\""
}
Run npm run dev from wherever that script lives, and both processes start together with their output interleaved in one terminal, which is enough for solo development, even though a real project usually graduates to a docker-compose.yml with a service per process once more than one person needs the same setup running reliably.
Two first-run errors are common enough to call out before you hit them. DisallowedHost on the Django side means ALLOWED_HOSTS in settings.py doesn’t include localhost or 127.0.0.1 for local development. And a blank page from Vite with a console error about a failed fetch almost always means the CORS setup above hasn’t been applied yet, or CORS_ALLOWED_ORIGINS doesn’t match the port Vite actually started on, worth checking directly in the terminal output since Vite silently falls back to the next free port, 5174 and up, whenever 5173 is already taken by another project.
None of this is specific to Django and React individually; it’s the standard shape of running any two dev servers side by side, one serving an API and one serving a frontend, and it’s worth internalizing once rather than re-debugging it fresh on the next stack.
And voilà! You have now set up a full-stack development environment with Python, Django, and React, and connected the two. With these powerful tools at your disposal, you’re ready to build scalable and efficient web applications. Stay tuned for more tutorials on developing with Python, Django, and React!
Frequently asked questions
- Do I really need a virtual environment?
- Yes, and it is the step people skip and regret. Without one, pip installs into your system Python, so two projects needing different versions of the same package cannot coexist and an upgrade for one silently breaks the other. venv ships with Python, creating one is a single command, and activating it changes nothing about how you work afterwards.
- What replaced Create React App?
- Vite, for most cases. The React team deprecated Create React App and removed it from the official documentation, because it had grown slow to start and hard to configure without ejecting. npm create vite@latest with the react template gives you a faster dev server, faster builds, and a config you can actually edit. If you want routing, data loading and server rendering handled for you, Next.js is the other direction the docs now point at.
- Which Python version should I install?
- The current stable release, unless something in your dependency tree specifically blocks it. Django 5.x requires 3.10 as a minimum, and tutorials written a few years ago naming 3.9 or earlier will fail at install time against a modern Django. Pin the version in the project so everyone on the team is on the same interpreter rather than whatever their machine happened to have.
- How do Django and React talk to each other in development?
- They do not, until you make them. They run as separate processes on separate ports, Django serving the API and Vite serving the frontend, so the browser treats a request from one to the other as cross-origin and blocks it. django-cors-headers is the usual fix: install it, add it to middleware, and allow your Vite dev server's origin. In production you either serve the built frontend from Django or put both behind one domain, and the problem goes away.
- Should the two live in one repository or two?
- One repository is simpler while the same people work on both, which is the usual case early on. You get atomic commits across an API change and its frontend consumer, and one place to clone. Split them when the deployment cadences genuinely diverge or different teams own each side, because at that point a shared repository starts forcing coordination that neither team wants.
Sponsored
More from this category
More from Web Development
Sponsored
Discussion
Join the conversation.
Comments are powered by GitHub Discussions. Sign in with your GitHub account to leave a comment.
Sponsored