dbt deps 500 Internal Server Error on dbt 2: the fix

If you installed dbt 2.0.6 with pip and dbt deps fails with 500 Internal Server Error from codeload.github.com, on a different package each run, you are probably hitting dbt issue 16620. The reported workaround is to install dbt as the native binary (the install script, Homebrew or winget) in place of pip: in the report, 8 of 8 pip runs failed and the binary passed every run. The cause is not confirmed yet.

Is this your bug?

It is likely if all of these hold:

• dbt --version says 2.0.x, and you installed it with pip install dbt.

• The error names codeload.github.com and a 500:

  [error] [RuntimeError (dbt8999)]: Failed to get tarball from
  https://codeload.github.com/metaplane/dbt-expectations/tar.gz/0.10.10; status: 500 Internal Server Error
  

• Run it again, and a different package fails while the rest install.

• GitHub's status page shows no incident. A real outage fails everything, every time.

Watch for one detail in the output: the run still prints "Installed 4 packages" even when one failed, so read the errors at the end, not the summary.

What the report shows

The reporter used pinned package versions (dbt_utils 1.4.1, dbt_expectations 0.10.10 and elementary 0.26.0, the first releases that allow dbt 2) in a clean folder, on a Mac and on GitHub Actions' Ubuntu runners:

So changing package versions is unlikely to help. The report does not say whether simply re-running ever passes; with every pip run failing, a retry loop is not a fix.

Try itIs it the dbt deps bug?

Installed with pip?

YesNo

dbt --version says 2.0.x?

YesNo

Error names codeload.github.com and a 500?

YesNo

A different package fails each run?

YesNo

GitHub's status page shows an incident?

YesNo

Matches dbt issue 16620

pip install dbt==2.0.6

1. ✕ elementary
2. ✕ elementary
3. ✕ elementary
4. ✕ elementary
5. ✕ dbt_expectations
6. ✕ dbt_expectations
7. ✕ dbt_expectations
8. ✕ dbt_utils

native binary, 2.0.6

1. ✓ passed
2. ✓ passed
3. ✓ passed
4. ✓ passed
5. ✓ passed
6. ✓ passed
7. ✓ passed
8. ✓ passed
9. ✓ passed
10. ✓ passed
11. ✓ passed

Confirm it in 2 minutes

Run dbt deps a few times in fresh folders and note which package fails each time. If the name changes from run to run, it matches the report; if the same package fails every time, look at that package's entry in packages.yml instead.

for i in 1 2 3 4 5; do
  rm -rf dbt_packages
  dbt deps 2>&1 | grep -o 'codeload.github.com/[^ ;]*' || echo "run $i: no download error"
done

Run it once with the pip install and once with the native binary (below). The report's pattern was a failure on every pip run and none on the binary.

Fix it on your machine

Remove the pip install first, so the old one does not shadow the new one:

python -m pip uninstall dbt

Then install the binary:

# macOS or Linux
curl -fsSL https://public.cdn.getdbt.com/fs/install/install.sh | sh -s -- --update
exec $SHELL

# or, on a Mac, with Homebrew
brew tap dbt-labs/dbt
brew install dbt-labs/dbt/dbt

On Windows, winget install --id dbtLabs.dbt --exact. Check that the shell finds the new one: which dbt should print ~/.local/bin/dbt (or Homebrew's folder), and dbt --version should print 2.0.x. If which dbt still points into a virtual environment, deactivate it.

Fix it in CI

In GitHub Actions, swap the pip step for the install script, pinned to a version so every run builds with the same dbt:

# Before
- run: pip install dbt==2.0.6

# After
- name: Install dbt (native binary)
  run: |
    curl -fsSL https://public.cdn.getdbt.com/fs/install/install.sh | sh -s -- --version 2.0.6 --to "$HOME/.local/bin"
    echo "$HOME/.local/bin" >> "$GITHUB_PATH"
- run: dbt --version
- run: dbt deps

The script supports Linux on x86_64 and ARM and macOS on Intel and Apple silicon, so it covers GitHub's Ubuntu and macOS runners; on Windows runners, use winget install --id dbtLabs.dbt --exact --version 2.0.6. It downloads jq if the runner lacks it.

2 more things make CI steady whichever way dbt is installed:

• Commit package-lock.yml. It records the exact versions dbt deps resolved, so every run installs the same ones.
• Cache dbt_packages/ keyed on the lock file's hash, and run dbt deps only when the cache misses, so most runs download nothing:

- uses: actions/cache@v6
  id: dbt-packages
  with:
    path: dbt_packages
    key: dbt-packages-${{ hashFiles('package-lock.yml') }}
- if: steps.dbt-packages.outputs.cache-hit != 'true'
  run: dbt deps

The cache does not fix the bug, but it shrinks how often a run meets it: only a change to the lock file downloads again.

Is the binary fine for production?

It is one of dbt Labs' documented install methods, alongside pip, and it pins to an exact version with --version, so builds are as reproducible as with pip. Upgrade it with dbt system update (or brew upgrade dbt), and change the pinned version in CI on purpose, not by accident. Read the release notes before each bump.

When to switch back to pip

Watch issue 16620. As of 19 October 2026 it is open with no reply from dbt Labs, and dbt 2.0.8 (14 October) lists no change to dbt deps. When a release says it fixed the download, try pip on a branch: run dbt deps in a clean folder several times, since the failure was random, before you change the main pipeline.