Bamboo Artifact Sharing: Configuring Multi-Stage Pipelines with Plan Dependencies

What artifact sharing does and why it matters

Bamboo artifact sharing lets a downstream plan automatically fetch files produced by an upstream plan. This is the primary mechanism for building multi-stage CI/CD pipelines—compile and test in one plan, then deploy or run integration tests in another—without manually copying files between agents or using external storage.

The upstream plan publishes artifacts (JARs, Docker images, test reports, etc.) to a shared directory on the Bamboo server (or configured external storage). The downstream plan declares a dependency on those artifacts by source plan key and artifact name. Before the downstream plan runs, Bamboo copies the artifacts into the downstream plan's working directory, making them available to tasks and scripts.

Worked example: publishing a JAR and consuming it in a deploy plan

Assume two plans in the same Bamboo instance:

• PROJECT-BUILD (plan key PROJ-BUILD) compiles a Java project and produces target/app.jar.
• PROJECT-DEPLOY (plan key PROJ-DEPLOY) needs that JAR to build a Docker image and push it to a registry.

Step 1: Define the artifact in the upstream plan

In the Bamboo UI, open PROJECT-BUILD → Artifacts tab → Create artifact:

• Name: app-jar (this becomes the artifact key)
• Location: target/app.jar (relative to the plan's working directory)
• Copy pattern: target/app.jar (or leave blank to use location)

Save. On each successful build, Bamboo stores app.jar under the artifact key app-jar indexed by the build number.

Step 2: Declare the dependency in the downstream plan

Open PROJECT-DEPLOY → Artifacts tab → Add artifact dependency:

• Source plan: PROJ-BUILD (select from dropdown)
• Artifact: app-jar (must match the upstream artifact key exactly)
• Destination path: artifacts/app.jar (relative to downstream working directory; optional, defaults to artifact name)

Save. When PROJECT-DEPLOY runs, Bamboo copies the latest successful build's app.jar from PROJ-BUILD into artifacts/app.jar before any task executes.

Equivalent Bamboo Specs (YAML) for version-controlled pipeline definition

version: 2
plans:
  - key: PROJ-BUILD
    name: Project Build
    artifacts:
      - name: app-jar
        location: target/app.jar
        pattern: target/app.jar
  - key: PROJ-DEPLOY
    name: Project Deploy
    artifactDependencies:
      - sourcePlanKey: PROJ-BUILD
        artifactName: app-jar
        destinationPath: artifacts/app.jar

Store this YAML in your repository and enable Bamboo Specs scanning to keep pipeline configuration in sync with code.

How versioning works and why pinning matters

Artifacts are bound to the source plan's build number. By default, a downstream plan pulls artifacts from the latest successful build of the source plan. If PROJ-BUILD runs again (even a manual re-run) before PROJ-DEPLOY starts, the downstream plan will consume the newer artifact—potentially deploying an untested or unintended version.

To pin a specific version, use plan branches or trigger dependencies:

• Configure PROJ-DEPLOY to trigger only after PROJ-BUILD completes successfully on the same branch (branch matching).
• For release pipelines, use a manual stage or a deployment project that selects a specific build number from the source plan.

Without explicit pinning, the "latest successful" behavior can cause surprising rollbacks or double-deploys when developers re-run builds.

Performance limits and storage quotas

Bamboo enforces per-artifact size limits and total storage quotas that vary by instance configuration (Server/Data Center vs. Cloud). Typical defaults:

Limit	Typical default	Notes
Max artifact size	100 MB (Server), 250 MB (Cloud)	Configurable in bamboo.cfg.xml for Server/DC
Total artifact storage per plan	1 GB (Cloud)	Server/DC: limited by disk space and artifact.max.size
Artifact retention	30 days (Cloud), configurable (Server/DC)	Old builds' artifacts are purged automatically

Large artifacts (e.g., Docker image tarballs, VM images) can slow down the copy step and consume agent disk space. Mitigations:

• Split monolithic artifacts into smaller, logical pieces (separate JAR, test reports, docs).
• Use external artifact repositories (Nexus, Artifactory, S3) for heavy binaries; store only metadata or SHA references in Bamboo.
• Enable artifact compression in the upstream plan (checkbox "Compress artifact") to reduce transfer time.

Common mistakes that break dependencies

1. Changing the artifact location or name in the upstream plan without updating the downstream dependency. Paths are relative to the plan's working directory; moving target/app.jar to build/app.jar breaks the copy because the stored artifact still references the old path.
2. Renaming the artifact key (e.g., from app-jar to application-jar) without updating the downstream plan's artifact dependency. The key is the lookup identifier.
3. Assuming cross-instance sharing works. Artifacts cannot be shared between separate Bamboo instances (even if they share a database). Use an external repository for cross-instance handoffs.
4. Ignoring branch mismatch. If PROJ-BUILD runs on branch feature/x and PROJ-DEPLOY runs on main, the downstream plan may pull artifacts from the wrong branch unless branch matching is enforced.
5. Exceeding storage quotas causing silent artifact truncation or plan failures. Monitor the Artifact storage report in Bamboo administration.

Verification checklist

After configuring a new artifact dependency:

• Open the downstream plan's Artifacts tab and confirm the source plan key and artifact name appear exactly as defined upstream.
• Trigger a build of the upstream plan and wait for success.
• Trigger the downstream plan (manually or via trigger). In the build log, look for lines like Downloading artifact [app-jar] from plan [PROJ-BUILD] build [123].
• Add a temporary script task in the downstream plan to list the working directory and verify artifacts/app.jar exists and has the expected size.

When to consider alternatives

Artifact sharing is ideal for small-to-medium binaries produced and consumed within the same Bamboo instance. Consider external repositories when:

• Artifacts exceed Bamboo's size limits or retention policies.
• Multiple independent pipelines (or teams) need access to the same artifacts.
• You require immutable, versioned artifact storage with metadata (signatures, SBOMs, vulnerability scans).

In those cases, publish to Nexus/Artifactory/S3 from the upstream plan and download in the downstream plan using credentials stored in Bamboo's shared credentials.