Where Taiga fits
Taiga is a self-hosted work-management application built around agile projects. A Kanban project follows work as it moves through a board. A Scrum project adds a product backlog, sprint planning and sprint progress. Both can hold user stories, tasks, issues and attachments, so a team does not need a separate tracker merely to record the work around a feature.
It suits a team that wants control of its project data and is willing to own the application. It is less suitable when the main requirement is a large portfolio-management system, a heavily regulated record repository, or a universal replacement for source control, customer support and documentation. Keep those boundaries clear before people create projects.
Choose the working model before configuring screens
Use a Kanban project when flow matters more than a time-boxed commitment. Agree what each column means, what can enter it, and who can move an item. A column called Review should mean a real review state, not a parking place for unfinished work.
Use a Scrum project when a team maintains a backlog and plans bounded sprints. Decide whether user stories, tasks and bugs have distinct rules. Record who can start a sprint, close it and change its scope once work has begun.
One organisation can run both project types, but shared labels and conventions still matter. A support team may run Kanban while a product squad runs Scrum. Give each project a named owner instead of forcing one workflow on both.
The application pieces to plan
A production Taiga installation includes the web interface, application services, a database and persistent media storage for uploads. It also depends on an external URL, TLS termination, outbound email and a background-job path where the selected deployment method uses one. The exact container layout differs from a source installation, so treat upstream deployment documentation for the chosen version as the operating reference.
The useful data path is simple: a browser or API client reaches Taiga through HTTPS; Taiga reads and writes project records in its database; uploaded files land in configured media storage; email delivers invitations and notifications. A failed mail relay should not silently become a failed account-recovery process. Test it with a non-administrator account.
Set up a workspace that people can read
Start with a pilot project and remove assumptions before importing the team’s active backlog.
Project templates
Create a small number of templates for recurring project shapes. Include statuses, issue types, roles and wiki defaults. Avoid a template for every department; a short catalogue is easier to maintain.
Backlog rules
Define the minimum fields for an item to enter a backlog: a clear outcome, an owner or triage group, and an agreed workflow type. A title alone is rarely enough for planning.
Permissions
Map Taiga roles to actual responsibilities. Test what a member, stakeholder and project administrator can see and change, including attachments and private project settings.
Notifications
Pilot mentions, assignments, watcher behaviour and email delivery. Notification noise pushes work back into private chat; missing notifications leave work unattended.
Bring work in deliberately
An import is a data migration. Treat it as one, even when the source is a spreadsheet.
| Boundary | Questions to answer | Acceptance check |
|---|---|---|
| Repository links | Which events should appear in Taiga, and which stay in the code host? | A test repository links an item without exposing a token or creating duplicate updates. |
| Imports | How do source identifiers, statuses, users, comments and attachments map to Taiga records? | A pilot import is compared with the source by its project owner before the full run. |
| Chat and webhooks | Who owns each webhook and where do failures appear? | A failed delivery is visible to an administrator and can be replayed or corrected from a documented runbook. |
| API clients | Which personal or service credentials are permitted? | Tokens have named owners, limited scope where available, and a review date. |
Identity, access and exposed surfaces
Decide whether Taiga will use its own accounts or a supported identity arrangement for your release. Whichever route you choose, confirm the user lifecycle: invitations, disabled accounts, administrator access, password reset and the handling of people who change teams. Do not assume an inactive account disappears from project history; test the desired behaviour in a non-production workspace.
Publish only the HTTPS endpoint users need. Protect administrative infrastructure separately, store secrets outside the repository, and review reverse-proxy headers so that the app sees the correct scheme and host. Uploaded files deserve the same attention as database records. Check access control, malware-handling policy and restore behaviour before inviting a broad group.
Migrate in a sequence people can verify
Inventory active projects first. For each one, name the source owner, destination owner, date range, attachments policy, open versus closed work, and any identifier that must stay visible. Import one representative project, then ask people who actually use it to check board positions, sprint dates, comments, files and notifications. This is where awkward field mapping surfaces.
Keep the old tracker readable until the pilot meets its written acceptance checks. Cut over a project at a defined time, route new work to Taiga, and publish the new project URL. Do not move every historical project merely because an importer exists. Old, closed work can often remain read-only in its original system if retention policy allows it.
Operating ownership
Taiga needs an application owner and an infrastructure owner. Those may be the same person in a small team, but the duties should still be written down.
Service health
- Monitor the public endpoint, application errors and database connectivity.
- Check background work and outbound email after each release.
- Keep a current contact for the reverse proxy and DNS path.
Backups
- Back up the database and uploaded media as a recoverable pair.
- Set a retention policy for backup copies and restrict access to them.
- Perform a restore test into an isolated environment and record the result.
Change control
- Read the release notes for the selected deployment and plugin set.
- Test the upgrade against a copy of representative data.
- Plan a rollback decision before changing production.
Documentation
- Keep the deployment method, environment variables and owners in one runbook.
- Record open upgrade, mail and integration decisions.
- Give project administrators a route for support and escalation.
Questions worth answering before launch
Can every team use the same workflow?
Usually no. Keep the shared vocabulary small, then let a Kanban service team and a Scrum product team use the project type that matches their work. The test is whether a new member can tell what to do from the board without a separate translation guide.
What should we back up?
Back up the database and the media or attachment storage together. A database-only restore can leave project records pointing to missing files; file-only recovery loses context, permissions and item history.
How do we know an import worked?
Compare a pilot with its source using agreed samples: active items, closed items, comments, attachments, owners and dates. Have the project owner sign off before the full migration.
Who supports a broken login or missed notification?
Name a first-line contact, the application administrator and the mail or identity-system owner. Put the hand-off path in the project’s launch note, where users can find it.
What changes the deployment effort
The number of named users is not the whole sizing question. Attachment volume, notification traffic, active integrations, project count, desired availability and whether teams require a separate test environment all change the operating work. A single internal project with a small database is a different service from an organisation-wide tracker with public integrations.
Ask early who owns project configuration after launch. A central team can run the infrastructure while project owners maintain boards, backlogs and permissions. That split prevents routine workflow changes from becoming infrastructure tickets and prevents infrastructure administrators from silently becoming process owners.
