Create a New Monorepo

Purpose and Scope

Use create-turbo when you want a new Turborepo repository that is already shaped like the docs expect: a JavaScript or TypeScript workspace with Turborepo installed, package-manager integration selected, and a starter structure ready for task orchestration. The first-party reference describes create-turbo as the easiest way to start with Turborepo because it scaffolds a new monorepo from scratch instead of asking you to assemble workspaces, scripts, and examples manually. That makes it the shortest path for learning the conventions before adapting them to a production repository.

Sources: apps/docs/content/docs/reference/create-turbo.mdx

This page focuses on bootstrapping rather than migrating an existing repository. If you already have packages, lockfiles, and application code, you may still compare your layout with a generated project, but the create flow is designed for a clean start. The related guide callout also shows how many Turborepo guides assume either a create-turbo repository or another repository with a similar structure, so using it gives you a known baseline for later caching, task, and framework guidance.

Sources: apps/docs/content/docs/guides/tools/create-turbo-callout.tsx

Relevant Source Files

• apps/docs/content/docs/reference/create-turbo.mdx - Defines the public create-turbo reference page, package-manager commands, example bootstrapping flow, custom GitHub starter support, and CLI options.
• apps/docs/content/docs/guides/tools/create-turbo-callout.tsx - Provides a reusable docs callout that states tool guides assume create-turbo or a similarly structured repository.
• apps/docs/content/blog/free-vercel-remote-cache.mdx - Explains why a newly created repository can later benefit from Vercel Remote Cache with turbo login, turbo link, and CI environment variables.
• apps/docs/content/blog/joining-vercel.mdx - Gives historical context for Vercel-backed remote caching and the open-source CLI, which matters after bootstrapping when teams connect shared cache.
• apps/docs/content/blog/turbo-0-4-0.mdx - Documents historical build-system capabilities such as smarter hashing, task orchestration, output cache control, and pruned workspaces that shaped modern starter workflows.
• apps/docs/content/blog/turbo-1-1-0.mdx - Documents the move to root turbo.json, package-manager detection through packageManager, environment variable dependencies, and automatic migrations.

Bootstrap Commands

Run the command that matches the package manager you want the new workspace to use. The reference page presents equivalent commands for pnpm, Yarn, npm, and Bun, so the command choice is mostly about your team’s package-manager standard. create-turbo then prompts for project details and prepares the starter. If you are evaluating Turborepo for the first time, using the default starter is useful because the generated repository demonstrates how packages, apps, and tasks fit together before you add framework-specific complexity.

Sources: apps/docs/content/docs/reference/create-turbo.mdx

pnpm dlx create-turbo@latest

yarn dlx create-turbo@latest

npx create-turbo@latest

bunx create-turbo@latest

After generation, treat the scaffold as a working reference implementation. The docs’ caching tutorial uses npx create-turbo@latest as the first step before running turbo build and observing a cache hit on a later run. That sequence is important because a fresh repository lets you see Turborepo’s contract clearly: tasks run from package scripts, task outputs are restored when their inputs have not changed, and the repository structure is discoverable before you tune it for your own application layout.

Sources: apps/docs/content/docs/reference/create-turbo.mdx

Starting from Examples and Templates

The --example flag changes the bootstrap experience from “create the default starter” to “start from a named example or external starter.” The reference page distinguishes core-maintained examples from community-maintained examples. Core-maintained examples are kept up to date by the Turborepo core team and accept GitHub issues, while community examples showcase additional tools and libraries. Choose a core example when you want the most stable learning path, and choose a community example when you want to inspect an integration pattern closer to your stack.

Sources: apps/docs/content/docs/reference/create-turbo.mdx

pnpm dlx create-turbo@latest --example [example-name]
yarn dlx create-turbo@latest --example [example-name]
npx create-turbo@latest --example [example-name]
bunx create-turbo@latest --example [example-name]

A custom GitHub URL is useful when your organization maintains its own starter, when you want to try a community repository that is not listed in the official examples table, or when you need a branch or subdirectory from a larger repository. The same --example option accepts either an official example name or a GitHub URL. If the URL’s branch name contains a slash and the example also lives under a subdirectory, use --example-path to disambiguate the path to the example.

Sources: apps/docs/content/docs/reference/create-turbo.mdx

npx create-turbo@latest --example [github-url]
npx create-turbo@latest --example [github-url] --example-path foo/bar

CLI Options Reference

The reference page exposes a compact option surface. -m or --package-manager selects one of npm, yarn, pnpm, or bun; this is the option to use when you want deterministic scaffolding in automation instead of answering an interactive prompt. --turbo-version <version> pins the generated repository to a specific turbo version rather than the latest release. --skip-install leaves dependency installation to a later step, which is useful in CI-like provisioning or when you need to inspect files before installing.

Sources: apps/docs/content/docs/reference/create-turbo.mdx

--skip-transforms disables code transformations after the project is created. Keep the default behavior unless you have a reason to preserve the starter exactly as fetched. -e or --example [name]|[github-url] selects an official example or custom starter, and -p or --example-path <path-to-example> resolves the uncommon case where the GitHub URL alone cannot identify both the branch and the example directory. -v reports the current version, and -h displays command help.

Sources: apps/docs/content/docs/reference/create-turbo.mdx

How the Generated Repository Fits Turborepo

A generated monorepo is not only a file scaffold; it is a runnable demonstration of Turborepo’s core model. Turborepo’s history explains why the project emphasizes hashing, task scheduling, cache outputs, and pruned workspaces. Earlier release notes describe improvements to hashing so dependency changes only invalidate affected work, task orchestration through configuration, and output-level cache control. Those capabilities are easier to understand when you can run a small generated workspace and then change one package, one dependency, or one task definition at a time.

Sources: apps/docs/content/blog/turbo-0-4-0.mdx

Modern generated repositories also align with later configuration conventions. Turborepo 1.1 moved configuration into a root turbo.json, added faster package-manager detection from the root packageManager key, and documented environment variable dependencies for caching. Those historical notes matter because a starter repository gives you today’s expected shape: package-manager metadata at the root, Turborepo configuration in a dedicated file, and task definitions that can be expanded as your workspace grows.

Sources: apps/docs/content/blog/turbo-1-1-0.mdx

After Creation: Cache and Team Workflow

Once the repository exists, the next step is usually to run the starter tasks and then connect team-level caching. Turborepo’s Vercel integration provides a Remote Cache path where linked repositories can share task artifacts so developers and CI do not repeat the same work. The blog announcement for free Vercel Remote Cache describes local setup with npx turbo login and npx turbo link, while CI providers authenticate with TURBO_TOKEN and TURBO_TEAM. That is not part of scaffolding, but it is the natural follow-up after the first successful build.

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

npx turbo login
npx turbo link

For a practical first session, create the repository, install dependencies unless you skipped installation, run the generated build task, and then run it again to observe caching behavior. Next, inspect the example’s package scripts and Turborepo configuration before adding new apps or packages. If your team is choosing a template, prefer a core-maintained example for baseline learning, a community example for specific integrations, or a GitHub URL when you need an internal starter that encodes your organization’s conventions.

Sources: apps/docs/content/docs/reference/create-turbo.mdx, apps/docs/content/blog/free-vercel-remote-cache.mdx