iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Antihost offers Linux VPS plans with full root access, unlimited traffic on a 1 Gbps port and a 14-day free trial.
The error almost always means the process starting your Django app cannot see a usable Django installation. Your generated wsgi.py imports django.core.wsgi; if systemd, Supervisor, Gunicorn, uWSGI, or mod_wsgi uses a different Python interpreter or virtual environment than your shell, that import fails. Verify the exact service interpreter first, install the project dependencies into that environment, test the import directly, and then correct the WSGI module path or settings configuration if the traceback moves on to a different module.
What “No module named django.core.wsgi” actually means
A Django project created with startproject contains a WSGI module similar to this:
PC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minute
from django.core.wsgi import get_wsgi_application
application = get_wsgi_application()Gunicorn and other WSGI servers import that module to obtain the application callable. The django.core.wsgi package is part of Django itself, so a failure at that exact import normally points to the Python environment rather than to a missing file in your project.
There are four common explanations:
- The service is using a Python interpreter or virtual environment where Django was never installed.
- Django is installed, but the installation is damaged or incompatible with the interpreter running the service.
- A project file or directory named
djangois shadowing the real package onsys.path. - The first line shown in a shortened log is misleading: Django imported successfully, and a later traceback line is the real failure.
Do not assume that a successful python command in your SSH session proves the service can import Django. A system service may call a different absolute executable, use a different working directory, or start Gunicorn from another virtual environment.
#1 Best Overall
Use this order to isolate the fault
Run the checks in this order. Stop at the first failed check, fix it, and repeat the next check with the same interpreter.
- Find the exact Python or Gunicorn executable used by the process manager.
- Ask that interpreter which Django package, if any, it can see.
- Install the project’s requirements into that same environment.
- Test
django.core.wsgiwith a one-line import. - Check the generated WSGI file and
DJANGO_SETTINGS_MODULE. - Correct the project package path, working directory, or Python path.
- Restart the service and read the complete traceback, not only its first line.
1. Identify the interpreter that really starts Django
Find the launch command before changing packages. Installing Django into the wrong environment can leave the production error unchanged.
Quick wins for a faster PC:
Scan for outdated or missing drivers - takes under a minuteDriver Scan →Repair Windows errors before they cause bigger problemsFix Now →systemd
Inspect the unit and any drop-in overrides:
sudo systemctl cat your-django.service
sudo systemctl show your-django.service -p ExecStart -p WorkingDirectory -p EnvironmentLook for an absolute command such as /srv/myapp/venv/bin/gunicorn and a WorkingDirectory. The Python interpreter associated with a virtual-environment Gunicorn is normally the interpreter in that same venv/bin directory. If ExecStart invokes a wrapper script, inspect the script too; it may select another Python executable.
Supervisor
Open the applicable Supervisor program configuration and record its command, directory, environment, and any user-specific path settings. A command that says only gunicorn depends on Supervisor’s PATH; an absolute path removes that ambiguity.
Shell-launched Gunicorn or uWSGI
From the deployment account, inspect both commands:
command -v python
command -v gunicorn
python -c "import sys; print(sys.executable)"
gunicorn --versionThese values describe your current shell, not necessarily a daemon started by systemd or Supervisor. Compare them with the executable recorded in the service configuration.
Free tools Windows power users keep installed
One-click scans. No signup required.
Apache and mod_wsgi
mod_wsgi is compiled for a particular Python installation. The Python used to build or load the module can differ from the virtual environment where you ran pip install Django. Check the Apache module and daemon configuration, including any python-home, python-path, or WSGI process-group settings, and make sure they refer to the same Python family and project environment.
2. Verify Django with the service’s exact Python
Change to the project directory, then call the interpreter directly. Activation is optional; using an absolute path is safer for diagnosis.
cd /path/to/project
/path/to/venv/bin/python -m pip show Django
/path/to/venv/bin/python -c "import django; print(django.get_version(), django.__file__)"If your service uses a different interpreter, substitute that exact path. The first command should show an installed Django distribution, its version, and its location. The second should print a version and a file path inside the intended environment.
When pip show reports nothing
Django is absent from that environment. Install the dependencies from the file used to deploy the project:
/path/to/venv/bin/python -m pip install -r requirements.txtIf the project uses another documented dependency file, use it instead. The important detail is python -m pip: it binds pip to the interpreter you just identified, avoiding a global pip executable that belongs to another Python installation.
When Django is shown but the import still fails
Inspect the reported location. A path outside the intended virtual environment may indicate a system package, a stale deployment, or a different interpreter than the one you thought you tested. Confirm the executable again:
/path/to/venv/bin/python -c "import sys; print(sys.executable); print('n'.join(sys.path))"Look in the project directory for names that can shadow the package:
find . -maxdepth 2 ( -name 'django.py' -o -type d -name 'django' ) -printRename or remove an accidental django.py file or django/ directory that is not the installed framework package, then repeat the import test. Also check for a partially copied or damaged virtual environment; recreating it from the project’s dependency file is often safer than repairing individual files.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
3. Test the failing import directly
Run this exact test with the interpreter that starts the service:
/path/to/venv/bin/python -c "from django.core.wsgi import get_wsgi_application; print('django.core.wsgi OK')"- It prints
django.core.wsgi OK: Django’s package import works. The remaining problem is later in the traceback, usually the project module, settings module, or working directory. - It raises
No module named djangoorNo module named django.core: the service environment lacks a usable Django installation, or a shadowing path is taking precedence. - It raises a different Django import or compatibility error: inspect the complete exception and verify that the installed Django version supports the project’s Python version and dependencies.
This one-line test separates an environment/package fault from a project-configuration fault before you change Gunicorn options.
4. Check the generated WSGI module and settings name
Open the project’s WSGI file. It should set the settings module and expose an object named application, for example:
import os
from django.core.wsgi import get_wsgi_application
os.environ.setdefault('DJANGO_SETTINGS_MODULE', 'project.settings')
application = get_wsgi_application()Replace project.settings with the actual Python package and settings module in your project. The value is a dotted Python import path, not a filesystem path. If your settings are split into a package, it may be something such as project.settings.production, provided that module really exists.
A WSGI server must import the settings module named by DJANGO_SETTINGS_MODULE. A wrong value produces errors such as No module named project.settings after Django itself has loaded. That changed error is useful evidence: it means the original Django import is no longer the blocker.
5. Make the project package importable
Gunicorn’s target has the form module:callable. For a conventional project, the target is:
project.wsgi:applicationproject must be the Python package containing wsgi.py, not necessarily the name of the outer checkout directory. For example, if the files are under /srv/shop/siteconfig/wsgi.py, the target may be siteconfig.wsgi:application, even if the repository directory is called shop.
Start Gunicorn from a directory where that package is importable, or specify the directory explicitly:
/path/to/venv/bin/gunicorn --chdir /path/to/project project.wsgi:applicationThe exact paths and package name depend on your layout. If the application code is in a src directory, the --chdir value or Python path must make the directory containing the package visible. In package layouts that require it, confirm that the project package contains __init__.py.
6. Configure a supervised Gunicorn service consistently
Keep the interpreter, working directory, target, and environment aligned in one service definition. A typical command uses the virtual-environment executable directly:
/srv/myapp/venv/bin/gunicorn --chdir /srv/myapp project.wsgi:applicationIf the service relies on an environment file or an explicit variable, ensure it supplies the same settings module used by wsgi.py. After editing a systemd unit, reload its definition and restart it:
Recommended Free Tools
sudo systemctl daemon-reload
sudo systemctl restart your-django.service
sudo systemctl status your-django.service --no-pager
sudo journalctl -u your-django.service -n 100 --no-pagerRead the full traceback from the journal. If it now says No module named project, the Django installation is working and the service’s directory or Python path is wrong. If it says No module named project.settings, correct DJANGO_SETTINGS_MODULE or the settings package. Do not revert the Django fix simply because the visible error changed.
7. Recognize the failure patterns that cause this message
| Symptom | Likely cause | Corrective action |
|---|---|---|
pip install Django succeeds, service still fails |
Django was installed globally while the daemon uses a virtual environment | Run /path/to/service/python -m pip install -r requirements.txt and test with that same executable |
| Shell import works; systemd import fails | Different ExecStart interpreter, PATH, or working directory |
Inspect the unit and use absolute executable and project paths |
| Django path points into an unexpected directory | Stale environment, wrong checkout, or another Python installation | Confirm sys.executable, django.__file__, and rebuild the intended environment if necessary |
| Import resolves to a project file or local directory | django.py or django/ shadows the framework |
Rename the local object and retest sys.path |
Error changes to No module named project |
Django now imports; project package is not on the Python path | Use the correct package name and --chdir, working directory, or Python path |
Error changes to No module named project.settings |
Wrong settings module or missing settings package | Correct DJANGO_SETTINGS_MODULE and verify the dotted module exists |
| Only Apache/mod_wsgi fails | mod_wsgi was built for a different Python installation | Align mod_wsgi’s Python, virtual environment, daemon settings, and project path |
| Target names an outer folder rather than the package | Filesystem checkout name was used as the Python module | Use the package containing wsgi.py, for example project.wsgi:application |
8. If you are choosing a deployment interface
Django supports both WSGI and ASGI interfaces. The choice does not change the need to use the correct interpreter and import path, but it changes the callable and concurrency model.
| Path | Interpreter and environment concern | Module configuration | Operational considerations |
|---|---|---|---|
| Gunicorn with WSGI | Gunicorn and Django must come from the same virtual environment | Usually project.wsgi:application; working directory must expose project |
Process supervision, restart policy, and logs are normally supplied by systemd or Supervisor |
| uWSGI with WSGI | uWSGI’s Python plugin/build must match the Python installation containing Django | Set the WSGI module and Python path in its configuration | Check its emperor or service logs and verify the configured chdir |
| Apache with mod_wsgi | mod_wsgi is tied to the Python used to build it; a separate shell virtualenv may not apply | Configure the WSGI script, daemon process group, Python home, and Python path consistently | Inspect Apache’s error log and restart Apache after configuration changes |
| ASGI server | Use the interpreter containing Django and all ASGI dependencies | Use the project’s ASGI module and application callable rather than a WSGI target |
Confirm that the server mode matches the application’s synchronous or asynchronous requirements |
Do not switch interfaces merely to hide an import error. First prove that the chosen interpreter can import Django and the project module.
9. Restart, inspect, and validate the repaired deployment
Once the direct import and project import work, restart the process through the same supervisor that normally runs it. Check both service status and logs immediately so you capture the complete startup traceback.
- Confirm the service is running as the intended user; permissions can prevent access to the virtual environment or checkout.
- Confirm the configured working directory still exists after a release or symlink switch.
- Confirm the service’s environment contains the intended
DJANGO_SETTINGS_MODULEand any required settings variables. - Check that the reverse proxy is reaching the restarted process rather than an old worker on another socket or port.
- Repeat the one-line
django.core.wsgiimport after deployment if the service uses a newly created virtual environment.
A successful process start does not by itself prove that the application is production-ready. Exercise a health endpoint or a representative page and inspect the application log for database, static-file, or settings errors that occur after WSGI initialization.
10. Complete Django’s production checks
After the import problem is fixed, run Django’s deployment checklist before exposing the VPS publicly. Review production settings, allowed hosts, secret management, database configuration, static and media file handling, HTTPS and secure-cookie settings, logging, and backup procedures. Django documents both WSGI and ASGI deployment interfaces and recommends completing its deployment checklist for production.
The import error is an application-startup problem; it does not validate those security and operational settings. Treat a clean WSGI import as one checkpoint in the deployment, not as a complete release test.
Practical prevention checklist
- Pin and record Django and other dependencies in the project’s dependency file.
- Install with
python -m pipusing the same absolute interpreter that the service launches. - Use absolute paths for Gunicorn, uWSGI, and other server executables in process-manager configuration.
- Set an explicit working directory or
--chdirso the Python project package is importable. - Keep the WSGI target in the
module:applicationform and verify the module name against the file layout. - Keep
DJANGO_SETTINGS_MODULEaligned with the actual settings package. - Avoid project files or directories named after third-party packages such as
django.py. - After each deployment, test the exact import with the service interpreter and retain the full startup logs.
Bottom line
django.core.wsgi is supplied by Django. When a VPS reports that it cannot find it, identify the interpreter used by the running service instead of the one in your interactive shell. Install the project requirements there, remove any shadowing module, and prove the import with a direct command. If that command succeeds, fix the project package path, working directory, or DJANGO_SETTINGS_MODULE; a new traceback naming your project usually means the original Django import problem is solved.
The Tool Desk
Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
