Migrate from Bitbucket Pipelines to Woodpecker CI

Migrate from Bitbucket Pipelines to Woodpecker CI: the short answer on effort and risk

If your repositories must stay in Bitbucket Cloud but builds need to move to infrastructure you control, Woodpecker CI can do that without moving the code. Woodpecker connects to Bitbucket and Bitbucket Datacenter as forges, with push, tag and pull request events supported, so the server receives webhooks from Bitbucket and your own agents run the workflows. The migration is a rewrite of bitbucket-pipelines.yml into Woodpecker YAML, a deployment of the server and agents in your environment, and a cutover of build status reporting. Platform engineers usually do this work with the repository owners, who know which steps, deployments and secrets each project depends on. The Woodpecker forge documentation states that running multiple forges on one server is still experimental, which matters only if you plan to serve more than one forge from the same installation.

The effort depends on how many repositories you have, how many pipes and custom images they use, and whether deployments rely on secured variables. Each pipe in bitbucket-pipelines.yml has to be replaced by a container step or a Woodpecker plugin, and the plugin index does not guarantee that every Drone plugin works unchanged. Secured Bitbucket variables cannot be read back, so the values must be re-entered from their owners' records, and that step needs a named approver and a record of who supplied each value. Artifacts and build history expire in Bitbucket after at most 14 days, so export them before the first run. Confirm with your own team which of these items dominate, because they, not the YAML itself, usually set the schedule.

The main risks are a gap between old and new pipelines during parallel running, secrets copied to a server with weaker access controls than the original workspace, and agents that hold deployment credentials without isolation. Plan for a period where both systems build the same commits, compare outputs, and then retire Bitbucket Pipelines per repository. Decide early where the server and agents run, who administers them, and how patches are applied, because Woodpecker releases such as 3.19.0 include fixes you will want in place. Ask any implementation partner for a written scope that names repositories, pipeline translations, secret handling and the cutover plan before work starts.

Which Bitbucket Pipelines capabilities map cleanly to Woodpecker CI

This table maps each Bitbucket Pipelines capability to its closest Woodpecker CI equivalent and marks it as clean, needs rework or gap. Read the status column first, then the notes, because rows marked needs rework usually mean a translation step rather than a design change. Secured variables and multi-forge setups deserve early review, since they affect cutover planning.

Capability	Bitbucket Pipelines	Woodpecker CI and status
Pipeline definition	bitbucket-pipelines.yml in each repository	Clean: .woodpecker.yaml or a .woodpecker/ directory; syntax is rewritten by hand
Steps and parallel steps	Steps run in a Docker image; parallel steps in one pipeline	Clean: each step runs in a container image; independent workflows run in parallel with depends_on ordering
Pipes	Pre-built pipes referenced by name with variables	Needs rework: pipes become plugin images with settings blocks; confirm each plugin in the plugin index and expect adjustments
Caches	Named and custom caches defined per pipeline	Needs rework: confirm cache approach on your agent backend and rebuild cache paths in the new YAML
Artifacts	Kept for at most 14 days per Atlassian documentation	Needs rework: shared files pass between steps in one pipeline; long-term storage must be your own artifact store
Deployment environments	Deployment environments with variables and approvals	Gap or rework: confirm how your team will gate production deploys and who approves them
Secured variables	Can only be replaced or deleted, not read back	Gap: values must be re-entered in Woodpecker secrets from your own records or vault
Triggers and status reporting	Branch, tag and pull request triggers; build status on commits	Clean for Bitbucket and Bitbucket Datacenter forges; confirm status checks in your forge version

How bitbucket-pipelines.yml steps become Woodpecker workflows

Start with the file layout, because it sets how the rest of the translation reads. A Bitbucket repository has one bitbucket-pipelines.yml, while Woodpecker reads either a single .woodpecker.yaml or several files in a .woodpecker/ directory, as described in the Woodpecker workflows documentation. Each file in that directory runs as a parallel workflow, and depends_on sets the order between them. Map each Bitbucket pipeline to one workflow file, then translate the steps inside it. Bitbucket runs steps in sequence unless a parallel block says otherwise, so a sequential run becomes a chain of steps, or workflows that name each other in depends_on when one stage must finish before the next starts. Decide this split for each repository before writing any YAML, because it determines how results appear in the Woodpecker UI.

