Django-CRM: A Self-Hosted CRM Built Entirely on Django Admin

The Gap Django-CRM Fills: CRM Data Without a SaaS Contract

Most small sales teams end up with three disconnected tools: a spreadsheet or lightweight CRM for deals, a task app for follow-ups, and a mailing service for outreach. Each one holds a partial picture of the same customer, and none of them can be extended without paying for an API tier. Django-CRM targets exactly that situation. The README describes it as a free customer relationship management system built with Python and Django, intended for teams that want a self-hosted CRM, task manager, mailing tool and analytics package in one extensible platform. The stated audience is twofold. On the business side: leads, deals, contacts, tasks, projects and email campaigns in one system, replacing several tools with a single collaborative CRM. On the developer side: a CRM written entirely in Python, with no proprietary UI layer, so customization follows normal Django patterns. The repository topics confirm the same scope: crm, task-management, email-automation, reports, self-hosted. If your team is already comfortable with Django, the pitch is that you are extending a framework you know rather than learning a vendor's plugin language.

Django Admin Is the Product, Not a Stopgap

The most consequential design decision in Django-CRM is that it does not ship a bespoke front end. The README states that everything runs on Django Admin, with adaptive admin templates for desktop and mobile, advanced filtering, sorting and search, and object-level permissions covering view, add, change and delete. The project's own framing is that instead of reinventing a UI framework, it concentrates on business logic, data integrity and extensibility. This is a real architectural commitment, and it cuts both ways. For a Django developer, it means model changes surface in the interface immediately, permissions reuse Django's built-in system, and there is no separate JavaScript build to maintain. For a salesperson who has used Salesforce or HubSpot, the interface will look like a database administration tool, because that is what it is. The README lists over 20 interconnected CRM models for sales workflows, which suggests the data model is the substance here, not the presentation layer. Whether that is acceptable depends entirely on who will be clicking through records every day.

Applications and Data Flow Across the CRM

Django-CRM is organized into applications that share one database. The CRM application covers requests (described as inquiries and incidents), leads and opportunities, companies and contact persons, deals as a sales pipeline, products and payments, and email messages linked to CRM objects. The tasks module handles tasks and subtasks, projects as collections of tasks, office memos that can be converted into tasks or projects, plus chat, files, reminders and tags. The analytics application provides sales funnel analysis, income summary reports, lead source analytics and a Requests Summary. Mailing handles email accounts over SMTP and IMAP, campaigns and newsletters, dynamic templates, signatures and contact segmentation. The integration point is the email client. According to the README, all correspondence is stored in the CRM database, linked to requests, leads and deals, and organized using a ticket-style mechanism. That linkage is what separates this from running a generic Django app alongside a mail client: an inbound reply becomes a record attached to the deal or request it belongs to, rather than a message in a separate inbox. The analytics app then reads from those same linked records, which is why funnel and lead-source reports can exist without a separate ETL step.

Getting It Running: Standard Django Deployment

The README does not print an install command sequence, so treat the repository itself as the source of truth for exact steps. What can be stated from the material is the shape of the deployment. This is a Django project, so the expected path is a Python environment, the project's dependency file, database migrations, a static files collection step, and a WSGI or ASGI server behind a reverse proxy. Configuration lives in Django settings, and the README names the specific integration points you will need to configure: SMTP and IMAP accounts for the email client, OAuth 2.0 for providers such as Gmail that require two-step authentication, and reCAPTCHA v3 for web form integration. The mailing module needs its own email accounts configured before campaigns can send. Because the interface is Django Admin, the first account you create is a superuser, and from there the object-level permissions described in the README determine what each team member sees. The README links to a homepage at DjangoCRM.github.io/info/ and to in-repository documents including docs/crm_system_overview.md and docs/django-crm_task_features.md. Those pages, not this article, are where the concrete commands and settings keys belong. Verify the pinned Django and Python versions in the repository before you plan an upgrade path, since the project's own release cadence is separate from Django's.

Where Django-CRM Is the Wrong Tool

The README describes the project status as production and stable, used in real business environments for many years. That is a claim about the software's maturity, and it does not address fit. The clearest limitation is the interface. A sales team that expects pipeline drag-and-drop, mobile apps, or a marketing-friendly campaign builder will find Django Admin unfamiliar, and the project does not appear to offer an alternative front end. The second limitation is operational. Self-hosting means you own the database, the backups, the mail server credentials and the upgrade cycle. The README lists SMTP, IMAP and OAuth 2.0 as supported, which means you are also the person debugging an expired OAuth token when campaign sending stops. Third, the feature list is broad but shallow by design: the README describes leads, deals, tasks, chat, memos, mailing, analytics, VoIP callback and messenger integration in a single sentence each. Teams with deep requirements in any one area, such as multi-touch attribution or complex quote configuration, should assume they will be writing that logic themselves as Django code. Finally, the README notes the project is designed for easy customization and quick development, which is a statement about extensibility rather than about out-of-the-box completeness.

How It Compares to SuiteCRM and EspoCRM

The natural alternatives for a self-hosted CRM are PHP applications such as SuiteCRM and EspoCRM. The difference is not the feature checklist, which overlaps considerably, but the extension model. SuiteCRM and EspoCRM ship their own user interfaces and their own module or extension systems, typically configured through a web-based Studio rather than through application code. Customizing them means learning their conventions, and upgrading means checking whether your customizations survive. Django-CRM inverts this. There is no separate UI framework to learn because the UI is Django Admin, and there is no plugin format because extensions are Django apps and models. The README's phrasing is that the project avoids proprietary frameworks and vendor lock-in. The practical consequence is that a Django developer can read the whole codebase, while a non-developer administrator will find SuiteCRM or EspoCRM friendlier to configure without touching code. If your organization has no Python capacity, the PHP options are the more honest comparison, not because they are better but because their customization path does not require a developer.

Licence and the Cost of Staying Current

Django-CRM is licensed under AGPL-3.0. That is a copyleft licence with a network clause: if you modify the software and let users interact with it over a network, the AGPL's source-disclosure obligations can apply to your modified version. This is not legal advice, and the details matter for how you deploy. An internal, unmodified installation is a different situation from a modified installation offered to external users as a service. If your business model involves hosting a customized CRM for customers, have counsel review the AGPL before you build on it. On maintenance: the release history shows v2.3.0 in April 2026, v2.3.1 later that month, and v2.4.0 in May 2026, with repository activity continuing into September 2026. That is a steady cadence, but because this is a Django application, your real upgrade cost is the intersection of Django's release cycle and the project's. A Django version bump can require changes across the project's own apps, and any local modifications you have made are yours to port. Budget for reading release notes rather than assuming a drop-in upgrade, and pin your dependency versions so a routine pip install does not move Django underneath you.

Editorial conclusion

Adopt Django-CRM if your team already runs Django and Python, you want leads, deals, tasks and mailing data in one self-hosted database, and you are willing to accept the Django Admin as the user interface. Do not adopt it if you need a polished out-of-the-box sales UI, native mobile apps, or a vendor who will manage hosting and upgrades for you, because none of those are part of this project. Before committing, check the repository's requirements file for the Django and Python versions it pins, read docs/crm_system_overview.md to understand how the email client and mailing modules are wired together, and confirm that AGPL-3.0 fits how you intend to distribute or expose the software.

Official sources

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