Installation

Purpose and Scope

This page explains the practical ways to make the turbo CLI available to a team: start a new repository with create-turbo, install turbo globally for convenient local commands, and install turbo in the repository so every contributor and CI job uses a pinned version. Turborepo’s installation docs frame these options as complementary rather than mutually exclusive: a global CLI is fast for day-to-day terminal use, while a repository dependency is the stable contract for collaboration. The same installation choices also shape CI, remote caching, upgrades, and Vercel deployments.

Sources: apps/docs/content/docs/getting-started/installation.mdx

Turborepo’s first-run path is intentionally short. The installation guide tells new users to get started with create-turbo@latest, which scaffolds a starter repository containing two deployable applications and three shared libraries. That starter gives readers a working monorepo before they have to design package boundaries, task graphs, or cache outputs from scratch. If the starter is not a match, the docs point readers toward examples that better fit their toolchain interests, keeping installation connected to hands-on learning rather than only package installation.

Sources: apps/docs/content/docs/getting-started/installation.mdx

Quick Start with create-turbo

Use create-turbo when you want a new monorepo with Turborepo already configured. The command is executed through the package-manager runner rather than installed permanently first. This keeps the bootstrap flow simple: choose the command that matches the package manager you use, let the generator create the repository, then inspect the generated apps, shared packages, and root configuration before adding your own tasks.

pnpm dlx create-turbo@latest
yarn dlx create-turbo@latest
npx create-turbo@latest
bunx create-turbo@latest

The release notes continue to reinforce this path for new projects, listing npx create-turbo@latest alongside the automated migration command for existing projects. That pairing is useful when choosing between starting fresh and upgrading an existing workspace: use create-turbo to learn the current project shape from a generated starter, and use the codemod migration flow when you already have a repository that should be updated in place.

Sources: apps/docs/content/blog/2-10.mdx, apps/docs/content/docs/getting-started/installation.mdx

Installing the turbo CLI

Install turbo globally when you want a fast terminal command that can be used from any repository checkout. The official installation guide describes the global install as a way to bring flexibility and speed to local workflows. After the global CLI is available, commands such as turbo build, turbo build --filter=docs --dry, turbo generate, and cd apps/docs && turbo build can be run directly. The docs also clarify an important naming detail: turbo is an alias for turbo run, so turbo build and turbo run build both execute the build task.

pnpm add turbo --global
yarn global add turbo
npm install turbo --global
bun install turbo --global

The global install has one operational caveat: avoid multiple global installations from different package managers. The installation guide warns that mixing global installs can create unexpected behavior and points readers to turbo bin as the way to check which package manager was previously used. In practice, teams should document their preferred package manager and use it consistently for the global install. That decision is separate from the repository-pinned dependency, but it prevents confusing local PATH behavior when developers switch between pnpm, Yarn, npm, and Bun.

Sources: apps/docs/content/docs/getting-started/installation.mdx

Repository installation is the collaborative baseline. Add turbo as a root devDependency so the workspace records a specific CLI version in package.json and the lockfile. The docs recommend this because teams should pin dependency versions when collaborating. CI examples follow the same model: the sample root package.json defines scripts such as build and test that call turbo run build and turbo run test, and lists turbo in devDependencies. That gives local developers and CI jobs the same task runner version.

pnpm add turbo --save-dev --ignore-workspace-root-check
yarn add turbo --dev --ignore-workspace-root-check
npm install turbo --save-dev
bun add turbo --dev

Sources: apps/docs/content/docs/getting-started/installation.mdx, apps/docs/content/docs/guides/ci-vendors/github-actions.mdx

CI and Remote Cache Considerations

Installation does not stop at a developer laptop. In CI, the package-manager install step restores project dependencies, then package scripts invoke the repository-pinned turbo. The GitHub Actions guide shows a workflow that checks out code, sets up the package manager and Node.js, installs dependencies, then runs build and test scripts. The same guide includes optional remote-cache environment variables, TURBO_TOKEN and TURBO_TEAM, showing that CI installation and cache authentication are adjacent setup steps.