Every Woodpecker step runs its commands inside the container image named in that step, so each Bitbucket step needs an explicit image value, either set per step or shared at the workflow level. Confirm that every image is available to your agents, and check that each script still works inside it, since shell, user and working directory defaults can differ between the two systems. Trigger rules need the most attention. Bitbucket branches, pull-requests and custom blocks become when conditions in Woodpecker, filtered on event, branch and path, as set out in the workflow syntax documentation. Write each condition from the behavior your team wants, then test it with a push, a pull request and a tag before the old pipeline is turned off.

Matrix builds and service containers need their own decisions. Matrix builds expand one step across variable combinations, so several near-identical Bitbucket steps, such as one job per runtime version, can often collapse into one definition. Service containers, such as a database that tests need, are declared on the workflow so they start alongside the step, and their ports and credentials must match what the tests expect. Pipes are the largest manual item. A Bitbucket pipe is a prebuilt container configured through variables, and its Woodpecker counterpart is a plugin configured through a settings block, which the plugins overview notes may need adjustments. Check each pipe against its plugin index entry and test its inputs. Treat the translated files as drafts that a person reviews line by line against the old pipeline, not as output that can run unattended.

What data and integrations move, and what must be rebuilt

A Bitbucket to Woodpecker move splits into three groups: files that travel with the repository, values that must be re-entered by hand, and history that expires unless you export it first. Use this inventory to plan the cutover window and to name an owner for each item before work starts.

Pipeline definitions in each repository

The bitbucket-pipelines.yml file lives in each repository, so it moves with the code and can be rewritten as Woodpecker workflows under a .woodpecker/ directory or as a single .woodpecker.yaml. Steps map to Woodpecker steps that each run inside a container image, and pipes need to be replaced with plugin-style steps. Check each pipe and custom image against the plugin index, because some Drone-style plugins may need adjustments.

Secured variables must be re-entered

Bitbucket secured variables can only be replaced or deleted, so their values cannot be copied into Woodpecker. Record which variables exist, which repositories and deployment environments use them, and who holds the source values. Issue fresh credentials where possible, store them in Woodpecker's secret handling, and rotate any value that was shared through a chat tool or ticket during setup.

Artifacts expire after at most 14 days

Bitbucket Pipelines keeps artifacts for at most 14 days, so any artifact a release or audit depends on must be downloaded and stored in your own repository or artifact store before cutover. Confirm with Atlassian whether artifacts from older pipelines can still be retrieved on your plan, and decide whether Woodpecker will publish to the same registry or a new one.

Build history and logs

Pipeline run history and logs are not carried into Woodpecker, so they remain in Bitbucket only for their documented retention. If you need them for incident reviews or compliance evidence, export the relevant run records and logs on a schedule before the window closes. Ask Atlassian which export options your plan supports and how far back they reach.

Webhooks and build status reporting

Woodpecker connects to Bitbucket as a forge and registers its own webhooks for push, tag and pull request events, so builds start from the new server once the forge connection is in place. Confirm that the Bitbucket user or app used for the connection has the repository permissions it needs to post build statuses, and remove the old Pipelines triggers so builds do not run twice during the overlap.

The migration sequence from inventory to decommission

This sequence moves builds from Bitbucket Pipelines to Woodpecker CI one repository at a time while the repositories stay in Bitbucket. Each step produces a record the next step depends on, so the team can prove parity and roll back at any point before decommission.

