Lesstep
Bitbucket Cloud · Pipelines · Checked October 30, 2026

Bitbucket Pipelines: Build setup takes too long

Build setup is the first section of a step's log, before the first line of your script. Atlassian's article on it (Bitbucket Pipelines build setup is running longer than expected) says its time includes, among other things, cloning the repository and, for steps on Atlassian's machines or a self-hosted Linux Docker runner, pulling the step's Docker image. Which of the two is slow decides what to change, and the log times neither.

What Build setup shows

From a step log posted in a community thread in 2022, shortened and wrapped to fit here:

Build setup 14m 55s
+ GIT_LFS_SKIP_SMUDGE=1 retry 6
  git clone --branch="…"
  --depth 50 … $BUILD_DIR
+ git reset --hard 362cec8…
Cache "maven": Downloading
Cache "maven": Downloaded
  214.3 MiB in 6 seconds
Cache "maven": Extracting
Cache "maven": Extracted in 1 seconds
Images used:
build : eu.gcr.io/…@sha256:b569…

Only the caches report their own time. The clone and the image pull have none, so what is left of Build setup after the caches is mostly those two. Images used lists the build image and, when the step has services, their images as well; each of them is pulled.

1. Time both on your computer

Atlassian's article asks you to clone the repository and pull the image on your own computer and compare the times with Build setup. Clone the way the step does: its branch (for a pull-request build, the source branch) with depth 50, unless your bitbucket-pipelines.yml sets another depth. The article's commands use an app password, which Bitbucket stopped accepting in July 2026 ("The requested URL returned error: 410"); with an API token that has read:repository:bitbucket instead (Atlassian's Using API tokens):

r=bitbucket.org/<workspace>/<repo>
a="x-token-auth:$BB_TOKEN"
time git clone --branch=main \
  --depth 50 "https://$a@$r.git" t
rm -rf t

The token is saved in t/.git/config, so delete t afterwards. For a pull-request build, or one started on a commit, leave out --depth 50: Atlassian says those always clone in full. Then pull each image named in Images used, copied with its digest:

i='<an image from Images used>'
time docker pull "$i"

If one of them takes about as long as Build setup, that is the one to make smaller: section 2 for the clone, section 3 for the image. If both are much faster on your computer than in Pipelines, look at Bitbucket's status page; otherwise Atlassian's article asks for a support ticket with the build's URL. The registry can be the slow part too: in the 2022 thread above, Atlassian found that images on gcr.io were slow to pull while images on Artifact Registry (pkg.dev) were not.

2. A large repository

A smaller depth. The clone takes the last 50 commits unless you set depth (Atlassian's Git clone behavior):

- step:
    clone:
      depth: 10

Atlassian's article notes that this does not help pull-request builds or builds started on a commit, which always clone in full. Don't go too low: the step clones the branch and then resets to the build's commit, so with depth: 10 that commit must still be among the branch's last 10 commits when the step starts. If it isn't, the step fails with "Could not parse object".

Git LFS. The clone in the log above runs with GIT_LFS_SKIP_SMUDGE=1, and lfs is false by default, so LFS files are not downloaded unless you set lfs: true. Set for the whole pipeline, it downloads every LFS file at the start of every step. Atlassian recommends turning it on only in the steps that need it, or downloading only the files a step needs:

- step:
    script:
      - git lfs pull --include=big.zip

That needs git-lfs in the image; Atlassian's example installs it with apt-get first.

Steps that don't need the code. enabled: false skips the clone, for one step or for all of them:

- step:
    clone:
      enabled: false

Large files in the history. A full clone, such as every pull-request build, carries every large file ever committed, deleted ones included. Atlassian's article suggests rewriting the history to remove files that don't need to be versioned (Reduce repository size).

3. A large image

This applies to steps on Atlassian's machines or a self-hosted Linux Docker runner. Linux shell, macOS and Windows runners run the step on the host without Docker and pull no image.

Public images are cached. Atlassian announced in 2017 that Pipelines caches public Docker images, and in a 2024 answer an Atlassian engineer added that a public image not used before is cached in the background, so the next build that uses it starts much faster. So the first build after you switch to a new public image or tag is the slow one; if the second is just as slow, it isn't that. The answer is about public images and says nothing about private ones.

A smaller image. A step with no image runs in atlassian/default-image:latest (Atlassian's Use Docker images as build environments), and Atlassian suggests a specific image instead, for faster builds. Sizes as Docker Hub lists them for linux/amd64 (compressed, which is what a pull downloads) on October 30, 2026:

A slim or Alpine image may lack a tool your script uses; the step then stops at "command not found". For an image you build yourself, Atlassian's tips are to keep it small and to order the Dockerfile so its layers can be reused.

Services. Each service in Images used is pulled as well, so a step that doesn't use a service shouldn't list it.

4. Caches

Caches are downloaded and extracted in Build setup, and these lines do show their time. If Downloaded and Extracted take most of Build setup, the time is there. A cache is at most 1 GB compressed (Atlassian's Caches). If a cache isn't restored at all, see The cache is not used.

From IntelliJ IDEA

Pipeline Inbox for Bitbucket Pipelines, a plugin by Lesstep for JetBrains IDEs 2024.1 or later, lists the pipelines of all your Bitbucket Cloud repositories in an IDE tool window with how long each run took, and each step with its duration and image. Each step's log, Build setup included, opens in the IDE and can be searched for Cache and Images used, so you can compare a slow run with a fast one. After switching to a new public image, Run again (Pro) builds the same commit once more and shows whether the second pull is faster. The list, steps and logs are free; running, re-running and stopping pipelines are Pro (US$1.50 a month, with a 30-day trial).

Get it on JetBrains Marketplace

Atlassian, Bitbucket and Bitbucket Pipelines are trademarks of Atlassian; Git is a trademark of Software Freedom Conservancy; Docker is a trademark of Docker, Inc.; Google Cloud and Artifact Registry are trademarks of Google LLC; Node.js is a trademark of the OpenJS Foundation; Ubuntu is a trademark of Canonical Ltd.; Windows is a trademark of the Microsoft group of companies; macOS is a trademark of Apple Inc.; IntelliJ IDEA is a trademark of JetBrains s.r.o. This page is not affiliated with or endorsed by any of them.

More: The build passed before and fails now · The artifact is missing in the next step · "Step exceeded processing limits" · "Exceeded build time limit of 120 minutes" · "No space left on device" · "No online runner available" · "We couldn't clone the repository" · Submodules not cloned · "command not found" · "unexpected system error" · The cache is not used · Pipelines did not run after a push · "Container 'Build' exceeded memory limit." · "Container 'docker' exceeded memory limit." · "You've run out of build minutes" · "Permission denied to update branch" · "You have reached your pull rate limit" (Docker Hub) · "There is an error in your bitbucket-pipelines.yml" · "This pipeline was paused" (deployments) · Bitbucket Pipelines plugins for IntelliJ IDEA, compared · 日本語