The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →“No module named django.core.wsgi” almost always means the VPS service is using a Python environment where Django is missing, damaged, incompatible, or hidden by a local file named django.py or a django/ directory. The fix is to identify the exact interpreter launching Gunicorn, uWSGI, mod_wsgi, or systemd; install and test Django with that interpreter; then correct the WSGI module path and settings configuration if the traceback moves on to a project-specific error.
Antihost offers Linux VPS plans with full root access, unlimited traffic on a 1 Gbps port and a 14-day free trial.
The import comes from the WSGI file generated by Django’s startproject command:
As an Amazon Associate I earn from qualifying purchases.
Recommended Free Tools
from django.core.wsgi import get_wsgi_application
application = get_wsgi_application()Follow the checks below in order. Do not rely on the python or pip commands in your interactive shell unless they are the same executables used by the production service.
What the error actually means
django.core.wsgi is a module inside the Django package. It is not a package that should be installed separately. When Python reports No module named django.core.wsgi, it failed while evaluating the standard import in your project’s WSGI entry point.
#1 Best Overall
The import chain
A WSGI server loads a Python module such as project.wsgi. That file imports get_wsgi_application from Django, then creates the callable named application. Django uses the DJANGO_SETTINGS_MODULE environment variable to locate your settings module. A failure at django.core.wsgi occurs before Django can load your project settings, so the first suspect is the interpreter or Django installation used by the service.
Read the whole traceback
Python prints the import that was being attempted first, but the final exception can reveal a later, more useful cause. For example, after Django is installed correctly, the error may change to No module named project or No module named project.settings. That change is progress: Python can now import Django, and the remaining problem is the project path or settings configuration.
Windows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallCrashes, 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 minuteRepair the environment in a controlled sequence
-
Find the interpreter that actually runs your service
Inspect the command used by the process manager rather than guessing from your shell. For a systemd service, display the unit and its expanded configuration:
sudo systemctl cat myproject.service sudo systemctl show myproject.service -p ExecStart -p WorkingDirectory -p EnvironmentLook for an absolute Gunicorn or Python path, such as
/srv/myproject/venv/bin/gunicorn. Supervisor configurations usually contain acommand=,directory=, and optionalenvironment=line. Apache/mod_wsgi uses the Python installation against which its module was compiled; the web server may therefore use a different interpreter from your shell. If you start Gunicorn manually, record the exact executable and current directory. -
Run Django checks with that exact Python executable
Use the virtual environment’s Python directly. Calling it by absolute path avoids activating a different environment in the current shell:
cd /srv/myproject /srv/myproject/venv/bin/python -m pip show Django /srv/myproject/venv/bin/python -c "import sys; print(sys.executable); import django; print(django.get_version()); print(django.__file__)"pip showshould identify an installed Django distribution and its location. The second command prints the interpreter, Django version, and file path that Python imported. If it raisesModuleNotFoundError: No module named 'django', Django is absent from this environment. If the reported path points into an unexpected virtual environment or checkout, the service and your shell are not using the same installation.Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.If the service invokes
gunicornwithout an absolute path, check which executable would be selected in its environment:command -v gunicorn head -n 1 "$(command -v gunicorn)" /srv/myproject/venv/bin/python -m pip show gunicornThe shebang on the Gunicorn script should point to the same virtual environment whose Python contains Django.
-
Install the project dependencies into that environment
Use the same Python executable to run pip and install the dependency file declared by the project:
/srv/myproject/venv/bin/python -m pip install -r /srv/myproject/requirements.txtIf your project uses a different, documented dependency file, use that file instead. Installing with a global
pipcommand does not repair a virtual environment used by systemd or Gunicorn. Avoid mixing package managers or silently installing into a second checkout.Free tools Windows power users keep installed
One-click scans. No signup required.
Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.After installation, repeat:
/srv/myproject/venv/bin/python -c "from django.core.wsgi import get_wsgi_application; print('django.core.wsgi OK')"This is the decisive environment test. It exercises the exact import that failed without involving your project’s settings.
-
Check for a local module that shadows Django
Python searches the working directory and entries on
sys.path. A file nameddjango.pyor a directory nameddjangoin your project can hide the real third-party package. List suspicious paths and print Python’s import search path:find /srv/myproject -maxdepth 2 ( -name 'django.py' -o -type d -name 'django' ) -print /srv/myproject/venv/bin/python -c "import sys; print('n'.join(sys.path))"Rename the project file or directory if it is not the installed package, remove stale compiled files if appropriate, and rerun the exact import test. Do not delete the Django package from the virtual environment itself.
-
Validate the generated WSGI file
The WSGI file should resemble:
import os from django.core.wsgi import get_wsgi_application os.environ.setdefault('DJANGO_SETTINGS_MODULE', 'project.settings') application = get_wsgi_application()Replace
project.settingswith the real Python path to your settings module. It is a dotted import path, not a filesystem path and not the name of the parent directory on disk. The module must be importable from the service’s Python path.PerformanceWindows Errors? Fix Them Before They SpreadDriversCrashes, No Sound, or Screen Glitches?PerformancePC Slower Than It Used to Be?Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.Check the value independently:
cd /srv/myproject /srv/myproject/venv/bin/python -c "import os; os.environ.setdefault('DJANGO_SETTINGS_MODULE', 'project.settings'); import django; django.setup(); print('settings OK')"If this test reports a missing settings module, fix the dotted name, package layout, or working directory before restarting the service.
-
Use the Python package name in the server target
Gunicorn expects a module path followed by the WSGI callable, commonly
project.wsgi:application. It does not accept an arbitrary filesystem directory name unless that directory is also the importable Python package. A minimal command is:/srv/myproject/venv/bin/gunicorn --chdir /srv/myproject project.wsgi:applicationThe
--chdiroption makes the project package importable. Alternatively, configure the service’s working directory or Python path explicitly. If your repository has a nested layout, the correct command might need a different--chdirvalue and package name; verify it by importing the WSGI module directly:cd /srv/myproject /srv/myproject/venv/bin/python -c "import project.wsgi; print(project.wsgi.application)"A missing
__init__.pycan also prevent imports in layouts that rely on regular Python packages. Confirm that the project package and any required subpackages contain the files expected by your chosen Python and packaging setup.Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Scan for outdated or missing drivers - takes under a minute3Clear out junk files and repair common Windows errorsSpecial offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy. -
Restart the service and capture the complete traceback
For systemd:
sudo systemctl daemon-reload sudo systemctl restart myproject.service sudo systemctl status myproject.service --no-pager sudo journalctl -u myproject.service -n 100 --no-pagerFor Supervisor, restart the affected program through Supervisor’s control command and inspect its captured stderr/stdout logs. For Apache, inspect the configured error log after restarting or reloading the web server. Always read the final exception and its preceding import context. If the error has changed from
django.core.wsgito a project module, return to steps 5 and 6 rather than reinstalling Django again.
Make the service configuration unambiguous
Example systemd unit for Gunicorn
A unit should bind the executable, project directory, and environment together. Adapt names and paths to your deployment:
[Unit]
Description=Gunicorn service for the Django project
After=network.target
[Service]
User=deploy
Group=www-data
WorkingDirectory=/srv/myproject
Environment="DJANGO_SETTINGS_MODULE=project.settings"
ExecStart=/srv/myproject/venv/bin/gunicorn --workers 3 --bind unix:/run/myproject.sock project.wsgi:application
Restart=on-failure
[Install]
WantedBy=multi-user.targetThe important details for this error are the absolute Gunicorn path, WorkingDirectory, settings environment, and project.wsgi:application target. Worker count, socket location, and user permissions must match your server design; they do not install Django.
Supervisor
Set the same values explicitly in Supervisor: use the virtual environment’s Gunicorn in command=, set directory=/srv/myproject, and provide DJANGO_SETTINGS_MODULE in environment= when the WSGI file does not set it. A common mistake is pointing command= at one virtual environment while directory= references a different checkout.
Apache and mod_wsgi
mod_wsgi is tied to the Python installation used to compile that module. Installing Django into another virtual environment will not help if Apache is loading a mod_wsgi module built for a different Python. Verify the Python version and virtual environment configured for mod_wsgi, then install the project’s dependencies there or rebuild/use a compatible mod_wsgi setup. Check Apache’s error log for the interpreter and import path it reports.
uWSGI and other WSGI launchers
The same principles apply: identify the executable, virtual environment, working directory, module target, and settings variable. The server must import the Python object in project.wsgi:application; changing servers does not remove the requirement that Django be installed in the interpreter they use.
Common causes and targeted fixes
| Symptom | Likely cause | Targeted fix |
|---|---|---|
pip show Django is empty in the service environment |
Django was installed globally or in another virtual environment | Run python -m pip install -r requirements.txt with the service’s absolute Python path. |
| The import resolves to an unexpected directory | A different checkout or virtual environment is first on sys.path |
Correct the service executable, WorkingDirectory, and --chdir; verify django.__file__. |
| Import fails only from the project directory | A local django.py file or django/ directory shadows Django |
Rename the local item and retest the import. |
Django imports, then No module named project appears |
Gunicorn is starting outside the directory containing the project package | Use the correct --chdir, service working directory, or Python path and the package name in the target. |
No module named project.settings |
DJANGO_SETTINGS_MODULE is wrong or the package layout is incomplete |
Set the exact dotted settings path and verify package files and checkout location. |
| Shell tests pass but Apache fails | mod_wsgi uses a different Python installation | Inspect mod_wsgi’s compiled interpreter and install dependencies in that environment or use a compatible module. |
| One host works while another fails after deployment | The service unit, virtual environment, or checkout differs between hosts | Compare absolute paths, environment variables, dependency installation, and logs rather than copying only the source tree. |
Verify the project layout before changing code
From the directory specified by the service, you should be able to identify the package that contains wsgi.py:
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
cd /srv/myproject
find . -maxdepth 3 -name wsgi.py -print
find . -maxdepth 2 -type f -name '__init__.py' -printIf the file is at /srv/myproject/config/wsgi.py, the target is likely config.wsgi:application, not myproject.wsgi:application. The correct name is determined by the Python package directory, not by the VPS folder or Git repository name. Confirm with a direct import using the same interpreter and working directory as the service.
WSGI, ASGI, and choosing a deployment path
Django supports both WSGI and ASGI deployment interfaces. The import error discussed here concerns the WSGI path, but a deployment may use an ASGI server for asynchronous views or long-lived connections. Choose the interface that matches the application and existing web-server architecture; do not switch interfaces merely to conceal an environment error.
| Deployment path | Interpreter and environment concern | Module configuration | Operational considerations |
|---|---|---|---|
| Gunicorn with WSGI workers | Gunicorn and Django must come from the same virtual environment | Use a target such as project.wsgi:application and a correct --chdir |
Process supervision, restart policy, socket binding, and logs are normally managed by systemd or Supervisor |
| uWSGI | Its executable and Python plugin must see the environment containing Django | Configure the Python module and callable for the project package | Check emperor/worker logs and the configured working directory |
| Apache with mod_wsgi | mod_wsgi’s compiled Python is decisive; it may differ from shell Python | Set the WSGI script, Python path, and settings environment in Apache configuration | Use Apache error logs and reload the correct virtual host |
| ASGI server | The ASGI server still needs the project’s dependencies in its interpreter | Use the project’s ASGI module and callable rather than a WSGI target | Confirm that the reverse proxy and concurrency model support the application’s async requirements |
After the import works: complete the production checks
Getting past django.core.wsgi only proves that the service can import Django and, possibly, your project. Before exposing the VPS, run Django’s deployment checks with the production settings:
cd /srv/myproject
/srv/myproject/venv/bin/python manage.py check --deployReview warnings about secret keys, debug mode, allowed hosts, secure cookies, HTTPS, static files, database configuration, and any other settings relevant to your release. Confirm that the service user can read the project and virtual environment, write only to directories that require it, reach the database and cache, and access the socket or TCP bind address used by the reverse proxy.
Keep the full startup traceback available during the first restart after every configuration change. A new exception identifies the next layer to fix; reverting to a broad reinstall can hide that useful distinction.
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.