Inventory repositories, pipes, variables and artifacts
The platform lead, with each repository owner, lists every repository that runs Pipelines and records the bitbucket-pipelines.yml steps, the pipes they call, the deployment environments, the secured variables and the artifact dependencies between steps. Secured variables cannot be read back in Bitbucket, so record which ones exist and who owns each value. Export build history and any artifacts you need before retention windows close. The output is a translation register with one row per repository, and the step is done when every repository in scope has a row and an owner.
Translate pipelines and pipes into Woodpecker workflows
Engineers rewrite each bitbucket-pipelines.yml as a Woodpecker workflow, either a single .woodpecker.yaml or several files in a .woodpecker/ directory. Each Bitbucket step maps to a Woodpecker step that runs in a container image, and each pipe maps to an existing Woodpecker plugin or to a script step, since Drone plugins generally work but may need adjustments. Record every pipe that has no direct equivalent in the register. Caches and artifacts need an explicit plan, because passing files between steps depends on how your Woodpecker backend shares the workspace. The output is a reviewed workflow file per repository and a list of open gaps.
Build the secrets and agent foundation
The platform team installs the Woodpecker server and agents in your infrastructure, chooses the database (SQLite by default, with PostgreSQL or MariaDB recommended for larger instances), and selects Docker, Kubernetes or local execution for agents. Secrets are re-entered by their owners into Woodpecker's secret store, because Bitbucket secured variables can only be replaced or deleted and cannot be copied out. Restrict secrets to the repositories that need them and confirm the Bitbucket forge connection and webhooks work. The output is a running server with a documented secret inventory, and the step is done when a test pipeline runs on a sandbox repository.
Pilot on one low-risk repository
Choose a repository with a simple build, no production deployment and a clear owner, then run its Woodpecker workflow on push and pull request events while Bitbucket Pipelines stays enabled. The pilot checks that the workflow runs, that build status reaches Bitbucket pull requests, that artifacts and test results match the Bitbucket output, and that the team can follow the logs. Record every difference and fix the workflow until the differences are understood. The output is a pilot report listing the issues found, their fixes and the owner's sign-off.
Run both systems in parallel
For each repository in scope, both Bitbucket Pipelines and Woodpecker build the same commits for an agreed observation period. Compare pass and fail results, test counts, build artifacts and build times, and check that deployment steps are blocked on Woodpecker until the cutover decision, so two systems never deploy the same release. Keep the Bitbucket configuration unchanged so it remains the source of truth. The output is a parity log per repository, and the step is done when the owner confirms that results match for the agreed commits.
Cut over each repository with a rollback path
The owner of each repository switches its deployment and required status checks to Woodpecker, using a written cutover checklist that names the secrets, branch rules, deployment environments and the person who approves the change. The Bitbucket pipeline definition stays in the repository and can be re-enabled if a release fails, and the rollback steps are rehearsed before the switch. Monitor the first releases after cutover. The output is a signed cutover checklist per repository, and the step is done when the owner confirms that the repository has shipped at least one release from Woodpecker.
Decommission after runner and variable cleanup
Once every repository in scope has passed its cutover and the rollback window is closed, the team disables Pipelines in each repository, removes Bitbucket self-hosted runners and their slots, deletes the secured variables that are no longer needed, and revokes any tokens or deploy keys that Bitbucket used. Archive the translation register, parity logs and cutover checklists with the build history export. Confirm the billing change with Atlassian before the next invoice. The output is a decommission record, and the step is done when no repository still references Bitbucket Pipelines and no runner or secret remains active.

How to run Woodpecker and Bitbucket Pipelines in parallel and cut over

The safe way to move builds is to run Woodpecker CI in shadow beside Bitbucket Pipelines on a small set of branches while the existing pipeline stays the gate that merges depend on. Pick one low-risk repository first, add a .woodpecker.yaml or .woodpecker/ directory, and set Woodpecker's event and branch filters so it runs on pull requests into a test branch and on pushes to a feature branch only. Both systems report commit statuses to the same Bitbucket pull request, so the team can compare pass and fail results, test counts, build durations and produced artifacts for the same commit. Confirm in your Woodpecker version that the Bitbucket forge reports status back under the context name you choose, because the name you see in Bitbucket is what branch restrictions will reference.

Once several weeks of matching results exist, make the Woodpecker status a required status check in the Bitbucket branch restrictions for that repository, while keeping the Bitbucket Pipelines check required as well until the Woodpecker check has proven it blocks bad merges. Test this with a deliberately failing commit on a non-production branch. Only after the Woodpecker status is enforced and the deployment jobs have been moved and verified should you disable the Bitbucket pipeline for that repository. Keep bitbucket-pipelines.yml in version control rather than deleting it from history, tag the last commit that ran cleanly on Bitbucket Pipelines, and record which secured variables were recreated in Woodpecker. Because Bitbucket secured variables can only be replaced or deleted, rollback depends on the value holders still having access to the originals in your secrets store, so confirm that before disabling anything.

What drives cost and duration in a Bitbucket to Woodpecker move

This table lists the factors that move the cost and schedule of keeping repositories in Bitbucket while moving builds to Woodpecker CI. Read each row as a question to answer in your scope, since the biggest effort usually comes from pipes, secrets and compliance evidence rather than from the server itself.

