Which fits your Bitbucket Data Center team: Bamboo or Woodpecker CI?
Choose Bamboo if your existing plans, Bamboo Specs and deployment projects would be costly to rewrite and your organization wants Atlassian to support the CI server. Choose Woodpecker CI if your pipelines can be expressed as container steps, you want to stop paying per agent, and you have people who can run and patch a server. Both options work with Bitbucket Data Center as the Git server, because Woodpecker connects to Bitbucket Datacenter as a forge. The decision turns on three things: how complex your plans are, how much of your delivery depends on deployment projects, and who on your team will own a Woodpecker installation after go-live.
Bamboo fits teams with many plans, long-standing Bamboo Specs files, and Jira issue links and Bitbucket integrations that already work. Its per-agent annual subscriptions are the main recurring cost, so renewal is the moment to count agents against the work they actually do. Atlassian announced on September 8, 2025 that it is sunsetting its Data Center products, with sales to new customers ending March 30, 2026 and end of life on March 28, 2029. Its journey-to-cloud page states that Bitbucket and Bamboo Data Center will continue beyond 2029 under a Bitbucket Hybrid License. These notices conflict, so ask Atlassian in writing which terms apply to your contract and what the Hybrid License would cost for your agent count before you commit to either path.
Woodpecker fits teams whose builds can run as containers, with each workflow step defined by a container image and configured in YAML files stored in the repository. Woodpecker is licensed under Apache-2.0, so the server itself carries no per-agent subscription. Bamboo deployment projects have no one-to-one equivalent, so list every environment, approval and release step and decide how each will be modeled before you start. Plan for the operational side too: a Woodpecker installation has a server, agents and a database, and SQLite is the default with PostgreSQL recommended for larger instances. Before choosing Woodpecker, confirm that a named engineer can own upgrades, backups and agent capacity. If you cannot name that owner, Bamboo or a supported distribution may be the lower-risk choice.
Which option fits which scenario
This table maps common Bamboo situations to the platform that usually fits better, along with the condition that makes each choice true. Read each row against your own plan count, deployment setup, license position and vendor support needs, since several rows depend on facts only your environment can confirm.
| Scenario | Better fit | Condition that makes it true |
|---|---|---|
| Staying on Bamboo through the renewal window | Bamboo Data Center | Your contracts, compliance rules or Atlassian support terms require Bamboo until a planned migration date, and you have confirmed the current end-of-life terms with Atlassian |
| Many Bamboo deployment projects with environment promotion | Bamboo Data Center for now, or a plan to rebuild promotions in another tool | Your release process depends on Bamboo deployment projects and environments that have no direct Woodpecker equivalent, so promotion logic must be redesigned first |
| Mostly build-and-test plans that already run in containers | Woodpecker CI | Your steps run in Docker images, your repositories sit on Bitbucket Data Center or another supported forge, and your plans need little beyond build, test and artifact steps |
| A requirement for Apache-2.0 licensed CI software | Woodpecker CI | Your policy accepts Apache-2.0 open-source licensing for the CI engine and you have checked any plugins you depend on for their own licenses |
| A requirement for Atlassian vendor support | Bamboo Data Center | Your organization needs a vendor contract and support path from Atlassian, which Woodpecker, as community software, does not provide |
| Avoiding per-agent subscription fees | Woodpecker CI | Your budget owners want build capacity that does not scale with a per-agent license, and you have costed the Woodpecker servers, agents and the staff time to run them |
| Plans that depend on Bamboo-specific task types or Jira integration | Bamboo Data Center or a rebuild | Your builds call Bamboo tasks or Jira features with no container equivalent, so each one needs a replacement step or a plugin checked before you commit |
Where builds, secrets and artifacts live under each option
Moving from Bamboo Data Center to Woodpecker CI changes where build logs, secrets and artifacts sit and who controls how long they stay. Each card covers one part of that data picture, with the checks to run before you commit to a cut-over date.
Build data stays in your data center
Bamboo Data Center runs on servers you operate, and build logs, plan configuration and results are stored in its database. A Woodpecker installation keeps its server database (SQLite by default, with PostgreSQL or MariaDB recommended for larger instances) and its agents inside your own network. Confirm which agents can reach your Bitbucket Data Center instance, where the database backups go, and who can read the logs.
Secrets must be re-created
Bamboo stores encrypted variables and plan secrets inside its own data, and those values cannot be read back out in plain text through the interface. Woodpecker keeps its secrets on the server and you enter them again during migration. Plan a secret inventory, rotate credentials that were shared with other teams, and record which pipelines use each secret.
Artifact retention is your policy
Bamboo keeps artifacts according to the retention rules configured on your server, and Woodpecker writes artifacts to the storage you wire into your pipelines. Neither platform sets a short vendor default for you, so the retention period is a decision you document. Define how long build outputs, test reports and images are kept, and where they are stored, before cut-over.
Pipeline files hold no vault
Woodpecker workflows are YAML files in your repository, while Bamboo plan definitions live in its server or in Bamboo Specs code. Because pipeline files are in Git, review and history follow your repository controls. Check that no credentials are hard-coded in the new .woodpecker.yaml or .woodpecker/ files, and that secrets are injected only into the steps that need them.
Identity and SSO integration to confirm
Bamboo accepts users through Atlassian accounts and directory integrations configured on the server. Woodpecker authenticates users through the forge it connects to, and its administrator settings control who can log in and manage repositories. Confirm with your identity team how Bitbucket Data Center group membership maps to Woodpecker roles, and whether your SSO provider can be used for administrative access.
Compliance evidence you produce
Access logs, change records, secret rotation history and backup restore tests are evidence you must generate and keep, whichever CI product runs your builds. DeployOpen prepares systems, controls and evidence for assessments, but it does not issue audit reports or certifications, and independent auditors make that determination. Ask your auditor which Woodpecker and Bamboo records they will accept before you retire the old server.
How Woodpecker CI replaces Bamboo agents and plans
The first decision is architectural. A Woodpecker installation has a server that provides the UI and API, receives forge webhooks and parses pipeline YAML, and agents that run workflows and connect to the server over gRPC. Bamboo's remote agents pick up jobs from a central server in a similar way, but Woodpecker agents execute steps inside containers, so the build environment is defined by the workflow file rather than by what is installed on each agent. An optional autoscaler can create cloud VMs for pending builds, which replaces the fixed agent pool many Bamboo sites manage by hand. Before sizing anything, confirm which backend each agent will use (Docker, Kubernetes or the local machine) and where the server database will live, since Woodpecker defaults to SQLite and recommends PostgreSQL or MariaDB for larger instances.
Bamboo plans map to Woodpecker workflows, not one-to-one to Bamboo objects. A Bamboo plan's stages and jobs become one or more workflows, each defined in a .woodpecker.yaml file or in files under .woodpecker/, and the tasks inside each job become steps. Every step runs its commands inside a specified container image, so a Bamboo task that depended on a tool preinstalled on an agent needs an image that carries that tool. Use when filters on event, branch and path to recreate Bamboo's branch plans and triggers, and depends_on to keep the ordering that Bamboo stages implied. Parallel workflows in the .woodpecker/ directory run without that ordering unless you declare it, so check that every Bamboo stage dependency appears explicitly in the new files.
Bamboo deployment projects do not have a direct equivalent in Woodpecker and need a separate pattern. Teams usually add a deploy step that runs a tool such as kubectl or a Terraform or OpenTofu command, or hand deployment to a GitOps controller such as Argo CD, which reads the desired state from Git. Each choice changes who holds deployment credentials and where approval gates sit, so decide that before cut-over. Confirm the approach with the owners of your target environments, and test one release path end to end in a non-production environment, including rollback, before retiring the Bamboo deployment project.
What each option costs to own, by component
Bamboo and Woodpecker CI cost different things to own. Bamboo's largest line is recurring Data Center subscriptions, while Woodpecker shifts cost to infrastructure, staff time and the rewrite of existing plans. Quote requests should break each cost into these components so the two options can be compared on the same basis.
Bamboo agent-tier subscriptions
Bamboo Data Center is licensed per agent on an annual subscription, so the recurring cost grows with the number of build agents you run. Atlassian is paid by the license, and renewal usually comes around each year. Ask the Atlassian partner or reseller for the agent count your current plan covers, the tier at each renewal date, and whether any agents are added mid-term. Check the Bamboo pricing page for the current published structure before comparing.
Bitbucket Hybrid License renewal
Atlassian's journey-to-cloud page states that Bitbucket and Bamboo Data Center continue beyond the 2029 end of life under a Bitbucket Hybrid License. Treat this as a recurring line to model, since the terms of that license and its renewal cost are not part of this comparison. Ask Atlassian in writing for the Hybrid License terms, what they cover, and whether Bamboo is included in the same renewal as Bitbucket Data Center.
Woodpecker server and agent hosting
Woodpecker runs a server for the UI, API and webhooks, and agents that execute workflows over gRPC. Both are infrastructure you pay for: virtual machines or nodes, storage and backups, and the monitoring that keeps them up. The cost is recurring and grows with build volume and the number of agents. Ask your platform team to size the server and agent pool for your peak concurrent builds, and to state whether the optional autoscaler, which creates cloud VMs for pending builds, is part of the design.
Database for the Woodpecker server
Woodpecker uses SQLite by default, and the project recommends PostgreSQL or MariaDB for larger instances. A managed or self-run database adds a recurring infrastructure cost, plus backup and patching work that falls to your team. Decide early whether you will use a database your organization already operates. Confirm the sizing with your DBA and whether backups for CI history are required by your retention policy.
Kubernetes or Docker capacity
Woodpecker agents run workflows on Docker, Kubernetes or the local machine, and each Kubernetes step runs in its own pod with a temporary persistent volume claim for the pipeline. Capacity cost depends on how many steps run in parallel, how long they take and how much storage the shared claim consumes. Ask for a load estimate based on your current Bamboo build queue, and confirm which capacity you already pay for in your cloud or data center contract.
Plugin and workflow rewrite effort
Bamboo plans, tasks and deployment projects have to be rebuilt as Woodpecker workflow YAML, with each step running in a container image. Drone plugins generally work but may need adjustments, so each Bamboo task type needs a mapped container or a custom image. This is a one-time cost, and it rises with the number of plans, custom tasks and deployment environments. Ask for an inventory of Bamboo plans and task types first, then a per-plan effort line in the quote.
Staff time and support contracts
Your engineers pay the largest share of a migration in time: rewriting pipelines, rebuilding secrets, running Bamboo and Woodpecker in parallel and training developers. Support is a separate recurring line if you buy it from a vendor or partner, and it is priced by scope. Ask any provider to state which tasks are one-time, which are ongoing upgrades and on-call, and what response commitments are written into the agreement.
What moving from Bamboo to Woodpecker CI involves
The sequence moves builds to container-based Woodpecker workflows while Bitbucket Data Center stays as the Git server, and it keeps Bamboo running until each pipeline is proven. Each step ends with a check that tells you whether the next one can start.
Inventory Bamboo plans and deployment projects
Export your plans and deployment projects to YAML Specs as a starting inventory, then list every plan, its stages, jobs, tasks, triggers and linked deployment projects. Your team lead and the Bamboo administrator should own this list. It is done when every plan has an owner and a target repository, and each task type is marked as directly mappable, needs a plugin, or needs a custom container step.
Export build history and artifacts before retention ends
Bamboo's own history and artifacts are not carried over by the spec export, so decide which build logs, test reports and artifacts your audit or release process needs and export them to storage you control. The administrator performs this step and confirms that each export opens and is indexed. Confirm your Bamboo artifact retention settings with Atlassian before you assume any old data will remain available.
Identify encrypted secrets for manual re-entry
Bamboo encrypted variables cannot be read back out of the server, so list every secret that a plan or deployment project uses, including registry credentials, cloud keys and signing material. The security team assigns each secret to a new owner and a store in Woodpecker, such as repository or organization secrets or an external secrets manager. It is done when each secret has a named source of truth and a rotation plan.
Connect Woodpecker to Bitbucket Data Center
Install the Woodpecker server and agents in your own infrastructure, then register Bitbucket Datacenter as the forge so push, tag and pull request events trigger builds without moving repositories. The platform engineering team owns the connection and the agent hosts. It is done when a test repository sends webhook events to Woodpecker and a trivial pipeline runs on an agent. Confirm the current forge setup steps against the Woodpecker documentation for your version.
Translate plans into Woodpecker workflow files
Rewrite each Bamboo plan as one or more Woodpecker workflow files, choosing a container image for each step and mapping shared files to the pipeline workspace. Stages that run in parallel become separate workflows, and ordering uses depends_on. Developers review each translated file against the spec inventory from the first step. It is done when each workflow passes a review and produces the same test results and artifacts as the Bamboo plan.
Pilot on non-production repositories
Run the translated workflows on low-risk repositories and branches first, comparing test counts, build outputs and failure messages with Bamboo results for the same commits. Engineers record each difference and fix the workflow or plugin choice. The pilot is complete when the outputs match for an agreed set of builds and every open difference has an owner.
Run both servers in parallel
Keep Bamboo building production branches while Woodpecker runs the same builds in shadow mode, and compare results on every change. Deployment steps stay on Bamboo until the release process has been checked on Woodpecker. The release manager signs off when parallel runs show no unexplained differences over the agreed period.
Cut over and retire Bamboo agents
Switch triggers and deployment steps to Woodpecker, disable the Bamboo plans, then remove the Bamboo agents and confirm that no secrets, tokens or webhooks still point to the old server. Record the final state, including the retained export archive and the revoked credentials. It is done when Bamboo is no longer triggered for any repository and the decommission record is filed with the security team.
Questions buyers ask before choosing Woodpecker CI over Bamboo
What drives the cost of switching from Bamboo to Woodpecker CI?
The switch cost is mostly labor and infrastructure, not the license, because Woodpecker CI is licensed under Apache-2.0. The main drivers are the number of plans and deployment projects to rewrite, how many secrets must be re-entered by hand, the agent and server hosting you already pay for, and whether your Bitbucket Data Center instance needs changes to webhooks or permissions. Bamboo's cost is recurring and tied to per-agent subscriptions, so the comparison is one-time migration work against that ongoing renewal. Ask any implementation partner for a quote built from a written inventory of plans, agents, secrets and deployment steps, with each line item separated into migration, hosting, testing and support.
How long does a Bamboo to Woodpecker CI migration take?
The pace depends on the size and complexity of the Bamboo estate, not on the tool alone. Teams with a small number of plans that use standard build tasks will finish faster than teams with many plans, custom task types, shared variables and deployment projects tied to environments. Plan the work in phases: inventory plans and secrets, build the Woodpecker server and agents, translate pipelines into workflow files, then run both systems in parallel until builds match. Woodpecker documents the .woodpecker.yaml and .woodpecker/ directory formats, which give you a clear target for each plan. Ask for a fixed-scope timeline that names the plan count and the agent and forge work included.
Can our own team migrate from Bamboo to Woodpecker CI without outside help?
Yes, a capable platform team can migrate in-house, but the work needs someone who understands both the Bamboo plans and container-based pipelines. Woodpecker workflows are YAML files where every step runs inside a specified container image, so a Bamboo task that depended on an installed tool on an agent must be redone as an image, a plugin or a command. Woodpecker plugins are container images configured through a settings block, and the project notes that Drone plugins generally work but could need adjustments. Teams that lack this experience often bring in an implementation partner for a fixed scope, while keeping day-to-day ownership of the pipelines inside their own team.
What skills does the Woodpecker CI server need to run?
Running Woodpecker takes the same operational skills as any self-hosted service: container hosting, a database, TLS, backups and upgrades. A Woodpecker installation has a server that serves the UI and API, receives forge webhooks and parses pipeline YAML, and agents that connect to the server over gRPC and run workflows on Docker, Kubernetes or the local machine. An optional autoscaler can create cloud VMs for pending builds. Woodpecker uses SQLite by default, and the documentation recommends PostgreSQL or MariaDB for larger instances, so a team should plan a supported database from the start. Ask whether your team will also own the Kubernetes backend and the Helm chart if you choose that route.
Does Woodpecker CI still support Bitbucket Data Center as our Git server?
Yes. Woodpecker's forge documentation for version 3.19.x lists Bitbucket Datacenter among its supported forges, with push, tag and pull request events. That means your repositories can stay on Bitbucket Data Center while builds move to Woodpecker. Confirm the exact Bitbucket Data Center version and the authentication method you use with the current forge documentation before you configure the connection. The same documentation says that connecting multiple forges to one server is still experimental, so if you plan to serve several Git hosts from one Woodpecker server, treat that as a design risk to test before cut-over.
How are Bamboo deployment projects handled in Woodpecker CI?
Woodpecker is a CI engine, so it does not reproduce Bamboo deployment projects one for one. Build and test steps translate into workflow files, but the release and environment logic that Bamboo models as deployment projects needs its own design, usually as dedicated workflows triggered by tags or branches, or as separate deployment tooling. Document each deployment project's environments, approvals, rollback steps and credentials before you start. Then decide which deployment tool will own those steps, because Woodpecker will run them but will not replace a release model on its own. Ask any implementation partner to list each deployment project in the statement of work so nothing is dropped.
What happens to build history and secrets during the move?
Neither build history nor secrets move automatically, so plan both before the switch. Bamboo build results and logs stay in Bamboo unless you export them, and you should decide how long you must keep them for audit or troubleshooting. Secrets are the harder problem: CI platforms generally do not let you export secret values, so you must re-enter them into Woodpecker from their original sources and rotate any credential that was shared through Bamboo. Record which secrets are used by which plans, restrict access to the Woodpecker server, and confirm that each deployment credential has a named owner. Ask your provider how the secret inventory will be captured and verified.
How DeployOpen works on this
DeployOpen is a Chainscore Labs company that plans, implements, integrates, hardens, backs up and documents self-hosted open-source platforms inside your own infrastructure. For Bamboo vs Woodpecker CI, we start from your Bamboo plans, your Bitbucket Data Center setup and the deployment steps your teams depend on, then decide with you whether Woodpecker CI fits.
How we scope
- Inventory Bamboo plans, deployment projects, agents and the secrets each one uses before any build is rewritten.
- Confirm the Bitbucket Data Center forge connection, webhook events and agent placement in your environment.
- Agree in writing which plans move, which deployment steps are replaced and what stays on Bamboo during cut-over.
How we build
- Translate selected Bamboo plans into Woodpecker workflow files that run each step in a named container image.
- Set up the Woodpecker server, agents and database, choosing SQLite or PostgreSQL or MariaDB for your expected scale.
- Test workflows against real pull request and branch events, and record which Bamboo tasks need a plugin or custom image.
How we hand over
- Document the workflow files, agent configuration, secret handling and the mapping from each original Bamboo plan.
- Provide a written list of the parts that needed manual work, such as re-created secrets and unsupported task types.
- Run a supervised handover so your platform team can operate, back up and change the Woodpecker installation.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Plan Woodpecker version upgrades, such as moving between releases, with a tested rollback path for each change.
- Ask us to repeat security testing of the CI environment as your pipelines and plugins change over time.
