macOS hosted agents
Buildkite's macOS hosted agents are:
Buildkite Agents hosted by Buildkite that run in a macOS environment.
Configured as part of a Buildkite hosted queue, where the Buildkite hosted agent's machine type is macOS, has a particular size to efficiently manage jobs with varying requirements, and comes pre-installed with software.
Learn more about:
Best practices for configuring queues in How should I structure my queues of the Clusters overview, as well as Manage queues.
How to configure a macOS hosted agent in Create a Buildkite hosted queue.
How to use macOS hosted agents to build iOS apps.
The security of macOS hosted agents.
Sizes
Buildkite offers a selection of macOS instance types (each based on a different size combination of virtual CPU power and memory capacity, known as an instance shape), allowing you to tailor your hosted agents' resources to the demands of your jobs.
| Instance shape | Size | vCPU | Memory | Disk space | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Instance shape | Instance shape |
MACOS_ARM64_M4_6X28
|
Size | Size | Medium | vCPU | vCPU | 6 | Memory | Memory | 28 GB | Disk space | Disk space | 182 GB |
| Instance shape | Instance shape |
MACOS_ARM64_M4_12X56
|
Size | Size | Large | vCPU | vCPU | 12 | Memory | Memory | 56 GB | Disk space | Disk space | 294 GB |
Note: Shapes MACOS_M2_4X7, MACOS_M2_6X14, MACOS_M2_12X28, MACOS_M4_12X56 were deprecated and removed on July 1, 2025.
Also note the following about macOS hosted agent instances.
Only Apple silicon architectures are supported.
To accommodate different workloads, instances are capable of running up to 4 hours.
If you have specific needs for Intel architecture machines, or longer running hosted agents (over 4 hours), please contact Support at support@buildkite.com.
Concurrency
macOS hosted agents can operate concurrently when running your Buildkite pipeline jobs.
This concurrency is measured by the number of hosted agent machines that are allocated for your jobs at any given time. A machine is counted from the moment it starts booting to acquire a job, since that's when the machine starts consuming capacity. As a result, concurrency may not always match the exact number of running jobs, particularly with short-lived workloads.
The number of macOS hosted agents (of a Buildkite hosted queue) that can process your pipeline jobs concurrently is calculated by your Buildkite plan's maximum combined vCPU value divided by your instance shape's vCPU value. See the Buildkite pricing page for details on the Mac M4 Concurrency that applies to your plan.
For example, if your Buildkite plan provides you with a maximum combined vCPU value is up to 24, and you've configured a Buildkite hosted queue with the MACOS_ARM64_M4_6X28 (Medium) instance shape, whose vCPU value is 6, then the number of concurrent hosted agents that can run jobs on this queue is 4 (that is, 24 / 6 = 4).
When concurrency limits are exceeded, additional jobs will be queued until sufficient capacity becomes available.
macOS instance software support
All standard macOS Tahoe, Sequoia and Sonoma version instances have their own respective Xcode and runtime software versions available by default (listed below). Each macOS version also has its own set of Homebrew packages with specific versions optimized for that operating system. If you have specific requirements for software that is not listed here, please contact Support at support@buildkite.com.
While you currently cannot provide custom base images for macOS hosted agents (as is possible using agent images for Linux hosted agents), you do have significant control over these virtual machines during job execution—including the ability to install software using Homebrew, use git mirroring for performance, and leverage persistent cache volumes.
Updated Xcode versions will be available one week after Apple offers them for download. This includes Beta, Release Candidate (RC), and official release versions.
macOS Tahoe
- 26.0
Xcode
- 26.0
- 16.4
Runtimes
iOS
- 26.0
- 18.6
- 17.5
tvOS
- 26.0
- 17.5
- 16.4
visionOS
- 26.0
- 2.5
- 1.2
watchOS
- 26.0
- 11.5
- 10.5
macOS Sequoia
- 15.6.1
Xcode
- 26.0
- 16.4
- 16.3
- 16.2
- 16.1
- 16.0
- 15.4
Runtimes
iOS
- 26.0
- 18.6
- 18.5
- 18.4 RC
- 18.2 RC
- 18.1
- 18.0
- 17.5
- 16.4
- 15.5
tvOS
- 26.0
- 18.5
- 18.4 RC
- 18.2 RC
- 18.1
- 18.0
- 17.5
- 16.4
visionOS
- 26.0
- 2.5
- 2.4 RC
- 2.2 RC
- 2.1
- 2.0
- 1.2
- 1.1
- 1.0
watchOS
- 26.0
- 11.5
- 11.4 RC
- 11.2 RC
- 11.1
- 11.0
- 10.5
- 9.4
macOS Sonoma
- 14.6.1
Xcode
- 16.3
- 16.2
- 16.1
- 16.0
- 15.4
- 15.3
- 15.2
- 15.1
- 14.3.1
Runtimes
iOS
- 18.4 RC
- 18.2 RC
- 18.1
- 18.0
- 17.5
- 17.4
- 17.2
- 16.4
- 16.2
- 15.5
tvOS
- 18.4 RC
- 18.2 RC
- 18.1
- 18.0
- 17.5
- 17.4
- 17.2
- 16.4
visionOS
- 2.4 RC
- 2.2 RC
- 2.1
- 2.0
- 1.2
- 1.1
- 1.0
watchOS
- 11.4 RC
- 11.2 RC
- 11.1
- 11.0
- 10.5
- 10.4
- 10.2
- 9.4
Homebrew packages
The versions for each of these packages varies by macOS version. See Identifying Homebrew package versions for instructions on how to identify each package's version.
- ant
- applesimutils
- aria2
- awscli
- azcopy
- azure-cli
- bazelisk
- bicep
- carthage
- cmake
- cocoapods
- curl
- deno
- docker
- fastlane
- gcc@13
- gh
- git
- git-lfs
- gmp
- gnu-tar
- gnupg
- go
- gradle
- httpd
- jq
- kotlin
- libpq
- llvm
- llvm@15
- maven
- mint
- nginx
- node
- openssl@3
- p7zip
- packer
- perl
- php
- pkgconf
- postgresql@14
- python@3.13
- r
- rbenv
- rbenv-bundler
- ruby
- rust
- rustup
- selenium-server
- swiftformat
- swiftlint
- tmux
- unxip
- wget
- xcbeautify
- xcodes
- yq
- zstd
Identifying Homebrew package versions
To find the Homebrew package version used by your macOS hosted agent:
- Select Agents in the global navigation > your cluster containing the macOS Buildkite hosted agent queue > your macOS hosted agent.
- On your macOS hosted agent's page, select Base image and scroll down to Specifications > Homebrew packages to view these packages, along with their respective versions.
Security
Customer security is paramount to Buildkite, where our source code, build artifacts and deployment processes represent some of our most valuable and sensitive assets.
The shift from a self-hosted to a Buildkite hosted architecture for Buildkite Agents, introduces the potential for new attack vectors and shared responsibility models, and hence, additional security considerations.
The security model for Buildkite hosted agents has the following characteristics to address these security considerations and to mitigate attack risks.
Infrastructure and isolation security: Buildkite employs a multi-tenant architecture, where each job runs in a completely isolated virtualized environment. Once a job is complete, regardless of its exit status, the virtualized environment is destroyed, along with all its data (except for cache volumes that persist across jobs). This ephemeral approach ensures that customer workloads remain isolated from each other, even though the underlying hardware is shared across multiple customers.
Physical and operational security: The Buildkite hosted agent fleet operates from multiple Tier 3+ data centers with restricted physical access controls and regular security monitoring. The platform maintains SOC 2 compliance through regular audits of both hardware and software security controls.
Note that for macOS hosted agents, virtualization is achieved through Apple's Virtualization framework on Apple Silicon, providing lightweight but secure virtual machine isolation. Learn more about How Buildkite hosted agents work.
Git mirror cache
The Git mirror cache is a specialized type of cache volume designed to accelerate Git operations by caching the Git repository between builds. This is useful for large repositories that are slow to clone.
These volumes are attached on a best-effort basis depending on their locality, expiration and current usage, and therefore, should not be relied upon as durable data storage. By default, a Git mirror cache is created for each repository.
Enabling Git mirror cache
To enable Git mirror cache for your hosted agents:
- Select Agents in the global navigation to access the Clusters page.
- Select the cluster in which to enable the Git mirror cache feature.
- Select Cache Storage, then select the Settings tab.
- Select Enable Git mirror, then select Save cache settings to enable Git mirrors for the selected hosted cluster.
Once enabled, the Git mirror cache will be used for all hosted jobs using Git repositories in that cluster. A separate cache volume will be created for each repository.
Deleting Git mirror cache
Deleting a cache volume may affect the build time for the associated pipelines until the new cache is established.
To delete a git mirror cache:
- Select Agents in the global navigation to access the Clusters page.
- Select the cluster whose Git mirror cache is to be deleted.
- Select Cache Storage, then select the Volumes tab to view a list of all exiting cache volumes.
- Select Delete for the Git mirror cache volume you wish to remove.
- Confirm the deletion by selecting Delete Cache Volume.