Driver	Why it moves cost or effort	How to keep it down
Repository count	Each repository needs its own .woodpecker.yaml or .woodpecker/ directory, forge webhook and build status check, so effort grows with the number of repos.	Group repos by shared build pattern and migrate in waves, starting with a small set of representative projects.
Pipes and custom scripts	Bitbucket pipes are containers that must be mapped to Woodpecker plugins or rewritten as step commands, and the plugin docs note some Drone plugins need adjustments.	Inventory every pipe version in use, prefer existing plugin index images, and reuse one shared script across repos.
Secured variables and deployment credentials	Bitbucket secured variables can only be replaced or deleted, so each value must be re-entered into Woodpecker secrets by someone with the source system access.	Record which team owns each secret, rotate credentials during the move, and confirm scoping per repository and event.
Artifact dependencies	Bitbucket artifacts expire after at most 14 days, so older build outputs cannot be carried over and steps that pass artifacts between pipelines need redesign.	Export needed artifacts before cutover and decide whether downstream jobs should rebuild or pull from an external registry.
Kubernetes or Docker agent design	Docker agents are simpler to run, while the Kubernetes backend creates a pod per step and a temporary persistent volume claim (10G and ReadWriteMany by default) for each pipeline, adding cluster and storage work.	Start with Docker on a few agents if your cluster does not offer ReadWriteMany storage, and size the Kubernetes option only after pipeline shapes are known.
Database choice	Woodpecker uses SQLite by default, while PostgreSQL or MariaDB are recommended for larger instances, so a larger team adds database operations, backups and upgrades.	Use the default for a pilot, then move to PostgreSQL or MariaDB before wider rollout and ask the vendor for a documented migration path.
Compliance evidence needs	Auditors may ask for records of who changed pipeline config, secrets access, build logs and retention, which must be built and kept in your own systems.	Define the evidence list in writing before the build starts and confirm retention for logs and artifacts with your assessor.
Cost components and quote scope	Costs fall into infrastructure for servers and agents, staff time for migration and upkeep, support and upgrades; infrastructure and staff recur, while migration work is largely one-time.	Ask any provider for a written scope listing repos, pipes, secrets, agent design, database, evidence and upgrade cadence, with deliverables and timelines agreed in advance.

How the migration differs by team size and starting point

A small team with a handful of repositories usually has one or two pipelines, a few secured variables and little shared configuration. The main work is translating each bitbucket-pipelines.yml into Woodpecker YAML, standing up one server and one or two agents, and deciding whether a single Docker or Kubernetes backend is enough. Most of the effort sits in rebuilding deployment logic that was never written down.

Pipeline count: Inventory every repository with a pipeline file, including branch and tag rules that were set in the Bitbucket UI.
Secrets: Expect to re-enter every secured variable by hand, because Bitbucket secured variables can only be replaced or deleted.
Artifacts: Download any artifacts you still need, since Bitbucket Pipelines keeps them for at most 14 days.
Single server: SQLite is the default database, which is acceptable for a small instance, but confirm the backup approach before relying on it.
Webhooks: Check that the Bitbucket connection and webhook events work for push, tag and pull request events.

Before cutover, confirm that every repository has one passing build on Woodpecker and that the old pipeline is disabled so builds do not run twice.

A large Bitbucket Cloud estate usually has many repositories that call the same pipes, shared deployment scripts and organization-wide variables. Here the risk is less about translating one file and more about replacing shared behavior. Woodpecker plugins are container images configured through a settings block, and the documentation notes that Drone plugins generally work but may need adjustments, so each pipe needs its own check.

Pipe inventory: List every pipe in use across repositories, then map each to a Woodpecker plugin or a container image you build and maintain.
Shared templates: Plan reusable workflow files in a .woodpecker/ directory so common steps are not copied into hundreds of files.
Parallel migration: Move repositories in batches, keeping Bitbucket Pipelines available for teams that have not yet cut over.
Agent capacity: Size agents and the optional autoscaler from observed concurrency, which you should measure from current build history.
Variables at scale: Replacing secured variables across many repositories is the slowest manual step, so track which owner must supply each value.

Confirm which pipes your organization depends on and whether each has a maintained container image before you commit to a batch schedule.

What usually goes wrong and how to prevent it

Moving from Bitbucket Pipelines to Woodpecker CI is mostly a data and habit problem rather than a YAML problem. The risks below cover secrets, build history, unmapped pipes, forge status reporting, image drift and capacity, and each one has a check you can run before cutover.

