Are Bitbucket Pipelines caches shared across branches, and is that safe?

Yes. Bitbucket says caches are shared across all branches and all pipelines in the same repository. The documentation does not describe a separate cache for protected branches. Anything a feature branch writes can be restored by a later build, so keep release builds from trusting cached content blindly.

The facts from Bitbucket

Caches store external build dependencies and directories between builds. Predefined caches exist for Node.js, Composer, Maven, Gradle, pip, Docker, .NET Core and Ivy2, and custom caches use a definitions entry with a path. A cache expires after 7 days of inactivity, may be cleared at any time, and is capped at 1 GB compressed. Parallel steps can read caches but cannot write to them. Bitbucket's security advice is short: avoid sensitive data and never cache passwords or keys.

Compare this with GitLab, which separates protected and unprotected caches by default. See GitLab cache separation.

Why it matters

A poisoned cache is a quiet way into a build. If an untrusted change writes a modified dependency into a cache directory, and the next release step restores it, the release contains the change even if the lockfile is clean. The general pattern is in cache poisoning attacks and prevention.

Steps to reduce the risk

1. Use file based cache keys so a lockfile change refreshes the cache. Bitbucket says a changed package-lock.json regenerates the cache.
2. Do not cache build output or tools you will run. Cache download directories only.
3. For release and deploy steps, skip the cache or use a distinct key that only the default branch pipeline writes.
4. Require review of changes to bitbucket-pipelines.yml, since it defines cache paths.
5. To clear a cache, change the key such as npm-v1 to npm-v2, or use Repository Settings, Pipelines, Caches, Clear cache.
6. Verify downloads with a lockfile and integrity checks, using locked installs such as in npm ci versus npm install.

definitions:
  caches:
    npm-v1: ~/.npm
pipelines:
  default:
    - step:
        caches:
          - npm-v1
        script:
          - npm ci

Common mistakes

Teams sometimes cache the whole home directory or a build output folder because it makes the pipeline faster. That widens what a poisoned cache can reach. Others forget that a cache can outlive a dependency fix, so a vulnerable package keeps being restored after the lockfile changed on another branch. Name caches by purpose, keep paths narrow, and rotate the key when you patch something important. A short comment next to each cache definition explaining what it holds also helps the next reviewer.

Try it yourself

Click through it at your own pace, or open it full screen. Look at the exact versions listed per package, which is the baseline you compare a cached build against.

Safeguard's dependency and SBOM scanning produces that inventory, and you can try a free scan at https://gold.safeguard.sh/scan.

Quick check

Sources

• Atlassian: Caches in Bitbucket Pipelines, fetched 19 October 2026.

Last reviewed: 19 October 2026.