Integrations and environments

Taiga reaches outside itself for two things: your source control, where the work lands, and your package registries, where your internal packages come from.

Everything else it knows about your infrastructure, it knows because you described it.

Two levels, and it matters which

The organization holds what is the same for everyone: the source-control provider and your package registries. Connected once, used by every product, managed by administrators.

A product holds what is only true of it: the repository it works on, and the environments its software runs in.

Source control

A linked repository is the prerequisite for most of what Taiga does.

Detailed planning reads your code before it decides on steps, runs execute against a branch of it, maintenance sweeps scan it, and the as-built documents are derived from it. Without one, a product can produce documents and initiatives but not changes.

The provider is connected once for the organization. Linking a particular repository to a product is a separate act, done per product.

Connecting asks you to authorize on GitHub as well as install. Taiga links an installation only when the GitHub account you authorized with can actually reach it, so connect with the account that installed the app. If the connection is refused, that check is usually why.

The branch Taiga works on

Taiga branches from one branch of the linked repository and opens its pull requests against that same branch. By default it is the repository’s default branch.

Teams who run a branch per environment, such as development promoted to staging and then to main, usually want the lowest of them instead. Choose it on the repository card in the product’s settings: pick a branch, or pick Repository default to go back to following the repository. The branch has to exist already, and Taiga will not create it.

One setting covers everything that reads or writes your code: the clone detailed planning reads, the branch a run starts from, the base of the pull request it opens, the branch a maintenance sweep scans, and the push that marks the as-built documents stale.

Picking a protected branch is allowed and Taiga says so when you pick one. The pull request still has to satisfy whatever that protection requires, so if your app is not permitted to merge there, the work waits for someone who is.

Promotion stays yours. Taiga lands work on the branch you chose and never moves it onward, so the path from one environment branch to the next is your team’s process on your team’s schedule.

Package registries

If your repositories install private packages, connect the registry that serves them. Without it, Taiga’s runs cannot install those packages.

That includes internal libraries as well as a linked design system. For a design system there is an extra benefit. When your connected registries between them serve all of its scopes, Taiga installs it like any other dependency, with correct versions and complete type information. When any of its scopes is not served, it falls back to cloning the repository and linking from source, which works and makes every run slower. See design system for what that changes.

Connecting one

Start by choosing the ecosystem the registry serves. It decides which registries you can pick, what the address looks like and what the credential is, and neither it nor the registry type can be changed once the registry is connected.

Ecosystem	Registries	Credential
npm	GitHub Packages, npmjs.com, Google Artifact Registry, any npm registry	Read-only token, or a service-account key for Google
Terraform	HCP Terraform or Terraform Enterprise, Scalr, any module registry	Team or service-account API token
Python	Google Artifact Registry, Azure Artifacts, JFrog Artifactory, any package index	Username and token, or a service-account key for Google
NuGet	Azure Artifacts, GitHub Packages, JFrog Artifactory, any v3 feed	Username and token
Go	A git host (GitHub, GitLab, Bitbucket), Google Artifact Registry, JFrog Artifactory, any module proxy	Username and token, or a service-account key for Google
Cargo	JFrog Artifactory, any sparse registry	Token

Give Taiga the narrowest credential that can read your packages, because installing them is all it does with it. Where a username is asked for, Azure Artifacts and GitHub accept any value, and Taiga fills one in when you leave it blank; Artifactory needs the token’s own user.

While your design system is cloned, its page links to the connection form already filled in with the design system’s scopes that no working registry serves yet, and one of their packages to test. A registry whose last test was refused does not count, because runs do not use it. A link can fill in the registry, its type, the scopes and the package to test, never the credential. When the registry address came from a link, check that it is your organization’s registry before you enter the credential, because the test sends the credential there.

The connection is tested before it is saved, so a credential the registry rejects is refused there and then, not discovered in a failed run. For npm, every scope you list is tested, so a credential the registry refuses for one of them is refused as a whole, and the result names that scope. You can test it again at any time, and your settings show whether the last test succeeded. A registry that does not answer the test is still saved, and shown as unreachable.

