How to Clone All Your Team's Repos with raid install

The first thing a new hire usually does on day one is clone the repos. With five services and a couple of shared libs, that's the rest of the morning. raid install collapses that into a single command — it reads the active profile, clones every repo in parallel, and runs each repo's install: tasks.

This guide covers the basic flow, the flags that matter, and how raid install behaves on subsequent runs.

1. The basic flow

Assuming you've already added a profile (see How to create a Raid profile):

raid install

Raid does, in order:

1. Reads the active profile and the list of repositories in it.
2. Clones every repo in parallel to the path: defined for each.
3. Runs the profile-level install: tasks: sequence.
4. Reports a summary.

The order is intentional — repos exist before any install task touches them, so an npm ci in a freshly cloned frontend repo will find its package.json.

2. Capping parallelism

raid install clones every repo concurrently by default. On a constrained network or a self-hosted runner with bandwidth limits, cap the parallelism with --threads N (or -t N):

raid install --threads 4

Four concurrent clones at a time. Worth a lower number on flaky connections; the default is fine on most local machines.

3. Installing a single repo

Sometimes you only want to bootstrap one repo — you added a new service to the profile and don't want to re-walk the others:

raid install <repo-name>

Clones just that repo (or skips the clone if it's already there) and runs that repo's install: tasks. Profile-level install tasks are skipped in single-repo mode — those are for whole-environment bootstrap, not per-service top-ups.

4. Idempotency

raid install is safe to re-run. A repo that's already at its path: is skipped, not re-cloned. Install tasks always run — they're expected to be idempotent themselves (npm ci is fine; a destructive bootstrap script that wipes state is not).

A few cases worth knowing:

• Repo path exists, repo not cloned (e.g. empty directory): Raid will use it as the clone target. Make sure it's actually empty if you don't want git to refuse.
• Repo with no url: (local-only): if the path exists, Raid uses it as-is. If the path doesn't exist, Raid errors out — there's no remote to clone from.
• Already-cloned repo at a different remote: Raid does not change the remote. It assumes you intentionally renamed something and leaves the working copy alone.

5. Per-repo install tasks

Each repo's raid.yaml can declare its own install: block — the per-repo bootstrap:

# frontend/raid.yaml
install:
  tasks:
    - type: Shell
      cmd: npm ci
    - type: Shell
      cmd: npm run codegen

raid install runs the profile-level tasks first, then each repo's tasks in the order their repos are listed in the profile.

This is the natural place for npm ci / pip install / cargo fetch / make tools — anything the repo needs to be runnable after a fresh clone.

6. The install block at profile level

A profile can also declare its own install: tasks — for cross-repo bootstrap (priming a shared database, generating a TLS cert, starting a docker-compose stack):

# acme.raid.yaml
install:
  tasks:
    - type: Shell
      cmd: docker compose -f ./infra/local.yml up -d
    - type: Wait
      url: http://localhost:5432
      timeout: 30s
    - type: Shell
      cmd: ./scripts/seed-db.sh

Profile-level tasks run after all repos are cloned and before per-repo install tasks. Useful for infra that every repo's install depends on.

7. Failure handling

If a clone fails, Raid reports the failure for that repo and continues with the others (a single repo's network blip shouldn't block the rest of the install). Once all clones are done, install tasks run only for the repos that successfully cloned.

The exit code is 4 (Network) when any clone failed, 3 (Task) when an install task failed, 0 on full success. See How to wire Raid into CI for using the categories.

8. The day-one onboarding flow

Putting it together, day one looks like:

# Install raid
brew install 8bitalex/tap/raid

# Register the team profile
raid profile add git@github.com:acme/raid-profiles.git

# Clone and bootstrap everything
raid install

# Pick the env
raid env local

# Start the dev server
raid dev

Five commands and the new hire is running the stack — no wiki archaeology, no Slack threads.

Next steps

• How to Create a Raid Profile — the file raid install reads from.
• How to Add a raid.yaml to an Existing Repo — where per-repo install tasks live.
• How to Add a Health Check to a Raid Workflow — pairing Wait with install for "start service, wait for it, run seed".