Secrets lost or copied in plain text

Bitbucket secured variables can only be replaced or deleted, so their values cannot be carried over. Teams often paste them into a chat, a spreadsheet or a plain YAML file during re-entry, which creates a second copy of the most sensitive data in the pipeline. Re-enter each secret directly into Woodpecker's secrets store from the source system, rotate credentials that were ever shared, and confirm that no value appears in a committed .woodpecker.yaml file.

Artifacts expiring before export

Bitbucket Pipelines keeps artifacts for at most 14 days, so build outputs from older runs disappear on Atlassian's schedule, not yours. If you wait until cutover to pull them, the window may already be closed. Export the artifacts and build logs you need for audit or rollback now, store them in your own object or file storage, and record which pipeline run produced each one.

Pipes with no Woodpecker equivalent

Bitbucket pipes are prebuilt steps that many teams treat as black boxes. Woodpecker plugins are container images configured through a settings block, and the project notes that Drone plugins generally work but may need adjustments. A pipe that has no matching plugin must be rewritten as a plain container step with its own commands. Inventory every pipe: line across repositories before migration and mark each one as mapped, adapted or rewritten.

Status checks still pointing at Bitbucket

Pull requests may still require a Bitbucket build status that a pipeline no longer reports once Woodpecker takes over. Branch merge rules then block merges, or a stale green check hides a failing build. Woodpecker's forge integration reports status to Bitbucket and Bitbucket Datacenter, so confirm the status key names match what your branch restrictions expect, run a test pull request on each protected branch, and remove any Bitbucket Pipelines requirement only after a passing build is confirmed.

Unpinned images changing behavior

Bitbucket steps usually reference an image tag, and a tag such as latest or a broad major version can change under you between runs. The same pipeline may pass one week and fail the next with no code change. Pin each step's container image to a specific version or digest in your Woodpecker workflow files, record the versions in review, and update them through a deliberate pull request rather than by accident.

One agent becoming a bottleneck

A single Woodpecker agent runs every queued workflow, so a busy repository can stall the rest of the team and hide the true build cost. Bitbucket charges by build minutes or concurrent runner slots, so the capacity question is new to your team. Size agents against your peak queue, label agents by purpose, and confirm with your platform team how many concurrent workflows your servers can hold before you retire the hosted runners.

Questions buyers ask before moving from Bitbucket Pipelines to Woodpecker CI

Do we have to move our repositories out of Bitbucket to use Woodpecker CI?

No. Woodpecker CI connects to Bitbucket and Bitbucket Datacenter as forges, so builds can move to servers you run while repositories stay where they are. Push, tag and pull request events are supported on these forges according to the Woodpecker forge documentation. Confirm the exact forge setup for your Bitbucket edition (Cloud or Datacenter) and your authentication method before you commit to a design, because the forge integration is the part of the plan that depends on your environment.

Can we export our Bitbucket secured variables and move them to Woodpecker?

No. Bitbucket secured variables can only be replaced or deleted, so their values cannot be read back for transfer. You will need to re-enter each secret in Woodpecker's secret store from the source system that holds the original credential, such as a cloud account, registry or deploy key. Build the inventory of secured variables first, record which pipelines and deployment targets use each one, and rotate any credential that is shared or old during the cutover. Confirm the current variable behavior in Atlassian's variables and secrets documentation.

How long does a migration from Bitbucket Pipelines to Woodpecker CI take?

The duration depends on how many repositories and pipelines you have, how many use pipes or custom Docker images, how many deployment environments and secrets need re-creating, and how many approval or release steps depend on Bitbucket features. Repositories with simple build and test steps move faster than those with many deployment targets. Ask any provider for a timeline based on a written scope that lists repositories, pipelines, secrets and environments. An estimate that is not tied to that inventory is not useful for planning.

What does the migration need from our engineering team?

Plan for time from the people who own each repository and deployment, because they know which secrets, environments and artifacts matter. You also need someone who can run and secure the Woodpecker server and agents, including container runtime access and database choice. Woodpecker uses SQLite by default and recommends PostgreSQL or MariaDB for larger instances, so the platform owner should decide that early. Expect a parallel run period in which both Bitbucket Pipelines and Woodpecker build the same commits before you switch.

Can our own team do the migration without an outside implementation partner?

