django-helpdesk: A Django Ticket Tracker You Host Yourself

What django-helpdesk Is For, and Who It Fits

The README describes django-helpdesk as "a Django powered ticket tracker for small businesses", and pyproject.toml labels the intended audience as Customer Service with a Development Status of Production/Stable. The project was formerly known as Jutda Helpdesk, renamed in January 2011 to reflect that it is a Django-powered ticket tracker with contributors beyond the original company.

The practical target is an organisation that already runs Django and wants support tickets stored in the same database as the rest of its application. Tickets, incidents, cases and bugs are listed as keywords in pyproject.toml, which tells you the intended scope: internal or customer-facing request tracking, not a full ITIL service management suite. If you have no Django deployment, the standalone path exists, but you are then maintaining a Django project you did not otherwise need.

How the Application Is Put Together

The repository layout shows a single installable package under src/, with the app itself in src/helpdesk/. A top-level manage.py and a demodesk/ folder hold a demo Django project used for testing and development. The docs/ directory carries the installation, configuration and standalone guides, and the README points to readthedocs for the complete documentation.

Dependencies in pyproject.toml tell you what the app assumes at runtime: django>=5.2, djangorestframework, django-model-utils, markdown, beautifulsoup4 and nh3 for rendering and sanitising content, email-reply-parser for inbound mail, and requests plus oauthlib and requests-oauthlib for outbound integrations. django-cleanup is listed as a hard dependency on purpose; a comment in pyproject.toml explains that it activates automatically when placed in INSTALLED_APPS as docs/install.rst suggests, so a copy that follows the project's own instructions would refuse to start without it.

The front end is vendored rather than pulled from a CDN at runtime. package.json pins bootstrap 5.3.8, jQuery 4.0.0, jQuery UI 1.14.2, DataTables 3.x with its Bootstrap 5 and Buttons packages, metismenu 3.1.0, raphael 2.3.0 and Font Awesome 6.7.2. Those are built into static assets by the yarn and node toolchain rather than fetched per request.

Installing django-helpdesk and Opening the Demo

The README splits installation into two routes: standalone, documented in docs/standalone.rst, and integration with an existing Django application, documented in docs/install.rst and docs/configuration.rst. The demo project lives in demodesk/ and is the fastest way to see the interface before you commit to either route.

The README states you need the uv package manager first, with a link to its installation page. Then create a virtual environment:

uv venv

With the environment in place, the README gives a single make target to bring up the demo server:

make rundemo

There is a Docker alternative in the README. It builds from standalone/Dockerfile and maps port 8080:

docker build --file standalone/Dockerfile -t demodesk ..
docker run --rm -v "$PWD:/app" -p 8080:8080 demodesk

The README says to point a browser at http://localhost:8080 and log in as user admin with password Pa33w0rd, which is defined in the demo.json fixture file. Treat that credential as demo-only; it is written into the repository.

For contributors rather than users, the Makefile exposes make develop, which runs uv venv, uv sync --dev --group test, installs pre-commit through uv tool, and runs pre-commit install. Optional dependency groups are installed with uv sync --all-extras --group teams, and the README notes that make develop installs test dependencies.

The sqlite Search Limitation and Other Sharp Edges

The most clearly documented limitation concerns the demo database. The README states that the demo project uses sqlite, that sqlite does not allow case-insensitive searches, and that the search function may therefore not work as effectively as on PostgreSQL or MySQL. It adds that a message is displayed to alert you when you run a keyword search on sqlite, and closes the point with "There is no way around it, sorry." That is a real constraint if keyword search is central to how your agents triage tickets; the fix is a different database, not a configuration flag.

The upgrade path carries its own risk. The README tells you to migrate with a dry run first, then for real, then restart the web server. It does not document a rollback procedure. If a migration turns out badly on production data, the README offers no reversal steps, so a database backup before the dry run is your own responsibility.