The test is stronger when you name a package to test, one the registry serves and your runs install, in the ecosystem’s own form: @your-org/ui for npm, your-org/network/aws for a Terraform module or your-org/internal for a provider, your-org-utils for Python, YourOrg.Common for NuGet, github.com/your-org/platform for Go, your-org-core for Cargo. A Go git host needs one: it answers as if a repository did not exist whenever it will not show it, valid token or not, so only a real repository proves the token works. Taiga then fetches that package with the credential, which proves it can read your packages, not only that the registry accepts the credential. The package is kept with the registry, so every later test fetches it too. When the registry refuses a test, the result says what was refused: the registry did not accept the credential, it accepted the credential but the credential cannot read the package, or the package was not found, which is also what a registry answers when the credential cannot see it. The result names two other causes when they apply: Google refusing a service-account key when Taiga exchanges it for an access token, and a NuGet or Cargo registry tested without a package answering that nothing is at that address. Without a package to test, npmjs.com cannot be tested properly: it answers a package the token cannot read as if it did not exist, so the test cannot tell a working token from one that will fail.

For npm, list the scopes your repositories install from the registry, such as @your-org. You can also enter a package name such as @your-org/ui: it is changed to its scope, @your-org, and becomes the package to test when you have not named one. A name without a scope, such as utils, cannot be routed by scope, so it is refused rather than left out. One registry can serve several scopes, so a Google Artifact Registry repository that holds two of your scopes is one registry with both listed. Taiga routes the scopes you list, and your design system’s scopes as described below. Your repository’s own .npmrc takes precedence: a scope it already routes elsewhere keeps going there. Everything else installs wherever your repository’s own npm configuration sends it, which by default is the public registry.

You can leave the scopes empty in two cases. If the registry only serves your linked design system, its package scopes are routed to it automatically. When several registries leave their scopes empty, only the first one connected gets them, so list the scopes if that is not the one that serves it. If your repository’s own .npmrc already routes the scopes to the registry, Taiga only has to supply the credential.

For Go, list the module path prefixes the registry serves, such as github.com/your-org. They are required: they keep those modules out of the public checksum database, which cannot see private modules, and for a git host they also bound where the credential is sent. A module proxy is placed ahead of the public proxy for every module, and its host gets the credential. For a git host, every prefix must be on that host, and the package you test must sit under one of the prefixes. Terraform, Python, NuGet and Cargo take no scopes. A Terraform registry address is the host alone, such as https://app.terraform.io, because Terraform keys its credential by hostname. Your repository already names the registry, in a module source, an index URL, a nuget.config source or a .cargo/config.toml registry, and Taiga supplies the credential for it.

What happens to the credential

It is stored encrypted and never written into your repository. Agents receive it only while a run needs it, outside the repository they work in, in the form each ecosystem’s own tools read: a user-level npm configuration, Terraform’s per-host token variable, a credentials file for pip, uv and Go module proxies, per-index variables for uv and Poetry when pyproject.toml names the index, NuGet’s per-source credential variable, and Cargo’s per-registry token variable. For a Go git host, git is given a rewrite, through its environment rather than a configuration file, that adds the credential to fetches under the module prefixes you listed and nowhere else. Beyond npm and Go, a registry gets its credential only when your repository names it (a Terraform source, a Python index, a nuget.config source, a Cargo registry), so a run never holds credentials its repository does not use. A Google service-account key never leaves Taiga at all: agents get access tokens made from it, and those expire within an hour.

If you record when a token expires, the registry is flagged in your settings in the two weeks before it lapses, and again once it has.

When a registry is missing

