Runners

Runners allows you to run builds in Pipelines on your own infrastructure, and you won’t be charged for the build minutes used by your self-hosted runners. The following guides help you configure your operating system with Pipelines to use runners within your repositories.

Supported platforms

Currently, we only support the following:

• Linux with x64 and ARM architecture and a Linux kernel v4.0.0+. The runners have been tested on the following Linux distributions:

  • Ubuntu 22.04

  • Debian 11

  • Centos 7

  • Fedora 36

  • Oracle Linux 8.6

  • Amazon Linux 2

• Windows 10+ or Windows Server 2019+

• MacOS Catalina 10.15+

Minimum Requirements

Linux Docker

Linux Shell

Windows

MacOS

Runners in Bitbucket

You can configure and manage runners at different levels:

• Repository runners are available on a single repository.

• Workspace runners can run builds for multiple repositories in a workspace, sharing the same runner across different repositories and teams.

Queue for steps

Each workspace features a global queue of all steps run on self-hosted runners. This queue is shared amongst all pipelines in that workspace. Each step remains in the queue while it is waiting for a compatible runner to become available. Once the step is completed or stopped, it is removed from the step queue.

Runner Changelog

View the Bitbucket Pipelines Runner Changelog.

Usage limits

The following are the usage limits or quotas applied to Bitbucket Pipelines Runners:

• Step build time. Similar to Cloud, there is a maximum build time of 120 minutes per step. To reduce the total run time, we recommend using more parallel steps within your CI/CD workflow.

• Max available memory. With Runners, you can configure up to 32GB (8x) of memory to run your builds.

• API rate-limits:

  • Bitbucket rate-limits: Runners are subject to the same API rate-limits described in this document: API request limits.

  • Artifacts/ cache/ log rate-limits: The rate limit is 2000 requests/per minute per runner.

  • Download rate-limit on Docker Hub: Docker Hub has its own rate limits that can affect you. Authenticated users have a better image pull rate so we recommend to login to your docker hub account on a docker host.

• Total number of steps per pipeline: You can configure a maximum of 100 steps per pipeline in the YAML file.

• Total number of steps running concurrently: In a workspace on a Standard or Premium plan, you can configure the maximum number of steps that a workspace can run on self-hosted runners at once across all pipelines:

  • Standard workspaces include 1 step running concurrently across multiple pipelines

  • Premium workspaces include 2 concurrently running steps. Increasing the runner concurrency limit for your workspace above the included quota incurs a charge.

  • Free workspaces include 1 step running concurrently across multiple pipelines, and this limit is not configurable.

• Step queue time: Steps can be queued for a maximum of 2.5 hours.

• Step queue size: The queue can fit up to 1,000 steps. If the queue is at capacity, any step that is attempted to be added will immediately fail.

• Total number of runners: You can configure up to 100 runners per workspace and 100 runners per repository.

Linux Docker-only

• Can’t access the local files on the runner host from a build script: In order to provide isolation and reproducibility, a runner doesn’t provide access directly to the host file system, we recommend using SCP / Rsync, if necessary.

The limits described above are subject to change in the future.