The Django admin — the basics

A full working interface for managing your data, generated automatically from your models — one of Django's most famous "batteries included" features, and worth understanding rather than treating as magic.

Beginner

3 min read

What you get, for almost no work

# models.py
from django.db import models
 
class Article(models.Model):
    title = models.CharField(max_length=200)
    body = models.TextField()
    published_at = models.DateTimeField(auto_now_add=True)

# admin.py
from django.contrib import admin
from .models import Article
 
admin.site.register(Article)

Those two lines in admin.py are enough to get a complete web interface at /admin/ for creating, viewing, editing, and deleting Article rows — a real form generated automatically from the model's fields, a searchable list view, and basic validation, all without writing a single line of HTML or a view function. This is one of Django's most distinctive features: most frameworks make you build an admin interface yourself; Django generates a working one directly from the same model definition you already wrote for the database.

Setting it up: the one-time steps

python manage.py createsuperuser   # create the admin account you'll log in with
python manage.py runserver

createsuperuser prompts for a username, email, and password, then creates an account with full admin access. django.contrib.admin (the app that provides this whole interface) is included in every new Django project's INSTALLED_APPS by default, and its URLs are wired up in the project's urls.py automatically by the standard project template — visiting /admin/ and logging in with that superuser account is usually all it takes to see it working.

Customizing what the admin actually shows

# admin.py
from django.contrib import admin
from .models import Article
 
class ArticleAdmin(admin.ModelAdmin):
    list_display = ["title", "published_at"]     # columns shown in the list view
    search_fields = ["title"]                      # adds a search box
    list_filter = ["published_at"]                  # adds a filter sidebar
 
admin.site.register(Article, ArticleAdmin)

The plain admin.site.register(Article) from the first example uses sensible defaults, but real projects almost always customize it via a ModelAdmin subclass — controlling which fields show up in the list view (list_display), which fields are searchable (search_fields), and what filters appear in the sidebar (list_filter). This is configuration, not code that runs per-request — it's read once to determine how the admin interface for that specific model should behave.

What the admin is actually for — and what it isn't

The Django admin is designed for trusted internal users — the people building and running the site, not the general public. It's genuinely well-suited for content management (a blog's editors publishing articles), internal data correction, and quick day-to-day data inspection during development. It is not meant to be the user-facing part of an application — a real e-commerce site's product catalog is managed through the admin by staff, but customers browse the storefront through entirely separate views and templates, never touching /admin/ at all. Confusing "the admin" with "the application" is a common early misunderstanding: the admin is a tool for people who work on the site, not a substitute for building actual user-facing features.

Security: why access to the admin matters

Because the admin gives full read/write access to whatever models are registered with it, restricting who can log into it matters — is_staff (can log into the admin at all) and is_superuser (has every permission, bypassing individual permission checks entirely) are separate flags on Django's built-in User model, and real projects typically grant admin access carefully, scoped with the permission system covered in the authentication and permissions lesson, rather than handing out superuser accounts freely.