Atlassian’s Bitbucket team has rolled out a major update to Bitbucket Pipelines self-hosted runners with the release of version 5.0. This update delivers a suite of powerful new capabilities that give teams greater control over their continuous integration/continuous delivery (CI/CD) pipelines. From fine-tuning runner resources to persisting data between build steps, Bitbucket Pipelines runners are becoming more flexible than ever. In addition, Atlassian is introducing a new paid licensing model for these self-hosted runners, designed to support continued innovation and meet the needs of enterprise teams. Existing runner installations prior to v5.0 will remain free to use until June 3, 2026, providing a generous transition period for organizations to adapt.
In this blog, we’ll break down the key enhancements in Bitbucket Pipelines self-hosted runners v5.0 and explain what the new pricing model means for your team. These changes are geared towards faster build times, more efficient resource usage, and stronger data control, all critical for teams with compliance and performance demands. Read on for a clear overview of what’s new, tips on preparing for the transition, and how Atlas Bench can help you make the most of these updates.
Docker Volume Mounts for Faster Builds: Teams can now attach persistent storage volumes to pipeline steps, enabling data to be shared between build steps and even between separate pipeline runs. Instead of re-downloading dependencies or rebuilding assets in every step, you can cache outputs from one step and reuse them in subsequent steps. For example, a project’s dependencies can be downloaded once and stored on a mounted volume; later steps can access those files directly, eliminating redundant work. This enhancement significantly reduces build times and network usage, making pipelines more efficient.
Custom CPU and Memory Allocation: Bitbucket Pipelines now allows you to fine-tune the CPU and memory assigned to each self-hosted runner step via simple YAML settings. Previously, runner machines had fixed resource profiles, but with v5.0 you can choose from preset sizes or even specify custom resource amounts. This means you can allocate just the right amount of horsepower for each pipeline step giving intensive build steps more CPU or memory, while not over-provisioning for lighter tasks. Optimizing resource allocation in this way helps avoid bottlenecks and can potentially lower infrastructure costs, since you’ll use resources more effectively.
Control Over Build Artifact Storage: A major focus in v5.0 is data sovereignty and compliance. The new runners let you define where build artifacts and caches are stored by connecting your pipeline to your own cloud storage. You can easily configure an Amazon S3 bucket or a Google Cloud Storage bucket in your organization’s account to store pipeline caches and artifacts. In practice, this gives you full control over where your build data lives, keeping it within your private cloud environment for security or regulatory compliance. Teams in finance, healthcare, and other regulated industries will appreciate the ability to retain artifacts on infrastructure they manage. No more wondering if sensitive build outputs are floating around in an external cloud; you decide the storage location and retention policies.
Ephemeral macOS Runners (Upcoming): Although not part of the v5.0 release itself, Atlassian has announced that support for ephemeral macOS runners is on the horizon. Using an industry-leading macOS virtualization technology called Tart, Bitbucket Pipelines will be able to spin up disposable macOS virtual machines on a single host machine. This is big news for iOS and macOS developers: it means you won’t need a dedicated Mac for every runner agent. A single Mac host could run multiple isolated VM agents as needed, then tear them down after each job. This forthcoming capability will dramatically improve scalability and cost-efficiency for teams building iOS/macOS applications by enabling true on-demand macOS build agents.
One of the biggest shifts accompanying the v5.0 release is the move to a paid licensing model for Bitbucket self-hosted runners. Atlassian is transitioning from offering unlimited self-hosted runner usage for free to a slot-based subscription model. This new model is designed to be flexible and predictable, while allowing Atlassian to invest more into the self-hosted runner offering. Under the new pricing structure, self-hosted runners will be licensed per concurrent build slot. In essence, a “build slot” corresponds to one parallel pipeline execution on a self-hosted runner. Your Bitbucket workspace can be configured for a certain number of maximum concurrent self-hosted builds, and you will be charged based on that number. Each concurrent runner slot is priced at $15 per month. For example, if you need to run up to 3 builds at the same time on your own runners, you would license 3 slots for a total of $45/month. This pricing approach offers a clear value proposition compared to many alternative CI/CD solutions. Many organizations running on legacy tools will likely find that the costs of operating equivalent build agents are lower with Bitbucket Pipelines’ new model, especially when factoring in the maintenance and infrastructure savings of a cloud-managed service. Atlassian is effectively providing the coordination service and new features for a modest per-runner fee, while you bring your own hardware or cloud machines for the runners.
Plan inclusions: Bitbucket’s existing account plans come with some free runner capacity built in. Workspaces on the Standard plan will receive one self-hosted runner slot for free, and Premium plan workspaces will get two free slots included. This means if you only need a small degree of parallelism, you might not see any additional cost at all. If you require more concurrent builds, you can add as many slots as needed on top of those free allowances.
Configuring concurrency: Managing the number of runner slots is straightforward. Administrators can set the maximum number of concurrent self-hosted builds in the workspace settings. This acts as a cap; Bitbucket will not run more than that many self-hosted jobs in parallel. If your team triggers more builds than the available slots, the additional jobs will simply queue until a slot becomes free. This ensures you won’t be charged for capacity above what you’ve planned, your costs are predictable, based on the slot limit you configure.
Billing details: Billing for runner slots will be integrated into your Bitbucket Cloud subscription. You will be billed for the peak number of concurrent runner slots you configured in a given month. For instance, if you temporarily increase your limit to handle a surge and later reduce it, your bill for that month will reflect the highest configuration. Slots are treated as an add-on in your subscription, and charges will begin on your next billing cycle after upgrading to v5.0 and enabling paid runners. Atlassian has provided a long lead time before enforcement to ensure customers can plan budgets and adjustments accordingly.
Moving to a paid model is a significant change, and Atlassian is offering a lengthy transition period to help customers smoothly adjust. Here are the key timelines and details regarding the changeover from older runner versions to the new v5.0 system:
Transition Period: You can continue using your existing self-hosted runners on versions prior to 5.0 at no charge for quite some time. For monthly billing customers, the cutoff date is June 3, 2026. For annual subscription customers, you have until December 3, 2026 to use older runners without incurring runner slot charges. This means for the next 6 to 12 months, you can operate as usual on older runner versions. After those dates, Atlassian will disable the ability to schedule pipeline steps on runners older than v5.0. Essentially, older runners will stop working for new builds once the grace period expires.
Side-by-Side Migration: During the transition period, you are free to run v5.0 self-hosted runners alongside your existing older-version runners. Bitbucket Pipelines will intelligently distribute jobs to all available runners in your workspace’s runner pool. There’s no manual load balancing required on your part, the system knows which runners are online and will use them. This allows teams to gradually introduce v5.0 runners without immediately turning off all old runners. You could, for example, upgrade a few agents to v5.0 to test the new volume mounts or resource controls, while still keeping other pipelines on v3 until you’re comfortable switching them over. Pipelines will seamlessly queue and send builds to either type of runner as they are available, so your CI/CD continues uninterrupted during the migration.
Old Runners Don’t Count Toward Slots: Importantly, the new concurrent build slot limits apply only to runners on version 5.0 and above. Any builds executed on older runner versions during the transition period will not consume or count against your paid concurrent slot allowance. In other words, until you upgrade a runner to v5.0, you won’t need a paid license for it. This is great for teams who want to take their time migrating, you can keep using your existing runners free of charge until the deadline. Once you upgrade a runner to v5.0, then any jobs it runs will require an available slot. Keep this in mind when planning your capacity: you might choose to gradually increase your licensed slot count as you upgrade more agents to the new version.
Improved Runner Management UI: To support these changes, the Bitbucket Cloud interface for managing runners has been enhanced. The runner management screen now clearly shows the version of each registered runner, so you can easily distinguish which agents are v5.0 vs. older versions. Additionally, when creating a new runner registration, you have the option to select which runner version to install. This makes it easier to control your upgrade process while keeping others on the stable older version. The UI updates help avoid confusion by labeling everything, ensuring you know exactly which runners are using the new model.
With the new features and pricing model on the way, it’s important to prepare your team and environment ahead of the 2026 deadline. Here are two key steps to take in the coming months to ensure a smooth transition:
1. Configure Your Concurrency Limit: Start by evaluating how many parallel builds your team typically needs to run, and set an appropriate concurrent runner slot limit in your Bitbucket workspace settings. This configured number will determine the level of service and cost under the new model. Take stock of your current CI/CD usage, if you seldom run more than one or two pipelines at the same time, the default free slots in Standard or Premium might suffice initially. If you have higher parallelism needs, plan out the number of slots that will accommodate that workload. Setting this up early will give you clarity on budgeting and ensure there are no surprises when the licensing kicks in. Because the billing is based on the maximum configured slots per month, you might also consider phasing increases gradually: you can start with a lower limit and raise it as needed when your migration progresses or your team grows.
2. Upgrade Your Runners to v5.0: Begin scheduling time to upgrade your self-hosted runner instances to the new 5.0 version well before the cutoff date. Upgrading will allow you to leverage all the new capabilities like volume caching and custom resource allocation right away, which can benefit your pipeline speed and efficiency. It’s wise to introduce the updates incrementally, perhaps update one runner and run a subset of your pipeline through it to verify everything works as expected with your builds and configurations. Atlassian has made backward compatibility a priority; your pipelines YAML should work as before, unless you choose to add the new settings. By moving to v5.0 early, you also ensure that your team is fully ready when the free period for older runners ends. No one wants to be scrambling in June 2026 to upgrade critical infrastructure at the last minute. Early adoption also gives you time to adjust any internal documentation or automation scripts for the new runner version. If you have questions about the upgrade process or best practices for migrating, don’t hesitate to reach out for guidance, planning ahead will save a lot of stress later.
By taking these steps, organizations can maximize the benefits of Bitbucket Pipelines v5.0 while minimizing disruption. The combination of faster builds, greater control over data, and a clear licensing structure represents a positive evolution for Bitbucket Cloud’s CI/CD capabilities. Atlas Bench is here to help ensure you get the most out of these new features and transition confidently.