We use cookies to understand how people use Depot.
Cache

GitHub Actions

Depot Cache provides a remote cache service for GitHub Actions cache when running workflows on Depot-managed GitHub Actions runners, which provides faster upload and download speeds compared to the standard GitHub Actions cache.

Use GitHub Actions cache with Depot Cache

Depot Cache for GitHub Actions is only available when using Depot GitHub Actions runners. Standard GitHub-hosted runners or self-hosted runners use the standard GitHub Actions cache.

From Depot-managed Actions runners

Depot GitHub Actions runners are pre-configured to use Depot Cache for all GitHub Actions cache operations. When running workflows on Depot runners, any action that uses the GitHub Actions cache API automatically uses Depot Cache instead of the standard GitHub Actions cache.

This includes:

  • actions/cache - The standard caching action
  • actions/setup-node - Caches npm/yarn dependencies when you enable the cache option
  • actions/setup-python - Caches pip dependencies when you enable the cache option
  • actions/setup-java - Caches Maven/Gradle dependencies when you enable the cache option
  • Any other action that uses the GitHub Actions cache API

Example workflow

A workflow using actions/cache automatically uses Depot Cache when running on Depot runners, with no changes to your workflow file:

steps:
  - uses: actions/checkout@v4

  - name: Cache dependencies
    uses: actions/cache@v4
    with:
      path: ~/.npm
      key: ${{ runner.os }}-node-${{ hashFiles('**/package-lock.json') }}
      restore-keys: |
        ${{ runner.os }}-node-

  - name: Install dependencies
    run: npm ci

Compatibility with other tools

Depot Cache works with any tool or package manager that's compatible with the GitHub Actions cache API. When running on Depot runners, these tools automatically use Depot Cache for faster upload and download speeds.

For example, you can configure NX to use the GitHub Actions cache through the raegen/nx GitHub Action, which directly integrates with the GitHub Actions cache API, or by using the @nx/shared-fs-cache package combined with actions/cache to manually save and restore the .nx/cache directory.

Other build tools and package managers that integrate with GitHub Actions cache similarly work with Depot Cache without additional configuration.

Cache behavior

Repository scope

Depot Cache scopes cache entries by repository. This means that only the same repository that saved them can read cache entries.

Scoping cache by repository has the following benefits:

  • Repositories don't have key collisions when using the same cache key
  • One repository can't unexpectedly read cache entries from another repository of a different trust level (for example, a public repository reading from or writing to a private repository)

Branch isolation

Depot Cache doesn't enforce cache isolation based on the branch that runs the job. Whether the branch is main or another topic branch, the cache contributes to the same namespace making it accessible to other jobs. This allows you to control your cache isolation based on how you format your cache keys.

Cache retention and limits

The amount of Depot Cache storage you get depends on your plan. You can configure a cache retention policy (7, 14, or 30 days) and size limits (25 GB to 500 GB, or no limit) in your organization settings. The default cache retention policy is 14 days.