Articles

Fix Django "No Installed App with Label" Error (2026)

April 16, 2026 4 min read

This error means Django tried to find an app named X in your project’s INSTALLED_APPS setting, but it wasn’t there.

Here’s what’s likely broken and why:

The most common culprit is a simple typo in your INSTALLED_APPS setting. Django’s app registry is strict; myapp is not my_app.

Cause 1: Typo in INSTALLED_APPS

  • Diagnosis: Look at your settings.py file. Carefully compare the app names in your INSTALLED_APPS list against the actual directory names of your Django apps.
  • Fix: Correct the spelling. For example, if you have an app directory named users but it’s listed as 'user' in INSTALLED_APPS, change it to 'users'.
  • Why it works: Django uses these strings to look up and load your app configurations. An exact match is required.

Cause 2: App Directory Not in INSTALLED_APPS

  • Diagnosis: You’ve created a new app (e.g., python manage.py startapp myapp), but you forgot to add its name to the INSTALLED_APPS list in settings.py.
  • Fix: Add the app’s name as a string to INSTALLED_APPS. If your app is named myapp and located in the root of your project, add 'myapp' to the list. If it’s in a subdirectory like apps/myapp, you’d add 'apps.myapp'.
  • Why it works: Django only discovers and registers apps that are explicitly listed in this setting.

Cause 3: Using the App Directory Name Instead of the App Label

  • Diagnosis: Sometimes, especially with project structures where apps are in subdirectories (e.g., myproject/apps/users/), you might be tempted to use the full path in INSTALLED_APPS. However, Django expects the app label (usually the directory name), or the Python path to the app’s AppConfig.
  • Fix: Ensure you’re using the correct app label. If your app is at myproject/apps/users/, and users is the app directory, you should typically add 'users' or 'apps.users' to INSTALLED_APPS, assuming apps is a Python package and users contains an apps.py with AppConfig(name='users') or AppConfig(name='apps.users'). The most common and robust way is to specify the full Python path to your AppConfig class if you’ve defined one: 'apps.users.apps.UsersConfig'.
  • Why it works: Django’s app registry resolves these Python paths to locate the AppConfig and its associated models, views, etc.

Cause 4: Incorrect Project Structure / __init__.py Missing

  • Diagnosis: If your app is in a subdirectory (e.g., myproject/my_app/), that subdirectory needs to be a Python package. Check if it contains an __init__.py file. If it doesn’t, Python won’t treat it as a package, and Django won’t be able to import your app.
  • Fix: Create an empty __init__.py file inside your app’s directory (e.g., myproject/my_app/__init__.py).
  • Why it works: The __init__.py file signals to Python that the directory should be treated as a package, allowing modules within it to be imported.

Cause 5: AppConfig Name Mismatch

  • Diagnosis: If you’ve defined a custom AppConfig in your app’s apps.py (e.g., class MyCustomConfig(AppConfig): name = 'my_app'), but then listed just the app name ('my_app') in INSTALLED_APPS, Django might get confused if it expects a specific AppConfig. More likely, if you’ve specified the AppConfig explicitly in INSTALLED_APPS (e.g., 'my_app.apps.MyCustomConfig'), but the name attribute within MyCustomConfig is wrong, this error can occur.
  • Fix: Ensure the string in INSTALLED_APPS correctly points to your AppConfig class, or if you’re using the default AppConfig, ensure it’s correctly named and located. If you are using a custom AppConfig like my_app.apps.MyCustomConfig, verify that my_app/apps.py has class MyCustomConfig(AppConfig): name = 'my_app' (or name = 'my_app.apps.MyCustomConfig'). Often, just 'my_app' is sufficient if my_app/apps.py contains class AppConfig(AppConfig): name = 'my_app'.
  • Why it works: Django uses the INSTALLED_APPS entry to find and instantiate your app’s configuration class, which is the entry point for Django’s knowledge of your app.

Cause 6: Circular Dependencies

  • Diagnosis: While less common for this specific error message, complex project structures with circular imports between apps can sometimes manifest in strange ways during Django’s startup. If apps A and B both depend on each other directly or indirectly, Django’s app loading process might fail.
  • Fix: Refactor your code to break the circular dependency. This might involve moving shared functionality to a new, common app, or restructuring how your apps interact.
  • Why it works: Python’s import system (and by extension, Django’s app registry) struggles with circular imports, leading to incomplete initialization.

After fixing these, you’ll likely encounter a NameError or AttributeError if you had other issues related to models or views that were meant to be loaded by the now-found app.

Want structured learning?

Take the full Django course →