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

  • A 64-Bit Linux instance with at least 8GB of RAM as a host for the runner.

  • Allocate at least minimum 512MB memory for the runner container.

  • Docker v19.03 and above - Install Docker

 

Linux Shell

  • OpenJDK 11 (11.0.15 or newer) is installed

  • Git 2.35.0 and above

  • Bash 3.2 and above

  • A 64-Bit Linux instance with at least 8GB of RAM as a host for the runner.

Windows

MacOS

  • OpenJDK 11 (11.0.11 or newer) is installed

  • Git 2.35.0 and above

  • A 64-Bit MacOS instance with at least 8GB of RAM as a host for the runner.

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.

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: The number of steps your workspace can run at once across all pipelines varies according to your plan.

    • Standard and premium workspaces can support 600 steps running concurrently across multiple pipelines.

    • Free workspaces can support 10 steps runnings concurrently across multiple pipelines.

    • Once this limit is reached, excess steps will fail.

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

  • 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.

Still need help?

The Atlassian Community is here for you.