Taiga Back

Taiga is a fully open-source project management platform built for agile development teams. The backend (taiga-back) is the Django-powered engine behind Taiga’s Scrum boards, Kanban views, issue tracker, epics, and milestones — exposing every feature through a comprehensive REST API. Teams that need complete control over their data, no per-seat pricing, and full auditability choose Taiga over hosted alternatives.

The platform is architected as a Django application backed by PostgreSQL for persistence and Redis for real-time event propagation and caching. Celery handles asynchronous tasks such as notification emails and export generation. The backend ships as a standalone Docker image and pairs with the Taiga frontend (a separate React application) via the REST API, making the system genuinely decoupled and API-first.

Taiga supports both Scrum and Kanban workflows with customizable statuses, priorities, severities, and story points. Teams can define custom attributes on epics, user stories, tasks, and issues — allowing data models to match existing processes rather than forcing teams to adapt. Built-in importers from Jira, Asana, Trello, Pivotal Tracker, and GitHub give teams a migration path from commercial tools without losing historical data.

With over 84 contributors and more than 4,400 commits, taiga-back is an actively maintained project. It integrates with GitHub, GitLab, and Bitbucket webhooks to link commits and pull requests to issues automatically, and exposes OAuth2 endpoints for SSO integration.

What You Get

• Scrum Sprint Engine - Complete sprint lifecycle management including backlog grooming, sprint planning with story points, velocity tracking, and burn-down chart data exposed via API.
• Kanban Board Backend - Configurable workflow stages with customizable WIP limits, swimlanes, and column ordering — all managed through the REST API so the frontend and any custom clients stay in sync.
• Issue Tracker with Custom Attributes - Per-project custom fields on epics, user stories, tasks, and issues stored as JSON metadata, allowing teams to model domain-specific data without schema migrations.
• Full REST API - Every feature — creating issues, updating sprint assignments, fetching history, posting attachments — is exposed through versioned REST endpoints with OAuth2 authentication and granular permission checks.
• Multi-source Importers - Built-in import pipelines for Jira, Asana, Trello, Pivotal Tracker, and GitHub that migrate projects, issues, comments, and attachments into Taiga’s data model.
• Git Webhook Integration - Automatic issue linking via commit message references (e.g., TG-#123) with receivers for GitHub, GitLab, and Bitbucket webhooks that update issue statuses and attach commit references.
• Real-time Event System - Django signal-based event bus that publishes model changes to connected WebSocket clients via Redis, enabling live board updates without polling.
• Role-Based Access Control - Per-project role definitions with fine-grained permission sets, anonymous access controls, and project-level visibility settings (public/private).

Common Use Cases

• Running a software sprint - A development team uses Taiga’s Scrum board to plan a two-week sprint, assigns user stories with story point estimates, links commits to issues via GitHub webhooks, and monitors burn-down progress through the API.
• Migrating from Jira - An engineering organization uses Taiga’s built-in Jira importer to move projects, issues, sprints, and comments into a self-hosted Taiga instance, eliminating per-seat Atlassian licensing costs.
• Building a custom project dashboard - A platform team calls the Taiga REST API from an internal tool to aggregate open issues, sprint velocity, and team workload across multiple projects into a unified ops dashboard.
• Running non-software Kanban workflows - A marketing team creates a Taiga project with Kanban columns matching their content pipeline stages (Draft → Review → Scheduled → Published), using custom attributes to track publication dates and channels.
• Self-hosted CI/CD integration - A DevOps team configures GitLab webhooks to automatically close Taiga issues when merge requests are merged to main, keeping project boards in sync with the code repository without manual updates.

Under The Hood

Architecture Taiga Back is organized as a Django monolith partitioned into feature modules — projects, epics, user stories, tasks, issues, milestones, webhooks, importers, events — each containing its own models, API viewsets, serializers, services, signals, and permissions files. This consistent per-module structure enforces clear boundaries without requiring a microservices deployment. The event subsystem is decoupled from HTTP via Django’s signal framework: any model save or delete emits a signal that the events app fans out to connected WebSocket clients through Redis, enabling real-time collaboration independent of the request/response cycle. Bulk ordering operations use PostgreSQL’s execute_values for O(n) batch updates rather than N individual queries, and database-level advisory locks via django-pglocks prevent concurrent reordering conflicts.

Tech Stack The server runs Python 3.11 on Django 3.2 LTS backed by PostgreSQL accessed through Django’s ORM and raw psycopg2 for bulk operations. Celery with Kombu handles asynchronous work — email notifications, export generation, and telemetry — using an AMQP or Redis broker. Redis serves double duty as Celery’s broker and as the event relay for WebSocket-connected frontend clients. The Docker image is built on Python 3.11-slim with Gunicorn as the WSGI server. Authentication is handled through a custom JWT implementation with OAuth2 support and a token denylist for logout. Jinja2 templates handle transactional email rendering via django-jinja, and image processing uses Pillow, CairoSVG, and easy-thumbnails for attachment thumbnails.

Code Quality The codebase ships with an extensive test suite spread across integration and unit test directories, with coverage reported through Coveralls and CI enforced via GitHub Actions. Integration tests use pytest with Django-aware fixtures and factory_boy-style data factories, covering API endpoints, permission boundaries, webhook delivery, and importer correctness against realistic datasets. Code style is enforced through flake8 with a maximum line length of 120 and complexity limit of 10, excluding migration and test files. The project follows conventional commits and maintains a CONTRIBUTING guide and DCO policy. Some deprecation warnings from the Django 3.x-to-4.x transition are suppressed in pytest configuration, indicating the stack is approaching an upgrade boundary.

What Makes It Unique Taiga’s most distinctive engineering choice is the combination of a consistent per-module API pattern (each domain module exposes the same viewset, serializer, service, signal, and permission layers) with a project-level custom attribute system that stores typed metadata in JSON columns — avoiding schema migrations while allowing deep per-project customization of epics, stories, tasks, and issues. The bulk-order update service uses an explicit algorithm that computes cascading reorder shifts for all affected elements in a single pass, then persists them via PostgreSQL execute_values in one round-trip, maintaining consistent ordering across nested entity hierarchies (epics → stories → tasks) transactionally. The event architecture publishes every model mutation through a Django signal bus to Redis, so the frontend receives live diffs rather than polling — an approach that scales within a single-server deployment without requiring a dedicated event streaming service.

Self-Hosting

Taiga Back is released under the Mozilla Public License 2.0 (MPL-2.0), a weak copyleft license. MPL-2.0 is file-scoped: if you modify MPL-2.0 licensed source files you must release those specific files under MPL-2.0, but you can combine them with proprietary or differently-licensed code in the same project without triggering copyleft on your additions. Commercial use, modification, and distribution are all permitted. For most self-hosting teams this means you can deploy Taiga internally, customize it, and integrate it with proprietary systems without any licensing obligation to release your own code — only modifications to Taiga’s own files would need to be shared.

Operationally, self-hosting taiga-back requires running and maintaining several moving parts: a Django application server (Gunicorn behind a reverse proxy), a PostgreSQL database, a Redis instance, and a Celery worker for async tasks. The official Docker Compose setup bundles all of these, lowering the barrier to initial deployment, but ongoing operations — database backups, schema migrations across version upgrades, Redis persistence, SSL certificate management, and log aggregation — are entirely the operator’s responsibility. The application has no built-in backup scheduler, health-check dashboard, or auto-upgrade mechanism, so teams need standard infrastructure practices around these concerns.

Taiga.io operates a hosted cloud version (Taiga Cloud) that removes all of this operational burden and adds SLA-backed uptime, managed database backups, automatic upgrades, and priority support. The self-hosted backend is functionally equivalent to the cloud version — there is no gated enterprise tier or feature wall — but the cloud offering provides the administrative infrastructure that production deployments require. Teams evaluating self-hosting should weigh the full infrastructure cost (hardware, ops time, on-call coverage) against Taiga Cloud’s subscription pricing, especially for smaller teams where operational overhead per seat can exceed the cost of a managed plan.