Does self-hosting Bitbucket Pipelines cost less?
Self-hosting Bitbucket Pipelines saves money only when the spend it replaces is larger than the cost of running build capacity yourself. Metered build minutes and runner slot fees follow your volume, while self-hosting turns much of that into fixed costs for build servers, patching, upgrades and on-call time. The answer depends on two measurable numbers and your internal skills. Pull the monthly build minutes your pipelines consume and the peak count of builds running at the same time from Bitbucket billing and pipeline history before any renewal. Then compare those figures with the people available to operate a CI controller and its agents. A team with steady, high volume and platform engineers is in a different position from a small team that builds occasionally.
The change that prompts most reviews is the runner fee. Atlassian's v5 self-hosted runner announcement sets premium runners at $15 per month per concurrent build slot, so a team that needs five parallel builds at peak pays for five slots even when they sit idle. Confirm with Atlassian how your plan's included minutes apply to self-hosted runners and which runner versions are still scheduled before you model anything. Your own costs replace that line with compute, storage and network for agents, plus the time to keep them patched. Build history also has to leave the platform first. Bitbucket Pipelines keeps artifacts for at most 14 days, so anything you need for audit or rollback must be exported during the migration window, and that export is engineering time you should budget for.
Woodpecker CI is licensed under Apache-2.0 and Jenkins under the MIT License, so neither carries a license fee, and the recurring cost moves to infrastructure and people. Ask any implementation partner for a written scope that lists the servers or controllers, agent pools, database, backup storage, and who patches and upgrades each of them and on what schedule. Jenkins LTS releases follow a fixed cadence and plugins need attention, which is staff time that a Bitbucket subscription does not show. GitLab Runner is a separate option that only makes sense if you also move repositories and CI off Atlassian, because GitLab's paid tiers add their own per-user cost. DeployOpen does not publish prices, so the useful comparison is your own minutes and slot data set against a quote built from a written scope.
Which cost components change when you self-host CI
This table compares each cost component of Bitbucket Pipelines with the same component under self-hosted Woodpecker CI or Jenkins, and marks whether it is one-time or recurring. Read it as a checklist of who gets paid for what, then fill in your own figures from your Atlassian invoice and your infrastructure quotes. The main takeaway is that licence fees for Woodpecker and Jenkins are zero, so the decision turns on build infrastructure, staff time and upgrades.
| Cost component | Bitbucket Pipelines (Atlassian cloud) | Woodpecker CI or Jenkins (self-hosted) |
|---|---|---|
| Subscription or license | Bitbucket per-user plan fees, billed to Atlassian. Recurring. | Woodpecker is Apache-2.0 and Jenkins is MIT, so no license fee. Recurring cost is only support, if you buy it. |
| Build minutes | Included minutes per plan, then extra minutes billed. Recurring and usage-driven. | None per minute. Compute you run is a recurring infrastructure cost that you size yourself. |
| Runner slot fees | Premium self-hosted runners from runner version 5 are charged per concurrent build slot. Confirm the current rate with Atlassian. | No vendor slot fee. You pay only for the agents and machines you operate. Recurring. |
| Build infrastructure | Atlassian runs the build machines. You pay nothing extra unless you use self-hosted runners. | Agents or Kubernetes capacity, plus a controller or server. Mostly recurring, with one-time setup. |
| Storage for artifacts and logs | Artifacts expire after at most 14 days, so long retention means exporting elsewhere. Recurring if you archive. | You control retention. Storage for logs, artifacts and backups is a recurring cost you size. |
| Implementation | Largely absent, since the pipeline already runs in Bitbucket. One-time. | Installing the server, configuring forge webhooks, and rewriting bitbucket-pipelines.yml as Woodpecker YAML or a Jenkinsfile. One-time. |
| Migration of pipelines and secrets | Secured variables can only be replaced or deleted, so values must be re-entered in the new system. One-time. | Re-create every secret in the new store, rotate credentials, and validate each pipeline. One-time, scaled by pipeline count. |
| Support | Included in the Bitbucket plan at the tier you buy. Recurring. | Community support is free. Paid support or a retainer is a recurring quote to request in writing. |
| Upgrades and patching | Atlassian maintains the service. Your cost is limited to runner upgrades. | Your staff or provider patches the OS, Jenkins LTS or Woodpecker releases, and plugins. Recurring. |
| Backup and disaster recovery | Atlassian-managed. Limited to exporting your own pipeline definitions and history. | You back up the Jenkins home directory or Woodpecker database, and test restores. Recurring. |
| Internal skills | Pipeline YAML and Bitbucket administration. Low, recurring training. | Jenkins plugins, Kubernetes or Docker runners and server operations. Recurring staff time that is hard to outsource cheaply. |
What moves the cost of each option
Each card names one input that changes the bill for Bitbucket Pipelines and for a self-hosted build system. Together they show which costs are fixed by your infrastructure and which scale with how your teams build and retain data.
Concurrent build demand
Peak concurrency sets how many build slots or agents you need, which is the main driver of both sides of the comparison. Bitbucket charges $15 per month per concurrent build slot for premium self-hosted runners from runner version 5, so every extra parallel job adds a recurring line item. On Jenkins, the scaling guide recommends dedicated build agents so the controller only handles HTTP requests, and each agent is compute you size and pay for. For Woodpecker, the Kubernetes backend runs each step in a standalone pod, so peak demand becomes cluster capacity. Measure peak parallel jobs over a month, not the average.
Build minutes per month
Hosted Bitbucket Pipelines bills by build minutes, so long pipelines and frequent pushes raise the monthly bill directly. Self-hosting shifts that cost to the machines that run the minutes, so the question becomes how many compute hours you already own and how many you would need to add. Ask Atlassian for your current included minutes and overage rate in writing, and compare them with your measured monthly runtime per repository. Shorter pipelines through caching and parallel steps reduce both models.
Artifact and log retention
Bitbucket Pipelines keeps artifacts for at most 14 days, so a team that needs longer history must export it before a migration and keep it afterward. On a self-hosted system, retention is a storage decision: artifact and log volume grows with build count, and the cost sits in object or block storage plus the backup job that protects it. Woodpecker and Jenkins both keep state on the server side, so set retention rules and storage budgets before cutover. Confirm the retention policy your auditors expect.
Repositories and teams
The number of repositories, projects and teams decides whether one shared CI server is enough or whether you need several. Jenkins scales horizontally by adding controllers for new teams or projects, which adds controller hosting, upgrades and plugin management for each one. Woodpecker connects to Bitbucket and Bitbucket Datacenter, so you can keep repositories where they are and run one server for many teams, though the docs describe multi-forge setups as experimental. Count teams that need separate permissions, because that count sets the administration load.
Availability and failover design
A single build controller is a single point of failure, and the cost of resilience grows quickly. The Jenkins scaling guide describes a primary and backup controller arrangement where a proxy such as HAProxy or F5 routes traffic to the backup if the primary fails, which means a second controller, a proxy and a tested failover procedure. Hosted Bitbucket Pipelines carries that availability risk on Atlassian's side. Ask what downtime your delivery pipelines can tolerate, and price the standby infrastructure against that answer.
Kubernetes and Jenkins skills
The largest recurring cost is often the engineer time needed to run the platform, not the servers. Woodpecker on Kubernetes needs cluster operators who understand pods, persistent volume claims and ReadWriteMany storage, which the Woodpecker Kubernetes backend creates by default for each pipeline. Jenkins needs people who manage controllers, agents, plugins and the $JENKINS_HOME backup. Check which of these skills already exist in your team, and ask any implementation partner to quote the training and handover work as a separate line in a fixed-scope written proposal.
How to build the comparison with your own numbers
This sequence turns the Bitbucket Pipelines bill and your build fleet into a like-for-like model, so each cost line in the comparison comes from your own records and not from assumptions. The output is a side-by-side total over a horizon you choose, with migration and implementation shown as separate quoted lines.
Export current build minutes from Bitbucket
Pull the build minute usage for each workspace and repository from your Bitbucket billing and usage pages for the last several billing cycles, and record the included minutes, extra minutes and the months with the highest totals. Your finance or platform lead should confirm the figures against the invoices, since the usage view and the invoice can differ. This step is done when you have a monthly table of minutes by repository that reconciles to the amount you actually paid.
Measure peak concurrent builds
Using the pipeline history in Bitbucket and any runner logs you keep, find the largest number of builds that ran at the same time in each month, and note the hours when that peak occurs, such as release days or the start of the working day. Ask the team that owns each repository whether scheduled or nightly pipelines add to the peak. This step is done when you have one peak figure per month that you can explain to someone outside the team.
Count runner slots and the v5 slot fee
List every self-hosted runner, its version and the number of concurrent build slots each one offers, then confirm with Atlassian's runner announcement and your current Atlassian price list how the $15 per month per concurrent slot charge applies to premium v5 runners in your plan. Note which runners are on older versions, because the announcement says those no longer receive scheduled work. This step is done when you have a slot count and a monthly fee line that matches the figure Atlassian will bill.
List artifact and retention needs per pipeline
For each pipeline, record which steps produce artifacts, how large they are, and how long your release, audit or customer support process needs them to be kept. Compare those retention needs with the limit Bitbucket applies to artifacts, which Atlassian documents as at most 14 days. Your compliance or release owner should confirm which artifacts must be retained longer and where they will be stored after the move. This step is done when each pipeline has a retention requirement and a storage estimate for the self-hosted option.
Size agents and the controller for peak load
Translate the peak concurrency from step two into a count of build agents, each with the CPU, memory and disk that your heaviest pipelines need, and add a controller or server sized for the number of repositories and users. For Woodpecker CI, note whether you will use Docker, Kubernetes or autoscaled cloud VMs for agents, and for Jenkins, whether you will use dedicated build agents as the scaling guidance recommends. Ask your infrastructure team to price these machines in your own cloud account or data center. This step is done when you have a hardware or instance list that covers the peak with headroom you have agreed.
Estimate staff hours for upgrades and LTS cycles
Record the hours your team spends each month on platform work today, and estimate the same work for the self-hosted option: applying security fixes, upgrading the controller or server, moving to new Jenkins LTS baselines or Woodpecker releases, updating plugins or images, and checking backups. Base the cadence on the upgrade and release schedules in each project's documentation, and have the engineers who do the work give the hours, since they are the only reliable source. This step is done when you have a monthly hours figure for each activity and a named owner for each one.
Quote migration and implementation as separate lines
Keep one-time migration work out of the monthly total. List the translation of pipeline files, the moving of secured variables that must be re-entered because they cannot be exported, the build history exported before the cutover, and the hardening and documentation of the new platform. Request a written, fixed-scope quote from each implementation partner, including what is excluded, and ask how long the work will take and what it depends on. This step is done when each one-time item has its own quote line and is not mixed with recurring costs.
Compare totals over a stated horizon
Choose a horizon in years that matches your budget cycle, then add up the recurring Bitbucket and runner costs, the recurring infrastructure and staff costs for the self-hosted option, and the one-time quotes spread across that horizon. Run the model with your current peak and with a higher peak to see which assumption moves the result most, and show the result to finance with each assumption written down. This step is done when the comparison shows both totals, the assumptions behind them and the figures that would change the decision.
How the v5 runner slot fee changes the math
Atlassian's premium self-hosted runners for Bitbucket Pipelines carry a fee of $15 per month per concurrent build slot from runner version 5, according to the Atlassian announcement. The unit being charged is concurrency, not repository count or seat count. A team with fifty repositories and two parallel build slots pays for two slots, while a team with five repositories that runs eight builds at once pays for eight. Before comparing options, the reader should pull the peak number of simultaneous pipelines from the last quarter of Bitbucket activity and multiply it by the slot price, then confirm the current rate on Atlassian's pricing pages because that figure can change.
Running Woodpecker CI agents or Jenkins agents on machines you already operate removes that per-slot line item. Woodpecker and Jenkins are both open-source with no license fee: Woodpecker is licensed under Apache-2.0 and Jenkins under the MIT License. What remains is the cost of the agent hosts, storage, the controller or server, and the people who operate them. Those costs are largely fixed and can be sized to peak demand, and the reader should compare that compute cost with the metered slot count at the same peak. The Woodpecker autoscaler or Jenkins agents on cloud capacity can also turn parallel demand into short-lived compute instead of permanent capacity, which changes the arithmetic at high concurrency. Ask the infrastructure team what an agent host costs per month in your own cloud or data center, not in a vendor example.
The per-slot fee is one instance of a wider pattern. GitHub announced a $0.002 per minute charge for self-hosted GitHub Actions runners before postponing it, according to GitHub's pricing announcement, so vendors across the CI market are metering the machines customers already own. Treat the postponement as a delay, not a removal, and write the metering risk into the renewal review: if the fee model changes after a migration starts, the team should already know which of its builds depend on the vendor's runner. Woodpecker CI and Jenkins remove that dependency on any vendor's metering, although they still carry staff time and upgrade effort, which the adjacent cost components in this page cover.
Questions buyers ask about CI cost and effort
Is self-hosting Woodpecker CI or Jenkins cheaper than Bitbucket Pipelines?
It depends on your build volume, your runner setup and the staff time you already have, so no general answer holds. Bitbucket Pipelines costs come from per-user Bitbucket fees, build minutes beyond the included allowance, and, for premium self-hosted runners, a charge of $15 per month per concurrent build slot from runner version 5, according to Atlassian's announcement. Self-hosting replaces the minute and slot charges with build servers or cloud VMs, storage, backups, upgrades and engineer time. Woodpecker CI and Jenkins are open-source with no license fee, so the comparison comes down to infrastructure and people. Ask your team to model both sides with your real monthly build hours and concurrency before deciding.
How long does a migration from Bitbucket Pipelines take?
The timeline depends mainly on the number of pipelines, how many steps, caches and deployment environments each one uses, and how many secured variables must be re-entered. Secured variables cannot be read back from Bitbucket, so each one must be replaced from its original source, which often takes the most coordination. Artifacts are kept for at most 14 days, so build history you need should be exported first. Because most engagements are fixed-scope, DeployOpen agrees the timeline in writing after reviewing your pipeline inventory. Ask for that written schedule rather than relying on a general estimate.
What does our team have to do itself after a migration?
Your team keeps ownership of the runners, the CI server, the database, backups, access control and the decisions about which projects run where. Someone must also review pipeline changes, rotate deployment credentials, and monitor queue health and agent capacity. Repositories stay where they are, so developers keep their existing review workflow. If you want outside help after go-live, ongoing support, upgrades and continuous testing are available as retainers. Confirm in writing which of these tasks sit with your staff and which sit with the implementation partner.
Does Woodpecker CI or Jenkins need more specialized skill?
Woodpecker CI is simpler to start with because its workflows are YAML files that run each step in a container image, and it works with Docker or Kubernetes backends. Jenkins asks more of the team: Jenkinsfile pipelines in Declarative or Scripted syntax, controller and agent design, and a plugin ecosystem with more than 2,300 plugins that must be chosen, secured and kept current. Teams already fluent in Groovy, plugins and Kubernetes will find Jenkins familiar. Teams comfortable with container-based YAML may find Woodpecker faster to operate. Test both on one representative pipeline before choosing.
How often do Jenkins and Woodpecker CI need upgrades?
Both recur, and the cadence is the main ongoing cost after go-live. Jenkins picks a new LTS baseline about every 12 weeks from a recent weekly release, then ships three LTS releases for that baseline in four-week cycles that contain only backported fixes, according to the Jenkins LTS release line documentation. Plugin updates and Java support changes add work on top of that. Woodpecker publishes tagged releases on GitHub, with 3.19.0 released on October 7, 2026, so you should plan regular reviews of each release. In both cases, budget staff time for testing and rollout on a schedule your change process can absorb.
Do our repositories have to move off Bitbucket?
No. Woodpecker CI supports Bitbucket and Bitbucket Datacenter as forges, with push, tag and pull request events, so builds can move to your own servers while repositories stay in Bitbucket. Jenkins can also be connected to Bitbucket through its plugins, though the integration set-up should be confirmed for your Bitbucket edition. Moving repositories is a separate decision with its own cost and access-control impact. Ask your implementation partner to confirm the exact Bitbucket edition and webhook setup in your environment before scoping.
What should we request in a written quote for a CI migration?
Ask for a scope that lists the pipelines in and out of scope, the target platform and version, the hosting model and the environments covered. The quote should name the deliverables, such as translated pipeline files, runner configuration, backup setup, documentation and handover sessions, along with the timeline and acceptance criteria. Request a clear split of one-time work from recurring items such as upgrades and support retainers. Also ask who handles secret re-entry, artifact export, and rollback, and what your team must provide in staff time. A fixed-scope written agreement makes these points comparable across vendors.
Which hidden costs should we check before choosing self-hosted CI?
Common hidden costs include build servers sized for peak concurrency, storage for logs and artifacts you must now keep, backup and restore testing, and monitoring for the CI server and agents. Security work also recurs, such as patching, access reviews and rotating deployment secrets, because hosted CI platforms hold deployment secrets for every connected project. Staff time for on-call coverage and upgrades is often the largest item. Ask for each of these to be listed as a separate line, with who pays for it and whether it is one-time or recurring.
When Woodpecker CI, Jenkins or GitLab Runner fits the budget
Woodpecker CI fits best when the repositories stay in Bitbucket and the goal is to stop paying per build minute and per concurrent runner slot while keeping operations light. Woodpecker connects to Bitbucket and Bitbucket Datacenter as forges, so the cost to plan for is mostly the servers that run the Woodpecker server and agents, the database, and the time spent maintaining them. Confirm in the Woodpecker forge documentation that your Bitbucket edition and the events you need (push, tag, pull request) are covered, and note that multi-forge setups are still described as experimental, which matters only if you plan to connect more than one forge to one server.
Jenkins fits teams that need a large plugin catalog and accept the upkeep that comes with it. The Jenkins homepage cites more than 2,300 community plugins, but every plugin you rely on becomes a recurring maintenance item. The controller, the agents, the plugin versions and the $JENKINS_HOME backups are staff time that recurs every LTS cycle. The 2.580.1 LTS changelog shows that some formerly bundled plugins, such as the SSH server and JUnit plugins, must now be installed through the plugin manager, so budget for that review at each upgrade. Ask whether your Java runtime is on the supported list in the Jenkins support policy before you size the platform team.
GitLab Runner only makes economic sense when the repositories also move to GitLab. Its price comparison point is the GitLab Premium tier at 29 US dollars per user per month billed annually, according to the GitLab pricing page, multiplied by every user who needs access, plus the self-managed infrastructure and administration effort. Ask GitLab for a quote that lists each user type and whether Ultimate features are needed, because that tier is custom priced. Confirm in the GitLab maintenance policy how often you must upgrade, since required upgrade stops apply, and whether your hosting approach fits the reference architecture you choose.
How DeployOpen scopes a fixed-price CI implementation
DeployOpen plans and implements self-hosted CI on Woodpecker CI or Jenkins inside your own infrastructure, starting from a written scope that sets out which pipelines, forges and deployment targets are covered. Engagements are fixed-scope, so the scope, deliverables and timelines are agreed in writing before work starts.
How we scope
- Inventory every Bitbucket Pipelines file, pipe, deployment environment and runner in use across the repositories in scope.
- Record which build artifacts and variables must be exported or recreated, since secured variables cannot be read back once set.
- Agree in writing whether Woodpecker CI or Jenkins fits the forge, team skills and runner hosting, with a quote following from that scope.
How we build
- Translate bitbucket-pipelines.yml steps into Woodpecker workflows or Jenkinsfile stages, and test each pipeline against real branch and pull request events.
- Size and configure build agents, runner labels and secrets storage in your own cloud accounts, data centers or air-gapped networks.
- Integrate Bitbucket or other forge webhooks, build status reporting and access controls, then test the pipelines before cutover.
How we hand over
- Document the pipeline inventory, agent setup, backup scope for the CI controller or server, and the steps for rotating each migrated secret.
- Deliver runbooks for upgrades, plugin or image changes and recovery, so your staff can operate the CI platform after handover.
- Provide the evidence and configuration records your auditors or internal reviewers may request, without issuing any audit report or certification.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer, scoped separately from the implementation.
- Ask for the retainer terms in writing, including who applies Woodpecker or Jenkins upgrades and how security patches are handled.
- Confirm with DeployOpen which support hours, response paths and testing cadence apply before signing a fixed-scope agreement.
