Skip to content

Organizations, teams and projects

Taiga has three levels, and most things you configure live at one of them:

Organization
└── Team
└── Project

An organization contains teams. A team contains projects. A project has one repository. The work happens in projects; the levels above exist so that decisions made once do not have to be repeated.

That one-to-one rule is what decides how to model a larger system. A product built from several services, each in its own repository, is not one project. It is a team, with a project per service.

The useful question is not “where does this setting live” but “how widely should this apply”.

Level What lives there
Organization Policies, the approved tech stack, the design system, organization-wide instructions and knowledge, members.
Team A knowledge base, one instructions document, and members.
Project Everything specific to its codebase: the specification, documents, initiatives, instructions and knowledge.

The organization is where the weight sits. It carries the house style every team inherits, which is why setting it up matters more than its brevity suggests. A team is deliberately light: enough to give its projects shared context and to control who can reach them. That is what makes it the right home for a multi-service product. The services share a domain, a stack and a definition of done, and the team is where you write those down once instead of per repository.

A project sees its own settings, its team’s, and the organization’s. A team sees its own and the organization’s. Nothing flows upward or sideways: one team’s instructions never reach another team’s projects.

This is why the same idea can exist at more than one level. Instructions and knowledge are not duplicated between them, they accumulate. Each level adds guidance for a narrower audience, and a project ends up reading all three.