Django-CRM pins 29 packages and hands its whole interface to Django Admin

The whole interface is Django Admin, pinned to Django 6.0.8

Django-CRM makes its central bet explicit. It runs on Django Admin and ships no user interface layer of its own, which the readme states twice in different registers, first as a selling point and then as a strategy about not reinventing a UI framework. What that buys is a wide surface for free: adaptive admin templates for desktop and mobile, advanced filtering, sorting, search, and object-level permissions down to four verbs. What it costs is that the product's appearance is set by a dependency. requirements.txt pins Django to 6.0.8 with an equality sign, so the admin screens a user works in are the ones that ship with that exact release. Upgrading Django is therefore not background housekeeping here; it moves every screen in the product at once, and it is also the upgrade most likely to break a custom admin class somewhere in an 80-model schema.

Twenty-nine pinned dependencies, each with an equals sign

The dependency file is the most opinionated document in the repository, and every one of its twenty-nine lines is pinned to an exact version, all of them indented by four spaces. The list opens with aiohttp 3.14.3 and asgiref 3.12.1 and closes with XlsxWriter 3.2.9 and yarl 1.25.1. Several entries quietly carry features the readme mentions in passing. geoip2 5.3.0 and maxminddb 3.2.0 are what automatic geolocation runs on. pandas 3.0.6 and numpy 2.5.3 back the analytics app, so a sales funnel report drags a scientific stack into every install, including the evaluation install. openpyxl 3.1.5 and XlsxWriter 3.2.9 sit side by side, one library reading spreadsheets and the other writing them, which is a sensible pairing and also two places to maintain. polib 1.2.0 compiles gettext catalogues, the mechanism behind the locale directory, and tendo 0.3.0 is an SSH library that has no obvious counterpart in the feature list.

The SQLite trial run still installs a MySQL client library

One absence in that list matters more than the additions. The getting-started note says no external database is required and SQLite works out of the box, which is true and also incomplete, because the same requirements file pins mysqlclient 2.3.0. That package is a C extension that has to compile against MySQL client headers before anything runs. So the cheapest possible evaluation, the one where someone clones the repository and starts it on SQLite, still builds a native module for a database it will never touch, and fails outright on a machine without those headers. No pure-Python MySQL driver such as PyMySQL is pinned instead, and no PostgreSQL driver appears anywhere in the list. The supported database set is narrower than the phrase standard Django project implies, and the readme never spells out that narrowing.

Twenty-two interface languages, eleven translated READMEs

Localisation is the one place where two numbers in the same repository disagree. Twenty-two interface languages are available, from ar, cs, de, el, en, es, fr, he, hi, id, it, ja, ko, nl, pl, pt-br, ro, ru, tr, uk, and vi through to zh-hans, with full support claimed for translations, time zones, and locale-specific date and time formats. pytz and tzdata are pinned for the time zone half of that. The README itself exists in eleven languages: English, हिन्दी, Español, 中文, Português, Arabic, Français, Deutsch, Nederlands, Italiano, and Українська. The interface is thus twice as wide as the documentation, and the gap lands hardest on languages a self-hosted adopter tends to run: Polish, Turkish, Czech, Greek, Hebrew, Korean, Indonesian, and Romanian users get a translated screen and an English manual. For a team rolling this out in one of those languages, that asymmetry is a training cost, not a preference.

Mail, chat, and telephony sit inside the CRM, not beside it

The directory listing is a better map of scope than the feature table. There is crm/ for sales data, tasks/ for the task manager, massmail/ for the mailing side, chat/ for internal chat and files, voip/ for callback support, analytics/ for reports, common/ for shared pieces, help/ for context-aware help pages, and webcrm/ for the public-facing form integration. Email here is not a connector but a client: SMTP and IMAP, Gmail and other providers, OAuth 2.0 with two-step authentication, and automatic synchronisation, with every message stored in the CRM database and linked to requests, leads, and deals under a ticket-style mechanism. Contact segmentation, dynamic templates, signatures, campaigns, and newsletters come with it. Messenger integration for WhatsApp and Viber is claimed alongside reCAPTCHA v3 on the public web form, which is a wide surface area for a suite that installs on SQLite.

Eighty-plus models share one four-verb permission model

Over 80 interconnected CRM models is the figure the readme gives, and the permission model is where that count becomes concrete. Every model that reaches the admin is governed by the same four verbs, view, add, change, delete, applied at the object level rather than the page level. That is a real advantage over a flat role list: a user can be allowed to read a deal without being allowed to open its editor. It also means an access review is a walk through models rather than a walk through screens, because each new model arriving in crm/ or tasks/ inherits whatever its admin class declares, and nothing in the readme says where that declaration is audited. Meanwhile the public side, webcrm/, sits outside the admin entirely and needs its own exposure decisions, with reCAPTCHA v3 and geolocation as the only guards named.

AGPL-3.0 under a readme that promises no vendor lock-in

The licence is AGPL-3.0, and it sits underneath a list of reasons that never mentions copyleft: no SaaS fees, no vendor lock-in, fully self-hosted, Python and Django based. Each claim is true, and the sentence closes with a doubled period as if to underline the point. The AGPL is the part that changes what a business can do with the result. Modified source offered to users across a network has to remain available to those users, which is a different conversation from the one about avoiding a proprietary vendor, and for a hosted service built on top of the code the obligations travel with it. Nothing in the readme discusses that. Packaging is also older than the tooling around it: pyproject.toml declares only the setuptools build backend, so the project metadata lives in setup.cfg, with MANIFEST.in and a CHANGELOG.md beside it.

Editorial conclusion

Django-CRM is a credible pick when you want a self-hosted CRM that a Python team can extend, and a poor pick when you need PostgreSQL, a user interface you control, or a licence that lets modified source stay private. Before committing, read LICENSE against your own deployment model, then try the SQLite path on a machine without MySQL client headers: requirements.txt pins mysqlclient 2.3.0, and that is where a short evaluation often stops. If your team does not read English, weigh the gap between twenty-two interface languages and eleven translated READMEs before a rollout.

Frequently asked questions

Official sources

1. DjangoCRM/django-crm on GitHub
2. License: AGPL-3.0
3. Project website
4. README
5. Releases