django-helpdesk: A Django Ticket Tracker With a Kanban Board and a SQLite Search Caveat

What django-helpdesk Solves and Who It Is For

django-helpdesk is a Django application that manages support tickets for an internal helpdesk. It is aimed at small businesses, as the README states directly. The project has been around since 2009, originally as Jutda Helpdesk, and was renamed in 2011 to reflect its broader contributor base. If you already run a Django site and need a ticket system without moving to a separate SaaS platform, this app plugs into your existing stack. It is not a standalone product by default, though a standalone deployment path exists. The target user is a Django developer or a small IT team that wants to keep support requests inside their own infrastructure.

The Core Mechanism: Tickets, Queues, and the New Kanban Board

The repository does not include a detailed architecture document in the README, but the visible structure reveals the core mechanism. The app is a standard Django application with models, views, and templates under src/helpdesk/. Tickets are the central entity, managed through queues and statuses. The v2.3.0 release notes mention 'Kanban board functionality added', which suggests a visual board view for moving tickets through stages. The v2.3.1 release focuses on 'Modernizing UI and misc documentation', so the interface is being updated. The exact data flow is not described in the README, but the presence of migrations and a demo project indicates a typical Django request-response cycle: a user submits a ticket, the app stores it in the database, and staff can view and update it through the admin-like interface.

Getting It Running: The Demo Project and Docker Path

The README gives two concrete ways to start. The quickest is the demo project in the demodesk/ folder. You need the uv package manager. Run 'uv venv' to create a virtual environment, then 'make rundemo' to start the server. Alternatively, use Docker: 'docker build --file standalone/Dockerfile -t demodesk ..' and then 'docker run --rm -v "$PWD:/app" -p 8080:8080 demodesk'. You can then open http://localhost:8080 and log in as user 'admin' with password 'Pa33w0rd', defined in the demo.json fixture. For integration into an existing Django project, the README points to docs/install.rst and docs/configuration.rst, which are not reproduced here. The standalone installation also has its own documentation file. The upgrade path is clear: run 'python manage.py migrate helpdesk --db-dry-run' to check, then 'python manage.py migrate helpdesk'.

A Genuine Limitation: SQLite and Case-Insensitive Search

The README is explicit about a failure mode. The demo project uses SQLite, and SQLite does not allow case-insensitive searches. This means the search function may not work as effectively as on PostgreSQL or MySQL. When you try a keyword search on SQLite, a message is displayed to alert you to the shortcoming. The README says 'There is no way around it, sorry.' This is a real constraint for any deployment that sticks with SQLite. If your helpdesk relies on searching ticket content, you must use PostgreSQL or MySQL from the start. This is a concrete example of a database-specific behavior that can surprise developers who use SQLite for prototyping and then forget to switch.

The Alternative: Jutda Helpdesk or a Custom Django App

The main alternative is the predecessor, Jutda Helpdesk, which is the same project under a different name. Since django-helpdesk is the renamed continuation, the alternative is not a competitor but a historical version. For a real alternative, consider building a simple ticket model inside your existing Django app. That approach gives you full control over fields and workflows, but you lose the ready-made UI, the demo project, and the migration history. Another alternative is to use a full ITSM tool like Jira Service Management, but that is a separate product with its own hosting and licensing. The difference in approach is that django-helpdesk gives you a packaged, tested Django app with migrations and a UI, while a custom app requires you to write and maintain every feature yourself.

Maintenance and Upgrade Cost

The project has an active release cycle, with v2.2.0, v2.3.0, and v2.3.1 all released within a few months in 2026. Each release brings enhancements, bugfixes, and UI changes. This means you need to keep up with migrations. The README provides a migration command, but it also warns to restart your web server after migrating. The dependency on uv for development and the Makefile targets (make test, make checkformat, make format) show a modern Python toolchain. The license is BSD-3-Clause, which is permissive, but note that the project is distributed with third-party products that have their own licenses, as stated in LICENSE.3RDPARTY. You should review that file before deploying, especially if you redistribute the app.

Who Should Adopt It and What to Verify First

Adopt django-helpdesk if you are a small business with a Django site and you want a self-hosted ticket tracker without building one from scratch. The demo project and Docker path lower the barrier to trying it. Do not adopt it if you need case-insensitive search on SQLite, because the README says there is no workaround. Also, if you need advanced features like SLAs, asset management, or multi-tenant support, this app may not cover them. Before committing, verify your Django version against the project's requirements, which are not listed in the README but can be found in the package metadata. Test the Kanban board in v2.3.0 to see if it fits your workflow. Finally, run the migration dry-run command on a copy of your data to catch any issues.

Editorial conclusion

Adopt django-helpdesk if you run a small internal helpdesk on Django and want a self-hosted ticket tracker with a built-in demo and Docker option. Do not adopt it if you need case-insensitive search on SQLite, or if you require a full-featured enterprise ITSM tool. Before adopting, verify your Django version compatibility, check the latest migration path from your current version, and test the search on your target database (PostgreSQL or MySQL) to avoid the SQLite limitation.

Official sources

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