Yes, if you have engineers who know Docker, YAML pipelines and your deployment targets, and enough time to test them. Woodpecker is open source under the Apache-2.0 license, so there is no license fee to start. A partner makes sense when the team lacks time, when secrets and compliance evidence need careful handling, or when many pipelines need translation at once. DeployOpen plans, implements and documents self-hosted platforms in your own infrastructure under a written, fixed scope, and a quote follows from that scope.

How does the cost of Woodpecker CI compare with Bitbucket Pipelines by component?

Compare the components, not a single headline price. Bitbucket Pipelines charges for build minutes and, for self-hosted runners, a per-concurrent-slot fee; Atlassian's premium runner pricing is $15 per month per concurrent build slot from runner version 5, according to Atlassian's announcement. Woodpecker itself has no license fee under Apache-2.0, so your recurring costs are the servers or Kubernetes capacity for the server and agents, storage, maintenance, and staff time. One-time costs include migration work and re-entering secrets. Ask any quote to separate these components so you can compare them against your own build volume.

What happens to our build artifacts and history during the switch?

Bitbucket Pipelines keeps artifacts for at most 14 days, according to Atlassian's documentation, so older artifacts and build records will not be available once that window passes. Export anything you need for audit or rollback before you start the cutover, and keep the export location under your control. Woodpecker stores its own pipeline history on the server you run, so plan its retention and backup policy as part of the target design.

Primary sources

Before you change any pipeline, read the Woodpecker documentation that governs the decisions in this migration. Start with the Woodpecker about page to confirm the project's license history and its position as the Drone 0.8 fork, which matters if your legal or procurement team asks who maintains the engine. Then read the forges overview, which confirms that Woodpecker supports Bitbucket and Bitbucket Datacenter with push, tag and pull request events. Note that the same page says connecting multiple forges to one server is still experimental, so a single-forge setup is the safer assumption for a first cutover.

For the translation work, the Woodpecker workflow syntax reference is the document your engineers will use most. It defines the container image each step runs in, the services containers, the when filters on event, branch and path, and matrix builds. Map each bitbucket-pipelines.yml step against those keys and record any Bitbucket-specific behavior that has no direct equivalent, such as pipes, which Woodpecker handles as plugin containers that may need adjustment. The Kubernetes backend page matters if you run agents on a cluster: it explains that each step runs in its own pod and that a temporary persistent volume claim, 10G and ReadWriteMany by default, shares files between steps. Confirm that your storage class supports that access mode before you plan the cutover.

On the Atlassian side, the variables and secrets documentation and the artifacts documentation define what you must capture before you disconnect. Secured variables can only be replaced or deleted, so the export plan is to record which values your team can regenerate and rotate them in Woodpecker. Artifacts expire after at most 14 days, so download anything you need for audit or rollback first. Treat both pages as the reference for your change record, and confirm current limits with Atlassian, since vendor documentation changes.

How DeployOpen scopes, runs and supports the migration

DeployOpen plans, implements, integrates, hardens, backs up, documents and supports self-hosted open-source platforms inside your own infrastructure. For a move from Bitbucket Pipelines to Woodpecker CI, we start from a written scope that keeps your repositories on Bitbucket while the builds run on agents you control.

How we scope

We inventory every bitbucket-pipelines.yml file, its steps, pipes, caches and deployment targets before any work begins.
Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
The written scope lists which secured variables must be re-entered by your owners, since Bitbucket cannot export their values.

How we build

We stand up the Woodpecker server and agents in your environment, connected to your Bitbucket or Bitbucket Datacenter instance.
We translate pipeline steps into Woodpecker workflows, replacing pipes with plugin or container steps and testing each one.
We configure artifact retention in your own storage and test the build, test and deploy path on non-production repositories first.

How we hand over

We document the pipeline layout, agent configuration, secret ownership and rollback steps for your platform team.
We deliver a runbook for exporting build artifacts and logs from Bitbucket before the Pipelines retention window closes.
We walk your engineers through adding a repository to Woodpecker and reviewing failed workflows.

How we support

Ongoing support, upgrades and continuous testing are available as retainers, including planned Woodpecker version upgrades.
We can help you confirm Bitbucket webhook and build status reporting after each change to the forge configuration.
Your team confirms current licensing, forge support and agent sizing with the vendors and in your own environment before cutover.

Migrate from Bitbucket Pipelines to Woodpecker CI