Version floors matter too. pyproject.toml requires Python >=3.10 and django>=5.2, while the classifiers list Django 5.2 and 6.0. If your application is pinned to an older Django, integration is not a drop-in.

The README also does not describe a supported upgrade path between the front-end asset versions or what happens to customised templates when the bundled Bootstrap and jQuery versions move. Anyone who has overridden helpdesk templates should check that before upgrading.

What Changed in the Recent Releases

The release notes give three data points. v2.3.1, pushed on 2026-07-30, is described as "Modernizing UI and misc documentation". v2.3.0, from 2026-06-10, added Kanban board functionality. v2.2.0, from 2026-06-05, is described as multiple enhancements, changes and bugfixes.

The Kanban addition is the most substantive functional change in that window, and it aligns with the UI work in the following release. Note that pyproject.toml carries version 2.5.0 while the most recent tagged release listed is v2.3.1, so the working tree is ahead of the last release tag. If you install from a release rather than from the repository, you are not getting whatever sits between them.

The last push to the repository was on 2026-07-30, the same day as the v2.3.1 release.

Where django-helpdesk Stops and Something Else Starts

The honest comparison is not against another ticket tracker but against the two ways of running a helpdesk at all. A hosted SaaS helpdesk gives you a running system with no Django project, no migrations and no server to patch, at the cost of your ticket data living on someone else's infrastructure and a per-seat bill. django-helpdesk inverts that: the data sits in your database, the licence is BSD-3-Clause, and the operational burden is yours.

The second comparison is against building the ticket model yourself. A Django team that needs request tracking can write a Ticket model, a status field and an admin view in an afternoon. What django-helpdesk adds beyond that is the accumulated surface: inbound email parsing through email-reply-parser, HTML sanitising through nh3 and beautifulsoup4, a REST layer from djangorestframework, OAuth client support, and the vendored DataTables and Bootstrap front end. Whether that surface is worth adopting depends on how much of it you would otherwise write. If you only need a form that writes rows to a table, the app is heavier than the problem.

For teams that want workflow modelling rather than ticket queues, django-viewflow is a different kind of tool: it models explicit process graphs rather than the ticket lifecycle django-helpdesk ships. The two are not interchangeable, and the search data around django-viewflow suggests people conflate them.

Licence, Maintenance and Upgrade Cost

django-helpdesk is licensed under BSD-3-Clause, stated in both the README and pyproject.toml. That is a permissive licence, and it is the reason the project can be embedded in a commercial Django application without the copyleft questions a GPL dependency would raise. The README adds a caveat worth reading in full: the project is distributed with third-party products that carry their own licences, listed in LICENSE.3RDPARTY. The vendored front-end packages in package.json (Bootstrap, jQuery, DataTables, Font Awesome, raphael, metismenu) are the obvious place to look. This is a description of what the files say, not legal advice; if the licence terms affect a commercial deployment, read LICENSE and LICENSE.3RDPARTY yourself.

Upgrade cost has two components. The Python side is a migration run, documented in the README with a dry-run flag first. The front-end side is less visible: the vendored asset versions move between releases, and the v2.3.1 note about modernising the UI suggests template-level changes. The repository has a .pre-commit-config.yaml, a .flake8, an .isort.cfg and a .pylintrc, and the Makefile exposes make checkformat and make format, so contributions are held to a formatting standard. That is a contributor concern rather than an operator one.

The last push was on 2026-07-30, and the repository is not archived.

Editorial conclusion

Adopt django-helpdesk if you already run Django and want ticket data inside your own database rather than a hosted service; the integration path in docs/install.rst is the one to follow, and pyproject.toml pins django>=5.2 and Python >=3.10. Skip it if you need case-insensitive keyword search on sqlite, since the README states there is no way around that limitation, or if you have no Django project to attach it to. Before committing, verify your Django version against the django>=5.2 floor, confirm whether the pinax teams extras matter for your deployment, and read LICENSE.3RDPARTY for the bundled front-end packages.

Frequently asked questions

Official sources

1. Official README
2. Project repository
3. Release notes