When a run has to install your repository’s dependencies, Taiga first works out which registries they come from. For npm it reads the scopes your npm and Yarn configuration route to a registry, and the registries your lockfile downloads packages from. For the other ecosystems it reads your Terraform module and provider sources, your Python index URLs (requirements files, pip.conf or pip.ini, pyproject.toml, Pipfile, uv.lock, poetry.lock), your nuget.config sources and your Cargo registries. For scoped packages that install from the public npm registry, it also asks that registry, without credentials, about up to three packages in each scope. npmjs.com answers a request for a private package as if the package did not exist, so a scope where none of them exist is treated as private. Yarn 1 downloads a package from the exact address in yarn.lock, whatever registry its scope is routed to, so in a Yarn 1 repository this holds even when a connected registry lists that scope: the task then also says to remove the scope from that registry, because the packages do not come from there. npm and pnpm send a package to the registry its scope is routed to, so for them a scope a connected registry lists is left to that registry. There are two exceptions, both treated like Yarn 1: an npm project whose .npmrc sets replace-registry-host=never, because npm then fetches the address recorded in package-lock.json as it stands, and a pnpm project whose pnpm-lock.yaml records tarball addresses (lockfile-include-tarball-url), because pnpm downloads those as recorded. If the registry does not answer in time, or answers anything else, the result is inconclusive and no task is raised for that scope. Go modules are checked the same way against the public Go module proxy, which cannot serve a private module.

Then the install runs. If it succeeds, nothing is raised for the ecosystems it installed, because whatever was flagged there turned out to be reachable. If it fails, each scope that none of your connected registries serves becomes one action required task, naming the registry to connect and the scope to list. A registry your repository installs unscoped packages from gets one task of its own, and so does each registry of another ecosystem, or each Go module prefix, that nothing connected serves. A success only speaks for what it installed, though. A registry of an ecosystem whose install did not run is raised either way: Terraform, because runs do not initialize Terraform before they start, and, for example, a Python index named in a Pipfile that no install reads. When the repository’s own make install does the installing, Taiga cannot tell which ecosystems it covered, so only npm registries are cleared by its success. A later run for the same product that finds the same scope missing updates its task rather than adding another.

The run keeps going without those packages. A package manager that cannot fetch one package may install nothing at all. The agents are told which packages are unavailable, so they do not rewrite working code to get around errors that only exist because a package is missing. The pull request Taiga opens says the change was not verified locally, and your own CI, which can already reach those registries, is the check for it. Once you connect the registry, the next run installs them.

A registry you did connect is different. When the install shows it rejecting its credential, the run stops with that error, because nothing it serves can install until the credential is fixed.

Your CI needs access too

When Taiga installs your design system from registries, the change it opens records where its packages come from. For each of the design system’s scopes the repository does not route yet, it adds a line to the repository’s .npmrc that routes the scope to the registry serving it, and never a credential.

Your own CI then needs read access to those registries, or its install step fails on Taiga’s first change. Taiga raises that as an action required task, with the steps for your registry, unless the repository already authenticates it.

For a token-based registry, that is a read-only token stored as a CI secret and referenced from the CI’s npm configuration. For Google Artifact Registry, it is an authentication step before the install, such as Workload Identity Federation for your CI provider, rather than a stored token, because the access tokens expire within an hour.

Environments

An environment is a place your software runs: development, staging, production, or whatever ladder you use. Each product defines its own.

They matter more than they first appear, because several surfaces are keyed to them. Deployments are recorded against an environment, monitoring is reported per environment, and a plan made without knowing where the work will run is a plan made against assumptions.

An environment is a description, and it carries what Taiga needs to be concrete: which cloud and region it targets, so plans name real services instead of placeholders, and its public App URL, which is all monitoring needs to start checking.

Describing an environment gives Taiga no access to it. There is no permission to grant and no account to connect. Your pipeline deploys your software, Taiga learns what happened from your source-control provider, and monitoring watches the result from the outside like any other visitor.

Who can do this

The organization-level connections are administrator work. They are shared by every product, so a change to one affects work nobody else asked about. Linking a repository to a product needs someone who can manage source-control access, deliberately narrower than editing a product, because the link reaches a system outside Taiga.

Defining environments is member-level. Anyone doing the work can add the environment they need, which is the right split for something that describes the work rather than governing it.