django-grappelli: a restyled Django admin with a two-release-line support policy

What the project is and how long it has been around

Grappelli describes itself in one line as a jazzy skin for the Django admin interface, and more precisely as a grid-based alternative or extension to the Django administration interface. That word alternative is doing real work. It is not a fork of the admin, it is a layer that overrides templates and adds its own behaviour on top of the one Django ships.

The longevity is the interesting part of the repository. GitHub reports 3,946 stars and 650 forks, which for a Python distribution whose `setup.py` declares an empty `install_requires` tells you the audience is people who already have a Django project and want to change how it looks rather than people shopping for a stack. Three open issues against that star count is another signal: this is a project with a narrow surface and a settled design.

The last push was 2026-09-17, which is recent enough that describing it as actively maintained is fair. The repository is not archived, the default branch is `master`, and the homepage is grappelliproject.com with documentation at django-grappelli.readthedocs.io.

Two stable branches, one per Django generation

The Releases section of the README is the whole release policy, and it is unusually direct about the constraint. Grappelli is always developed against the latest stable Django release and is not tested with Django's master branch.

Grappelli 5.0.0 (April 29th, 2026): Compatible with Django 6.x
Grappelli 4.0.4 (April 28th, 2026): Compatible with Django 5.x

Two adjacent days, two parallel branches. The development versions are 5.0.1 on branch `Stable/5.0.x` for Django 6.0 and 4.0.5 on branch `Stable/4.0.x` for Django 5.0. Older versions exist on GitHub but are explicitly not supported.

That branch-per-Django-generation scheme is the answer to a question people rarely think about until it bites them. A skin that overrides admin templates is coupled to the exact markup Django emits, so it necessarily cannot support every Django version at once. Grappelli's answer is to support the two most recent and to make the third one your problem. Note that the 4.x and 5.x lines are maintained separately, so security and bug fixes land on whichever branch matches your project rather than forcing a Django upgrade.

Python packaging that declares no dependencies at all

The `setup.py` is short and contains one line worth staring at:

    install_requires=[],

Nothing. Grappelli pulls in no packages at runtime. Django itself is not listed, which means the package will install cleanly into any environment regardless of what else is there, and the compatibility constraint lives in documentation rather than in dependency resolution. For a theme whose whole job is templates and static files, that is the correct shape.

The declared Python support is what you should check against your own project. The classifiers list Python 3.12, 3.13 and 3.14, and the package is marked as a production stable BSD project:

    classifiers=[
        "Development Status :: 5 - Production/Stable",
        "Environment :: Web Environment",
        "Framework :: Django",
        "Intended Audience :: Developers",
        "License :: OSI Approved :: BSD License",

Build configuration is modern enough to be unremarkable: `pyproject.toml` requires setuptools 69.3.0 and wheel with the setuptools build backend, and packaging still goes through `setup.py` with `find_packages` excluding the `test_project` directory.

A JavaScript toolchain layered on a Python package

Grappelli is classed as HTML on GitHub, and the tree explains why. There is a `Gruntfile.js`, a `package.json`, a `package-lock.json` and a `package.json` version of 5.0.0 that matches the Python version exactly, which means the two toolchains are kept in step deliberately rather than by accident.

The build is Sass compiled to compressed CSS with source maps off:

"sass": "sass --watch ./grappelli/sass/screen.scss:./grappelli/static/grappelli/stylesheets/screen.css ./grappelli/sass/rtl.scss:./grappelli/static/grappelli/stylesheets/rtl.css --style=compressed --no-source-map"

Note that `rtl.scss` sits next to `screen.scss`, so right to left support is built in rather than bolted on. The devDependencies are a Grunt stack: clean, compass, concat, copy, jshint, uglify-es, watch, exec, flake8 and spritesmith, alongside sass. Spritesmith matters for an admin skin because icon sets are how you make dense tables scannable, and a sprite pipeline is how you ship many small icons in one request.

The `runtests.py` and `tox.ini` files at the root, plus a `test_project/` directory that is excluded from the package, show the project tests against a real Django project rather than mocks. The continuous integration badge in the README points at a GitHub Actions workflow named tests.

Where the repository metadata and the package disagree

Two small disagreements are worth putting side by side, because both are the kind of thing that shows up in an automated check and gets misread.

The first is licensing. GitHub reports the repository license field as `NOASSERTION`, which is what gets reported when a license cannot be classified automatically, not when one is absent. Against that, `package.json` says `"license": "New BSD"`, `setup.py` says `license="BSD"` and declares the OSI approved BSD classifier, and there is a `LICENSE` file at the top of the tree. The repository's own metadata is simply failing to read a license it clearly ships, so treat the LICENSE file as the authority.

The second is language composition. GitHub reports the primary language as HTML, and given that the package ships templates, stylesheets and sprite assets that is defensible. It is still worth knowing that the `grappelli/` directory is a Python package with templates inside it, because a language badge of HTML makes a Python distribution look like a static asset bundle.

Neither of these is a red flag. Both are reasons to look at the files rather than the summary when you are evaluating something with a long history.

Grappelli against the newer admin skins

The related searches around this project are the most useful competitive signal available: Django Jazzmin, Django Unfold, SimpleUI, django-baton and django-filebrowser all appear next to Grappelli, which tells you the category is crowded and each entry has picked a different angle.

SimpleUI and Jazzmin are closest in spirit, being drop-in restyles in the same tradition. Unfold and baton lean newer, often built on modern front end tooling and presented as a replacement for the admin rather than a skin on it. django-filebrowser is not a competitor at all; it is the other half of a common pairing, a media browser that Grappelli themes.

Where Grappelli sits is mostly about age and support discipline. It predates most of that list, it has no Python dependencies, and it maintains a branch per Django generation. What it will not give you is the newer admin work Django has shipped: a skin can restyle markup, but it cannot add a feature Django does not have. If you are picking today, the deciding question is whether you want the pre-recent look and the older navigation model back, in which case Grappelli has had a very long time to get that right, or whether you want something closer to a modern admin framework, in which case you are looking at one of the newer projects instead.

Editorial conclusion

Grappelli's real product is a support promise rather than a feature: two branches, one per supported Django generation, released within a day of each other, with a stated refusal to test against Django's master. That is rarer than it should be in the admin skin ecosystem, and it is why a project with no Python dependencies still gets the version bumps that matter. What you are giving up for it is everything the default admin added in the last few years, since a skin can only restyle markup that exists. For a team that wants the older look back, `pip install django-grappelli`, add it to INSTALLED_APPS before django.contrib.admin, and set GRAPPELLI_ADMIN_URL if you care about the URL. Read the changelog on the readthedocs site before you start, because the release notes, not this README, are where behaviour changes live.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. sehmaschine/django-grappelli on GitHub