Sources: apps/docs/content/docs/guides/ci-vendors/github-actions.mdx

Remote caching changes the payoff of a correct installation. The Vercel Remote Cache announcement describes remote caching as a distributed caching layer that helps developers and CI avoid doing the same work twice. For repositories linked to Vercel, remote caching is free and zero-configuration on Vercel builds. On other CI providers, the documented setup is to create TURBO_TOKEN and TURBO_TEAM environment variables. Locally, the announced flow is npx turbo login followed by npx turbo link, which connects a repository to the remote cache.

npx turbo login
npx turbo link

Sources: apps/docs/content/blog/free-vercel-remote-cache.mdx

Vercel deployments have the least manual Turborepo installation work. The Vercel guide says Vercel’s integration automatically understands the monorepo, and that importing code into a new Vercel project pre-configures the correct settings to use Vercel Remote Cache. That does not remove the value of a repository devDependency; it means the deployment platform can run Turborepo-aware builds and cache artifacts without the same manual token setup required by other CI systems.

Sources: apps/docs/content/docs/guides/ci-vendors/vercel.mdx

System-to-Code Mapping

The installation page is the canonical guide for user-facing install commands, the create-turbo quick start, the global-versus-repository recommendation, alias behavior for turbo run, and the warning about multiple global installations. The CI vendor guide demonstrates the repository-install model in a real automation file: root scripts call Turborepo tasks, dependencies are installed before execution, and optional remote-cache environment variables are documented near the job definition. The Vercel guide and remote-cache announcement extend installation into hosted environments by explaining when cache configuration is automatic and when credentials must be provided.

Sources: apps/docs/content/docs/getting-started/installation.mdx, apps/docs/content/docs/guides/ci-vendors/github-actions.mdx, apps/docs/content/docs/guides/ci-vendors/vercel.mdx, apps/docs/content/blog/free-vercel-remote-cache.mdx

The project history also matters for installation guidance. The joining-Vercel announcement states that the Turborepo CLI became open source and that older beta-era services and older CLI installability were being retired. Modern installation guidance should therefore prefer the current turbo package and the documented Vercel-backed remote-cache flows, rather than legacy beta service assumptions. Release notes such as Turborepo 2.10 reinforce the current upgrade and bootstrap commands, making @turbo/codemod migrate the update path and create-turbo@latest the new-project path.

Sources: apps/docs/content/blog/joining-vercel.mdx, apps/docs/content/blog/2-10.mdx

Relevant Source Files

• apps/docs/content/docs/getting-started/installation.mdx — Primary installation guide covering create-turbo, global installation, repository installation, turbo run alias behavior, and global-install caveats.
• apps/docs/content/blog/free-vercel-remote-cache.mdx — Remote cache announcement that documents local turbo login and turbo link setup plus CI variables for non-Vercel providers.
• apps/docs/content/blog/joining-vercel.mdx — Historical context for the open-source CLI and the move to Vercel-backed remote caching.
• apps/docs/content/docs/guides/ci-vendors/github-actions.mdx — Concrete CI example showing root scripts, turbo as a development dependency, dependency installation, and optional remote cache environment variables.
• apps/docs/content/docs/guides/ci-vendors/vercel.mdx — Vercel deployment guidance explaining automatic monorepo understanding and zero-config Vercel Remote Cache setup.
• apps/docs/content/blog/2-10.mdx — Release-note evidence for the current upgrade command and the continued recommendation to start new repositories with create-turbo@latest.

Next Steps

For a new project, run the create-turbo@latest command for your package manager, inspect the generated repository, and commit the package-manager lockfile. For an existing project, add turbo as a root development dependency, create scripts such as build, test, or dev that call turbo run, and optionally install the global CLI for faster interactive use. Once the CLI is installed, continue with task configuration, CI setup, and remote caching so the installed command is connected to a reproducible build workflow rather than sitting unused in the workspace.