Bitbucket Pipelines vs Woodpecker CI: which fits your build estate
Bitbucket Pipelines fits teams that accept hosted builds and Atlassian-managed runners, while Woodpecker CI fits teams that run build agents themselves and keep Bitbucket as the forge. If your pressure comes from build minute limits, per-slot runner fees or a rule that build execution must stay on your own servers, the choice is less about features and more about who operates the build infrastructure. Woodpecker connects to Bitbucket and Bitbucket Datacenter, so repositories, pull requests and branch rules can stay where they are while the server, agents and workflow execution move in-house.
Three questions should decide the matter. First, who will patch and scale the Woodpecker server, its database (SQLite by default, with PostgreSQL or MariaDB recommended for larger instances) and the agents that run Docker, Kubernetes or local workloads. Second, where secrets and artifacts must live. Hosted CI holds deployment secrets for every connected project, and Bitbucket secured variables can only be replaced or deleted, so plan a re-entry process with an owner for each value and a record of which pipelines depend on it. Artifacts in Bitbucket Pipelines expire after at most 14 days, so an in-house store with your own retention policy is a deliberate design choice you should confirm with your security and compliance teams.
Third, measure the translation effort. Bitbucket Pipelines uses bitbucket-pipelines.yml, while Woodpecker uses its own YAML, with steps that run inside container images, when filters and depends_on ordering. Pipes do not map one to one onto Woodpecker plugins, so count the pipes your repositories use and check each plugin in the plugin index before you commit. Pilot one representative repository with a deploy step and a secured variable. The results will show whether your team can absorb the change, and the same test gives you the operating data needed for a quote.
Which option fits which scenario
This table matches common situations to the option that usually fits better, Bitbucket Pipelines or self-hosted Woodpecker CI. Read each row as a condition: the condition in the right-hand column is what should decide the choice, and it is worth checking against your own build volume, staffing and data rules before you move.
| Situation | Better fit | Condition that drives the choice |
|---|---|---|
| Low build volume with no build-infrastructure staff | Bitbucket Pipelines | Hosted builds avoid running agents, autoscaling and upgrades. Stay here while included minutes cover your builds and nobody on the team wants to operate CI servers. |
| High build volume hitting minute or slot charges | Woodpecker CI on your own agents | Your bill grows with build minutes and concurrent premium runner slots. Compare that spend with the servers, maintenance and staff time needed to run agents, and ask Atlassian to confirm current rates for your plan. |
| Strict requirements to keep secrets and artifacts on owned servers | Woodpecker CI | Hosted pipelines store secured variables and keep artifacts on the vendor's side for a limited period. Woodpecker runs on your infrastructure, but you must still define how secrets are injected, rotated and kept out of logs. |
| Bitbucket Data Center estates | Woodpecker CI with Bitbucket Datacenter | Woodpecker lists Bitbucket Datacenter as a supported forge, so builds can move in-house while repositories stay on your existing server. Confirm the supported event types and webhook setup for your version. |
| Teams with no Kubernetes or Docker operations skills | Bitbucket Pipelines for now, or a managed Woodpecker plan from a partner | Woodpecker agents run workflows on Docker, Kubernetes or the local machine, so someone must own the container runtime, agent upgrades and the database. Without that skill, the operating cost can exceed the hosted fees. |
How the two options differ in day-to-day use
Bitbucket Pipelines reads a bitbucket-pipelines.yml file at the root of each repository. Pipelines are organized around steps, with optional parallel steps, reusable pipes for common tasks, caches and artifacts passed between steps, and deployment environments with their own variables. Atlassian runs the build infrastructure in Bitbucket Cloud, so a team that uses hosted runners has no CI servers to patch. Teams that need builds on their own machines can attach self-hosted runners, which Atlassian meters per concurrent build slot for premium runners from runner version 5.
- Configuration in one file: Pipeline definitions, branch rules and pipes all live in
bitbucket-pipelines.ymlnext to the code. - Pipes as building blocks: Common tasks such as deployments are called as pipes rather than written as raw scripts.
- Hosted by default: Builds run on Atlassian infrastructure without a server the team operates.
- Self-hosted runners as an add-on: Runners on your own machines are a licensed option tied to the Bitbucket account.
- Short artifact retention: Artifacts are kept for at most 14 days, so builds that must be retained longer need an export step.
Before comparing, confirm which runner version and plan your team uses, and check the current artifact and runner terms in Atlassian's documentation.
Woodpecker CI reads YAML from a single .woodpecker.yaml file or from several files in a .woodpecker/ directory, and those files run as parallel workflows with depends_on ordering. Every step runs its commands inside a container image you name, and steps can start service containers, filter on event, branch or path, and expand into matrix builds. Plugins are container images configured through a settings block, so a team can reuse the plugin index or write its own image. The server receives webhooks from the forge, parses the YAML and serves the UI, while agents pick up workflows over gRPC and run them on Docker, Kubernetes or the local machine.
- Workflow files in the repository: Developers keep
.woodpecker.yamlor.woodpecker/files alongside the code, with the Bitbucket repository unchanged. - Container image per step: Each step declares its image, so build tools are versioned with the pipeline.
- Plugins may need changes: Drone plugins generally work, but the documentation notes that some may need adjustments.
- Server and agents to operate: The team runs the server, database and agents, with an optional autoscaler for cloud VMs.
- Kubernetes backend behavior: Each step runs in its own pod, and a temporary persistent volume claim shares files between steps.
Before committing to this model, confirm which forge integration your Bitbucket or Bitbucket Datacenter setup needs and test each plugin your pipelines depend on.
For a developer, the largest change is the pipeline file. Bitbucket step definitions and pipes need to be rewritten as Woodpecker steps that call container images, and each script must run inside an image that contains its tools. Pull request status checks still come from the forge, so the review flow in Bitbucket stays familiar. The learning curve is mostly about container images, environment variables and how Woodpecker passes data between parallel workflows.
- Rewriting pipes: Each Bitbucket pipe becomes a plugin or a plain container step, which may require new settings.
- Images replace the runner image: Developers choose a container image per step instead of relying on a default build image.
- Parallel workflows: Splitting a pipeline into several files changes how dependencies are expressed.
- Secrets are set again: Secured variables cannot be read back from Bitbucket, so developers must coordinate new values with the operations team.
- Logs and status: Build logs and status checks appear in the Woodpecker UI and back in Bitbucket, so developers check two places during early adoption.
Ask a few application teams to convert one real pipeline in a test repository and measure how many changes the conversion needed.
The operations team takes on what Atlassian currently runs. That includes the Woodpecker server and database, the agent fleet, capacity for concurrent builds, TLS and webhook reachability, backups, and upgrades to new Woodpecker releases. The project's 3.19.0 release fixed a matrix environment injection in the default clone step and enforces agent labels on the server, which is the kind of change an operator must schedule and test. The database default is SQLite, and the documentation recommends PostgreSQL or MariaDB for larger instances.
- Server and database: Choose SQLite for a small trial or PostgreSQL or MariaDB for larger instances, then back it up.
- Agent capacity: Size agents for peak concurrent builds, using the autoscaler for cloud VMs if demand varies.
- Upgrade cadence: Track Woodpecker releases and test pipelines before rolling out server and agent updates.
- Secrets storage: Decide where deployment credentials live and who can read them, since they move out of a vendor-managed store.
- Monitoring and on-call: Someone must respond when agents fail or webhooks stop arriving.
Confirm the expected build volume, the database choice and the on-call owner before estimating staff time.
Capability comparison from supported facts
This table sets Bitbucket Pipelines against Woodpecker CI on the capabilities a migration depends on, using only what the vendor and project documentation supports. Where a row says to confirm, check the specific pipe, feature or edition against your own pipeline files before you commit to a move.
| Capability | Bitbucket Pipelines | Woodpecker CI |
|---|---|---|
| Pipeline file format | bitbucket-pipelines.yml in each repository | Workflow YAML in a single .woodpecker.yaml or several files in a .woodpecker/ directory |
| Container image per step | Each step runs in a Docker image; confirm image settings for your specific pipeline | Every step runs its commands inside a specified container image |
| Parallel and dependent workflows | Parallel steps are available; confirm the exact dependency model you use | Multiple workflows run in parallel, with depends_on ordering between them |
| Matrix builds | Confirm support against your current pipeline syntax | Supported through matrix builds in the workflow syntax |
| Path and branch filters | Branch-based pipeline selection; confirm path-level conditions you rely on | when filters on event, branch, path and other conditions |
| Plugins or pipes | Pipes are Atlassian-maintained building blocks; confirm an equivalent exists for each pipe you use | Plugins are container images configured through a settings block, listed in the plugin index; some Drone plugins may need adjustment |
| Self-hosted execution | Self-hosted runners are metered per concurrent build slot for premium runners from runner version 5 | Agents run on Docker, Kubernetes or the local machine, and an optional autoscaler creates cloud VMs |
| Supported forges | Bitbucket Cloud as the forge for the pipelines | GitHub, Gitea, Forgejo, GitLab, Bitbucket and Bitbucket Datacenter; multiple forges on one server is experimental |
| Secrets handling | Secured variables can only be replaced or deleted, not read back | Secrets must be re-entered in Woodpecker; confirm the secret store and scoping you need |
| Artifact retention | Artifacts kept for at most 14 days | Retention is set by your own server and storage, so you control how long builds are kept |
| Licensing | Proprietary hosted service billed by build minutes | Apache-2.0 for the code, with documentation under CC BY-SA 4.0 |
Where builds, secrets and artifacts live under each option
Moving from Bitbucket Pipelines to Woodpecker CI changes where builds run, where secrets are held and who controls artifact retention, while repositories can stay in Bitbucket. Each card below covers one of these decisions or the compliance checks that follow from them, so the migration team can confirm the answer for its own environment.
Build execution location
Bitbucket Pipelines runs steps on Atlassian-managed build infrastructure, billed in build minutes, with self-hosted runners as an option. Woodpecker CI runs each workflow on agents you operate, which can use Docker, Kubernetes or the local machine. Confirm where build containers, network egress and build logs will run, and whose machines carry the load at peak.
Secret storage and migration
Secured variables cannot be read back in Bitbucket, so they can only be replaced or deleted during a move. Woodpecker needs its own secret store for deployment credentials, and that store becomes a new system of record. Plan to recreate each secret from its source system, rotate it, and record which projects received it.
Artifact retention and ownership
Bitbucket Pipelines keeps artifacts for at most 14 days, a limit set by Atlassian. On Woodpecker, retention follows the storage you attach to the pipeline, so you set the policy. Export any artifacts or build records your audit or release process needs before the move, and confirm the retention rules in your own object or file storage.
Bitbucket Cloud or Datacenter as the forge
Woodpecker lists Bitbucket and Bitbucket Datacenter among its supported forges, so repositories can stay where they are. Cloud and Datacenter differ in webhook setup, authentication and access tokens, and the forge must send push, tag and pull request events. Confirm which edition your organization runs before choosing the connection method.
Woodpecker server and database placement
A Woodpecker installation includes a server for the UI, API and webhooks, agents that connect over gRPC, and an optional autoscaler. The server uses SQLite by default, with PostgreSQL or MariaDB recommended for larger instances. Decide where the server, database and backups sit within your network zones, and who patches them.
Identity and audit evidence
Bitbucket Pipelines access follows Atlassian account and workspace permissions. Woodpecker has its own user, token and agent registration model, so access reviews, log retention and change records move to your systems. Ask the compliance team which logs must be kept, who can approve pipeline changes, and how agent access is revoked when staff leave.
What you pay for in each option
The Bitbucket Pipelines side of the bill has three parts, and only one of them goes away if you move builds. Per-user Bitbucket fees stay in place under either option because repositories, pull requests and access control remain on Bitbucket. Build minutes are the hosted cost, and they recur monthly with your plan's included allowance and any extra minutes you buy. If you run your own machines, Atlassian's premium self-hosted runner rate of $15 per month per concurrent build slot, stated in its v5 self-hosted runners announcement, applies to each slot you need to run builds in parallel. Ask Atlassian which runner version and plan your account uses, and whether the slot charge applies to the runners you already operate.
The Woodpecker CI side is different in kind. Woodpecker's software is open source under Apache-2.0, so the license line is zero, but you pay for the infrastructure and the people who run it. Those costs include the server that hosts the UI, API and webhook intake, agent capacity on Docker, Kubernetes or local machines, a PostgreSQL or MariaDB database for anything beyond a small pilot, artifact and cache storage, and the optional autoscaler if you want cloud VMs created for queued builds. Costs rise with concurrent pipelines, retained build history and the number of forges you connect, and they fall when agents scale to demand. Engineering time for upgrades, security patches, plugin compatibility checks and on-call support is usually the largest recurring item and should be estimated explicitly.
When you request a quote from an implementation partner or compare internal estimates, ask for each component as a separate line: one-time migration work (translating bitbucket-pipelines.yml, replacing secured variables and exporting artifacts), recurring infrastructure, backup and disaster recovery, support hours, and upgrade effort. Confirm with Atlassian which fees will continue after you stop using hosted minutes. Keep a record of your current monthly build minutes and peak concurrent slots, since those two numbers drive both sides of the comparison.
Cost components, one-time and recurring
Each line below is a one-time cost to move, a recurring cost to run, or a cost that disappears after migration. Bitbucket Pipelines costs sit in seats, build minutes and runner slots, while Woodpecker costs sit in the servers, agents and people you run. Use the drivers on each card to write a quote request that compares the two like for like.
Forge seats stay the same
Repository and user licensing stays with Bitbucket, because Woodpecker connects to Bitbucket and Bitbucket Datacenter as forges. Seat fees do not change in this migration, so they belong on both sides of the comparison as an unchanged line. Check whether your current Bitbucket plan bundles Pipelines minutes or runner access with seats, since that bundling decides which line items actually disappear. Confirm with Atlassian which features your tier includes, and confirm that Woodpecker's Bitbucket integration covers the events and permissions your team uses.
Hosted minutes and runner slots
Pipelines bills build minutes on Atlassian's hosted runners, and self-managed runners now carry a per-slot charge. Atlassian's v5 self-hosted runner announcement sets premium runner pricing per concurrent build slot, so the fee follows peak parallelism. A team that raises concurrency pays more even when total build work stays the same. Multiply your peak concurrent jobs by the current Atlassian rate, then ask Atlassian in writing whether minutes and slots are billed separately.
Woodpecker server, agents and compute
Woodpecker runs one server for the UI, API, webhooks and YAML parsing, plus agents that execute workflows over gRPC. Agents can run on Docker, Kubernetes or the local machine, and an optional autoscaler creates cloud VMs for pending builds. Compute for build jobs is usually the largest recurring cost, and it rises with concurrency, build length and test volume. Ask for sizing based on your peak parallel jobs, your chosen agent backend and whether autoscaling is in scope.
Database, storage and backups
Woodpecker uses SQLite by default, and its documentation recommends PostgreSQL or MariaDB for larger instances. On Kubernetes, each pipeline gets a temporary persistent volume claim to share files between steps, so storage grows with concurrent pipelines. Database backups and restore tests are recurring work, and they belong in the run budget. Ask the provider to name the database engine, backup frequency, retention period and the location of backup copies.
Upgrades, patching and staff time
Woodpecker ships point releases with fixes. A recent one corrected injection of matrix variables into the default clone step and added server-side enforcement of agent labels. Each upgrade touches the server, the agents and the plugin images your pipelines call. Staff time for patching and on-call cover is the cost teams most often underestimate, and it grows with team size, forge count and plugin count. Ask for an upgrade calendar, written response times and the named owner for incidents outside business hours.
Migration effort and data exports
Migration is a one-time cost. It covers translating bitbucket-pipelines.yml steps into Woodpecker workflows, rebuilding caches and artifacts, and re-entering secrets. Bitbucket secured variables can only be replaced or deleted, so values must come from their original source systems. Re-entering secrets and exporting build history set the effort, because Bitbucket keeps artifacts only for a short window. Ask for a pipeline inventory, a per-repository translation estimate and a cutover plan with a rollback path.
How a move from Bitbucket Pipelines to Woodpecker CI proceeds
The sequence keeps repositories in Bitbucket while builds, secrets and build history move to infrastructure you control, with each phase closed by a check before the next starts.
Inventory repositories and pipeline files
Your engineering lead or platform team lists every repository that has a bitbucket-pipelines.yml file, the branches and events that trigger builds, the pipes and custom images each pipeline calls, and the deployment targets it reaches. Record which repositories use secured variables, caches and artifacts, since those need separate handling. The output is a migration register with one row per repository and an owner for each. The step is done when every active pipeline has a row and every pipe has been identified as a plugin, a custom image or a script.
Export build history and artifacts first
Before any cut-over work, the team downloads the build logs, test reports and artifacts it needs for audit or rollback from Bitbucket Pipelines. Artifacts in Bitbucket Pipelines are kept for at most 14 days, so this export starts early and runs on a fixed schedule rather than waiting for the migration plan to finish. Store the exports in your own storage with retention rules set by your compliance owner. The step is complete when each repository's required history is in your storage and a sample has been opened and checked.
Stand up the Woodpecker server and agents
The platform team installs the Woodpecker server, which provides the UI and API and receives forge webhooks, and one or more agents that run workflows over gRPC. Choose the execution backend for each agent pool, Docker, Kubernetes or the local machine, and decide whether an autoscaler is needed for burst capacity. Configure the Bitbucket forge connection, using Bitbucket Datacenter settings if that is your forge. Confirm the database choice: SQLite is the default, and PostgreSQL or MariaDB is recommended for larger instances. The step is done when a test repository builds on an agent you run.
Translate pipelines into Woodpecker workflows
A developer or build engineer rewrites each bitbucket-pipelines.yml as a Woodpecker workflow, either a single .woodpecker.yaml or several files in a .woodpecker/ directory. Each Bitbucket step becomes a Woodpecker step that runs in a specified container image, pipes become plugin steps or explicit commands, and parallel steps map to workflows or matrix builds. Check that event and branch filters match the original triggers, and that any cache or artifact behavior is reproduced with explicit steps. The step is done when each translated file passes a test run on a branch and produces the same outputs as the Bitbucket build.
Reissue secrets in the new system
Secured variables in Bitbucket can only be replaced or deleted, so their values cannot be copied into Woodpecker. Each owner generates new credentials at the source service, such as deploy keys, cloud access keys and registry tokens, and stores them as Woodpecker secrets scoped to the correct repositories. Retire the old credentials once the new ones are verified, and record who issued each one. The step is complete when every pipeline that used a secured variable runs successfully with a new secret and the old secret is revoked.
Connect webhooks and build status reporting
The team confirms that Bitbucket webhooks for push, tag and pull request events reach the Woodpecker server, and that build status is reported back to Bitbucket so pull request checks and merge rules still work. Because multi-forge support on one server is experimental, keep one Woodpecker server per forge unless your vendor confirms otherwise. Test each event type on a sample repository and confirm that failed builds block merges as before. The step is done when a pull request shows the expected status checks from Woodpecker.
Run both systems in parallel
For a defined period agreed by the project owners, both Bitbucket Pipelines and Woodpecker run the same pipelines for each migrated repository. The team compares build results, test counts, artifact outputs and deployment effects, and logs every difference with a cause and a fix. Parallel running also tests the secret replacements and agent capacity under real queue load. The step is complete when the migration register shows no open differences for a repository and its owner signs off in writing.
Cut over and decommission hosted runners
Once a repository passes parallel running, the team disables its Bitbucket Pipelines configuration, makes Woodpecker the only build trigger, and removes any remaining Bitbucket Pipelines variables that held live values. Hosted runner usage and any self-hosted runner licenses are checked against the final invoice, and the cancellation is recorded with the vendor. Keep the exported history and the migration register as the record. The step is done when every repository in the register reports Woodpecker as its only CI system and the Bitbucket billing lines for pipelines have stopped.
What the YAML and secrets work involves
The YAML conversion is a mapping exercise, not a find-and-replace. A bitbucket-pipelines.yml file organizes work around pipelines, steps and pipes, while Woodpecker reads a single .woodpecker.yaml or a .woodpecker/ directory of workflow files in which every step runs its commands inside a named container image, with optional service containers and when filters on event, branch and path. Each Bitbucket step therefore needs an image, a commands list and a trigger condition written out explicitly. Pipes are the part that needs the closest review. A Bitbucket pipe is a packaged integration, and each one must either be replaced by a Woodpecker plugin from the plugin index, which takes a settings block, or rewritten as explicit commands. The Woodpecker documentation says Drone plugins generally work but may need adjustments, so every plugin should be run once against a non-production repository and its output compared with the Bitbucket run.
Caches and artifacts also need new definitions. Bitbucket artifacts are passed between steps and expire after at most 14 days, and the Woodpecker equivalent depends on how the team stores files between steps and where it keeps them afterward. Dependency caches should be checked for the paths the build actually uses, and artifacts that must outlive a run should be sent to a storage location the team controls. Map each one to a named owner.
Secured variables are the step that cannot be automated. Bitbucket secured variables can only be replaced or deleted, so their values will not appear in the new Woodpecker server. Each secret must be recreated from its source system, such as the cloud provider, the registry or the deployment target, and the team should confirm which of those values are still valid, which should be rotated during the move, and which belong to a service account rather than a person. Store them in the Woodpecker secrets store or in an external secrets manager, and restrict each one to the repositories that need it. Record who approved each recreated secret so the migration leaves an audit trail.
Questions buyers ask before choosing Woodpecker CI over Bitbucket Pipelines
How much work does moving from Bitbucket Pipelines to Woodpecker CI involve?
The work scales with how many repositories you have, how complex each bitbucket-pipelines.yml file is, and how many deployment steps depend on Bitbucket-specific features. Each pipeline has to be translated into Woodpecker YAML, where every step runs inside a container image and plugins are container images configured through a settings block. Plugins from the Drone ecosystem generally work but may need adjustments, so pipes used in Bitbucket need to be matched to a Woodpecker plugin or rewritten as commands. Ask any implementer to inventory your pipelines first, since that inventory is what sets the scope, the timeline and the price in a written quote.
Can our team move to Woodpecker CI without outside help?
A team with experience running CI servers and container workloads can often do a small migration in-house, especially if it has few pipelines and no unusual deployment steps. The harder parts are the server and agent setup, the forge connection to Bitbucket, secret replacement and the validation of every pipeline against its previous results. Teams with many repositories, regulated release controls or limited spare engineering time usually weigh an outside implementation partner against the staff hours they would otherwise spend. DeployOpen plans, implements and documents this kind of migration under a fixed scope agreed in writing before work starts.
What skills does our staff need to run Woodpecker CI?
Operators need working knowledge of containers, since every workflow step runs its commands in a container image and agents can run workflows on Docker, Kubernetes or the local machine. If you choose the Kubernetes backend, you also need Kubernetes operations skills, including how each step runs as a standalone pod and how the temporary persistent volume claim is provisioned. Woodpecker uses SQLite by default, while PostgreSQL or MariaDB is recommended for larger instances, so someone must own database backups and upgrades. Staff should also know how the server, agents and optional autoscaler connect, because that is where most support requests start.
Does Woodpecker CI work if we use Bitbucket Data Center?
Yes. Woodpecker's forge documentation lists Bitbucket Datacenter alongside Bitbucket Cloud, with push, tag and pull request events supported on the forges it lists. This lets you keep repositories on a self-managed Bitbucket and run builds on your own servers. Atlassian has announced 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, while its journey-to-cloud page states that Bitbucket and Bamboo Data Center will continue beyond that date under a Bitbucket Hybrid License. Confirm the current licensing and support position with Atlassian before you commit to a platform.
How do secrets and build artifacts carry over during cutover?
Secured Bitbucket variables cannot be exported. Atlassian's documentation says they can only be replaced or deleted, so each deployment credential must be re-entered in Woodpecker or in the system that stores it, and the old values should be rotated at the same time. Build artifacts are a different problem: Bitbucket Pipelines keeps artifacts for at most 14 days, so anything you need for audit or rollback has to be exported before the migration window closes. Plan the cutover so that old and new pipelines run in parallel for a set period, and record which credentials were replaced and when.
When is staying on Bitbucket Pipelines the better choice?
Staying on Bitbucket Pipelines makes more sense when your build volume is small, your pipelines are simple, and you do not have staff time to run a CI server. It also fits teams that value a managed service over control of build infrastructure. The cost comparison depends on your metered build minutes and on whether you use self-hosted runners, since Atlassian charges $15 per month per concurrent build slot for premium Bitbucket Pipelines runners from runner version 5. Moving makes more sense when runner fees, data residency or secret exposure are the concern. Model both options with your real usage before deciding.
What recurring costs should we expect after moving to Woodpecker CI?
Woodpecker's software is open source under Apache-2.0, so the recurring costs are the infrastructure and the people. You pay for server and agent capacity, database hosting, storage, backups and monitoring, plus staff time for upgrades such as the 3.19.0 release, which was published on October 7, 2026 and fixed an injection of matrix environment variables into the default clone step. If you want outside support, a retainer covers upgrades and continuous testing. Ask any vendor for a quote that separates one-time migration work from these recurring items so you can compare them with your Bitbucket invoices.
How DeployOpen helps evaluate, implement or migrate
DeployOpen is a Chainscore Labs company that plans, implements, hardens, backs up and documents self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For this move, that means an engagement that starts with an evaluation of your pipeline estate rather than a switch-over. The evaluation inventories every repository that has a bitbucket-pipelines.yml, the pipes and custom images each one calls, the caches and artifacts it depends on, and the deployment steps that rely on secured variables. It also confirms which Bitbucket setup you run, including whether you are on Bitbucket Cloud or Bitbucket Datacenter, because that determines how Woodpecker connects to your forge. The output is a written inventory and a recommended order of migration.
Implementation covers the Woodpecker server, the agents and the backend you choose, whether Docker, Kubernetes or local machines, with a database sized for your build volume. Translation work converts pipeline files into Woodpecker YAML and checks each converted pipeline against its original, including the event and branch filters that decide when builds run. Secret reissue planning is handled as its own workstream: because secured variables cannot be read back from Bitbucket, the plan lists each credential, who can issue its replacement, and the order in which deployment targets accept the new values. Build history export and the rollback path are documented before any cutover.
Scope, deliverables and timelines are agreed in writing before work starts, and DeployOpen does not publish a price list. A quote follows from that written scope, so ask for it to name each workstream above, the environments in scope and the acceptance tests. Ongoing support, upgrades and continuous testing of the CI platform are available as retainers, which is useful once Woodpecker releases such as 3.19.0 need to be planned into your change calendar. DeployOpen prepares the systems and evidence for your assessments, but independent auditors and certification bodies issue any audit reports or certifications.
