Azure Pipelines vs Woodpecker CI: when each option fits
Most teams reach this comparison because of a renewal, a parallel-job bill that keeps growing, or a data residency rule that requires build infrastructure to run inside the organization. The question is whether a lightweight, container-first engine can take over that work. Woodpecker CI fits Linux container builds on a forge other than Azure Repos, such as GitHub, Gitea, Forgejo, GitLab or Bitbucket, where each workflow step runs in a container image you specify. Azure Pipelines fits teams that stay on Azure Repos, use TFVC, depend on classic release pipelines, or need Windows and .NET builds with Microsoft-supplied tooling.
Woodpecker's model is simple to describe: a server that receives forge webhooks and parses YAML, and agents that run the workflows, which can execute on Docker, Kubernetes or the local machine. That simplicity is also its boundary. Confirm before committing that your forge is on the supported list in the Woodpecker forges documentation, that your builds need no Windows agents or MSBuild-specific task chains, and that any Azure DevOps extension you rely on has a container-based equivalent or a plugin in the Woodpecker plugin index. Also confirm that connecting several forges to one server is acceptable, since the project lists multi-forge support as experimental.
The decision turns on three questions: where the code lives, what the build needs from the operating system, and who will operate the server. If repositories stay in Azure Repos, a self-hosted engine has to reach them through a supported forge or you move the repositories as well. If builds need Windows, a Woodpecker-only plan will not cover them. If your platform team can own agents, upgrades and database backups, the operating burden is modest. If nobody owns that work, the cost of the in-house option grows quickly.
Which scenarios favor Woodpecker CI and which favor Azure Pipelines
This table compares how each tool fits common scenarios, from forge and repository location to Windows builds and data residency. Read each row for the better fit and the condition that changes the answer. The main takeaway is that Woodpecker suits Linux container pipelines beside a non-Azure forge, while Azure Pipelines stays stronger where Azure Repos, TFVC or Windows toolchains are central.
| Scenario | Better fit | Condition that decides it |
|---|---|---|
| Linux container builds on GitHub, Gitea, Forgejo, GitLab or Bitbucket | Woodpecker CI | Each step runs in a container image, and the forge is one Woodpecker supports with push, tag and pull request events. |
| Code hosted in Azure Repos | Azure Pipelines | Woodpecker does not list Azure Repos among its supported forges, so moving repositories or keeping Azure Pipelines is the practical choice. |
| Source in TFVC | Azure Pipelines | Woodpecker works with Git-based forges, so TFVC repositories would need migration to Git before Woodpecker could build them. |
| Windows or .NET build agents | Azure Pipelines | Woodpecker agents run on Docker, Kubernetes or the local machine, so Windows builds need a verified Windows execution path that you must test. |
| Kubernetes-based builds | Woodpecker CI | The Kubernetes backend runs each step in its own pod, but confirm pod permissions, storage class and volume claim sizing for your cluster. |
| Teams with a data residency requirement | Woodpecker CI | A self-hosted server keeps pipeline logs and secrets in your infrastructure, but the forge and any hosted plugins must also meet the same requirement. |
| Multiple forges connected to one Woodpecker server | Neither, pilot first | Connecting multiple forges to one server is still experimental in Woodpecker, so plan a single-forge deployment or a pilot before relying on it. |
How Woodpecker CI is built and where it runs
Woodpecker CI is split into three parts that you deploy and size separately: a server, one or more agents, and an optional autoscaler. The server provides the web UI and API, receives webhooks from your forge and parses the pipeline YAML. Agents run the workflows and connect back to the server over gRPC, so agents can sit in a different network zone from the server as long as they can reach it. The autoscaler creates cloud virtual machines when builds are waiting, which matters if your Azure Pipelines usage today depends on Microsoft-hosted agents picking up bursts of work. Confirm with your platform team which of these three parts they will run, where each lives, and how the gRPC connection is secured between them.
Agents execute each workflow on Docker, Kubernetes or the local machine. Docker and Kubernetes suit Linux container builds, where every step runs inside the image you name. The local backend is the option to examine closely for Windows or .NET work, because it runs commands directly on the host, which makes the build depend on whatever tools that machine already has. Woodpecker uses SQLite by default, which is adequate for a trial or a small team. For larger instances the project recommends PostgreSQL or MariaDB, so plan that database from the start, including backup and restore, rather than migrating later. Ask your DBA to size it against the number of pipelines and build history you expect to keep.
Woodpecker is licensed under Apache-2.0, and its documentation is under CC BY-SA 4.0. The project began in 2019 as a fork of Drone 0.8, after Drone changed from Apache 2.0 to a proprietary license, and it was renamed Woodpecker on August 27, 2019. Drone is now managed by Harness under the Polyform Small Business license, so a legal review of the two projects will show different terms. The current release at the time of writing is 3.19.0, released on October 7, 2026, which fixed an injection of matrix environment variables into the default clone step and enforces agent labels on the server. Pin a version, read the release notes before each upgrade, and confirm that your security team accepts the release cadence and support model for your environment.
Capability comparison: Azure Pipelines against Woodpecker CI
This table compares how Azure Pipelines and Woodpecker CI handle the capabilities that most often decide a migration, from forge integration to secrets. Read each row against your own repositories and build agents, and treat any gap as a question to confirm with the Woodpecker version you plan to run. Woodpecker covers container-based Linux pipelines on supported forges well, while Windows builds, Azure Repos and release management need a closer look before you commit.
| Capability | Azure Pipelines | Woodpecker CI |
|---|---|---|
| Source control integration | Azure Repos, GitHub, Bitbucket and other Git providers, plus TFVC | GitHub, Gitea, Forgejo, GitLab, Bitbucket and Bitbucket Datacenter. Azure Repos and TFVC are not forge targets |
| YAML pipeline structure | Azure YAML pipelines with stages, jobs, steps and templates | Workflow YAML in one .woodpecker.yaml file or a .woodpecker/ directory, with depends_on ordering |
| Container steps and matrix builds | Container jobs and matrix strategies are supported. Confirm the exact syntax for your agent type | Each step runs in a specified container image, with service containers and matrix builds |
| Conditional filters | Conditions on stages, jobs and steps, plus branch and path triggers | When filters on event, branch, path and other conditions. Confirm each filter you rely on |
| Plugins and extensions | Marketplace tasks and extensions for the Azure DevOps ecosystem | Plugins are container images in the plugin index. Drone plugins generally work but may need adjustments |
| Kubernetes execution | Kubernetes agents are available through self-hosted agent setups. Confirm the supported pool model | Kubernetes backend runs each step in its own pod with a shared temporary volume, 10G ReadWriteMany by default |
| Windows build support | Microsoft-hosted and self-hosted Windows agents for .NET and Windows toolchains | Agents run on Docker, Kubernetes or the local machine. Confirm Windows agent support before planning |
| Classic release pipelines and approvals | Classic release pipelines and environment approvals exist, though new organizations cannot create classic releases by default | No built-in release pipeline or approval gates in the core product. Plan deployment stages with another tool |
| Secrets handling | Secret variables and variable groups. Values cannot be read back, so they must be re-created on migration | Repository and organization secrets managed on the server. Confirm storage, scope and export options in your version |
Where your build data and secrets sit with each option
Moving CI is as much about where build data, secrets and logs live as about pipeline syntax. This section sets out how Azure Pipelines and a self-hosted Woodpecker CI differ on hosting, secret custody, artifact retention and access control, and what to check before you cut over.
Azure Pipelines hosting models
Azure Pipelines runs jobs on Microsoft-hosted agents or on self-hosted agents that you register into agent pools. Microsoft-hosted jobs run on infrastructure Microsoft operates, so build workspaces and logs live in the Azure DevOps service. Self-hosted agents keep the build workspace on machines you control, but the pipeline definitions, run history and logs still sit in the Azure DevOps service unless you use Azure DevOps Server on premises. Confirm which model each pipeline uses today before you map it to Woodpecker.
Woodpecker on your own servers
A Woodpecker installation has a server that serves the UI and API and receives forge webhooks, plus agents that run workflows over gRPC. Both components can sit in your network, and agents can run on Docker, Kubernetes or the local machine. Build containers, workspaces and the pipeline database then stay inside your own infrastructure. Check that the server database is on a backend your team can back up, since the default is SQLite and PostgreSQL or MariaDB is recommended for larger instances.
Secrets in your own store
Azure Pipelines stores secret variables and service connections in the Azure DevOps service, and their values cannot be read back after they are set. Woodpecker keeps secrets in its own configuration on your server, which you can back up and rotate under your own process. Hosted CI incidents, including one at CircleCI in January 2023 that required all customers to rotate secrets, are a reason to review where secrets live today. Decide which secret store is authoritative before migration, and plan to re-create values rather than expecting an export.
Artifact retention you set
Hosted CI services apply their own retention windows to build artifacts, so history can disappear on the vendor's schedule. With Woodpecker, artifact storage is the one you attach to the workflow, such as object storage or a file share, and the retention policy is set by your team. Before the cutover, export the artifacts and logs you must keep from Azure Pipelines, since Azure Pipelines retention is governed by the Azure DevOps service and not by your environment.
Audit and identity controls
Azure Pipelines uses Microsoft Entra ID and Azure DevOps permissions, so access reviews and sign-in logs come from the Microsoft identity stack. Woodpecker authenticates users through the connected forge and applies its own admin and repository permissions, so access reviews and audit trails move to your logging and identity tools. Map who can approve pipelines, read secrets and trigger deployments, and confirm that the audit events you need can be exported from Woodpecker before the move.
The forge stays where it is
Woodpecker connects to GitHub, GitLab, Gitea, Forgejo, Bitbucket and Bitbucket Datacenter, so you can move builds in-house without moving repositories. This matters most when repositories remain in Azure Repos, which Woodpecker does not list as a supported forge. If your code lives in Azure Repos, the repository and its branch policies stay in Azure, and you must decide how Woodpecker receives events for those repositories before you retire Azure Pipelines.
Operating effort by environment: a small team or a larger platform
A single-team Woodpecker server on one virtual machine uses the default SQLite database. One server process serves the UI, the API and forge webhooks, and agents run workflows on Docker or the local machine. Upkeep is small in scope but falls on the same person or group who runs the rest of the host, so the tasks need explicit owners before go-live.
- Plugin review: Each plugin is a container image called from a settings block in the pipeline. Review the plugin images your pipelines use, pin their tags, and retest after any change, since Drone plugins generally work in Woodpecker but may need adjustments.
- Agent image maintenance: Rebuild the base images your steps run in on a fixed schedule, patch the host operating system, and keep agent versions aligned with the server.
- Backups: Back up the SQLite database file together with the server configuration, and test a restore on a second machine before you rely on it.
- Upgrades: Read the release notes for each version before upgrading. Woodpecker 3.19.0, released October 7, 2026, fixed an injection of matrix environment variables into the default clone step and enforces agent labels on the server, so confirm that existing pipelines and agent labels still match.
- Monitoring: Watch disk space, the server process and agent connectivity. A disconnected agent usually shows first as builds that stay queued.
Before go-live, confirm that SQLite is sufficient for your expected build volume and that the backup and restore steps are written down and tested.
A multi-team instance usually runs Woodpecker on Kubernetes, installed with the Helm chart and backed by PostgreSQL or MariaDB, which the project recommends for larger instances. The Kubernetes backend runs each step in a standalone pod and creates a temporary persistent volume claim for the pipeline, 10G and ReadWriteMany by default, to share files between steps. Upkeep moves from the host to the cluster, the database and the storage layer, and it usually needs a platform team rather than a single maintainer.
- Database operations: Run PostgreSQL or MariaDB with tested backups and upgrades scheduled with the platform team. Confirm who owns that database service and who is paged when it fails.
- Storage for pipeline files: Check the default 10G size and the storage class against your largest repositories, because a claim is created for each pipeline run and carries the files shared between steps.
- Plugin and image governance: With several teams, set central rules for which plugin images and base images may run, pin versions, and review changes before they reach shared pipelines.
- Helm chart upgrades: Track chart and application versions together, test each upgrade in a non-production namespace, and keep values files in version control.
- Monitoring and access: Monitor the server, agent pods, queue length and volume usage. Decide how teams receive project access and who can change repository secrets.
Before go-live, confirm that your cluster's storage class supports ReadWriteMany, and ask your platform team how the chart stores database credentials.
Build capacity is the upkeep area that grows with demand, whichever installation you choose. Agents connect to the server over gRPC and run workflows, and the optional autoscaler can create cloud VMs for pending builds. Fixed agents are predictable but can sit idle, while autoscaled agents shift cost to cloud accounts and to the work of keeping their machine images current. Build capacity is owned by whoever pays for compute, which may differ from the team that runs the server.
- Agent sizing: Decide how many agents each environment needs for peak queues, and label agents by workload so that jobs land on suitable machines.
- Autoscaler configuration: If you use the autoscaler, review its cloud credentials, instance types, quotas and the image each new VM boots from, and keep those images patched.
- Image currency: Rebuild agent and VM images when toolchains change, and remove unused images so that old base layers do not persist in your registry.
- Capacity cost: Track idle compute and storage separately from the server cost, since agents and pipeline volumes are often the larger recurring line items.
- Failure handling: Define what happens when a cloud region or quota is unavailable, and who decides whether to queue builds or pause pipelines.
Before go-live, ask who owns the cloud account for autoscaled agents and how that cost is reported, so that capacity decisions are visible to the people who pay for them.
What you pay for: cost components on each side
Replacing Azure Pipelines moves money from a per-job subscription to infrastructure, storage and people that you own. The cards below separate what Azure Pipelines charges for from what a self-hosted Woodpecker CI setup consumes, and which costs are one-time and which recur.
Azure Pipelines parallel jobs
Microsoft-hosted and self-hosted parallel jobs are the metered unit on the Azure Pipelines side. Your bill grows with how many pipelines can run at once, so concurrency is the driver to measure before you size anything. Ask the vendor how each job tier is billed, which free grants apply to your organization, and whether self-hosted agents still consume a parallel job.
Self-hosted agent infrastructure
If you keep Azure Pipelines, agent machines or Managed DevOps Pools are an extra recurring cost you run yourself. Woodpecker agents can run workflows on Docker, Kubernetes or the local machine, so the same build capacity can move onto nodes you already operate. Estimate peak concurrent builds and the CPU and memory each step needs, then price those nodes as a recurring line.
Woodpecker server and autoscaling
A Woodpecker installation needs a server that serves the UI and API, receives forge webhooks and parses pipeline YAML. It is a recurring cost of compute and uptime, and it is usually small compared with build capacity. The optional autoscaler creates cloud VMs for pending builds, so its cost depends on how often builds queue and how long those VMs stay up.
Database and storage
Woodpecker uses SQLite by default, and the documentation recommends PostgreSQL or MariaDB for larger instances. Moving to a managed or self-run database adds a recurring cost plus backup work. On Kubernetes, each pipeline gets a temporary persistent volume claim, so the default size and access mode drive storage cost as pipeline count grows.
Build history and artifact retention
Azure Pipelines keeps run history and artifacts under its own retention settings, and those settings define how much you store. Before migrating, export logs and artifacts you must keep for audit, then decide how long they live on your storage. Longer retention is a recurring cost, so set it per artifact type and ask the vendor what exports are supported.
Migration and staff time
Migration is mostly one-time: converting pipeline YAML, re-creating secrets that cannot be read back, and rebuilding deployment steps. Operating the platform is recurring: patching, upgrades, plugin compatibility checks and on-call support. Staff time usually outweighs infrastructure cost, so ask any implementation partner for a written scope that separates one-time work from retainer support.
How a move from Azure Pipelines to Woodpecker CI proceeds
The sequence turns Azure Pipelines definitions, secrets and build history into Woodpecker workflows on a pilot repository, then retires the old agents once every repository has cut over. Each step ends with a check the team can verify before moving on.
Inventory pipelines, tasks, connections and variable groups
The platform owner and the team leads list every pipeline, its trigger, the repositories it reads and the Azure-specific tasks it calls. They also record each service connection, variable group and agent pool that the pipelines depend on. Anything that only works because of Azure, such as Windows-only tasks or Azure Artifacts feeds, is marked for a decision before any conversion starts. The output is a signed-off inventory where every pipeline has a named owner and a target, or a documented reason to stay on Azure for now.
Confirm where source repositories will live
Woodpecker reads repositories from a supported forge such as GitHub, Gitea, Forgejo, GitLab or Bitbucket, and it does not read Azure Repos directly. Teams with code in Azure Repos must first migrate those repositories to a supported forge, along with their branch protection and pull request settings. The platform owner checks each repository's new home and confirms that the forge's webhook and access settings allow Woodpecker to receive events. The check is complete when every pipeline in the inventory points at a repository Woodpecker can reach.
Export YAML, run history and logs before retirement
Azure Pipelines YAML already lives in the repository, so it is copied into the new home with its history intact. Classic pipeline definitions, which are not stored as YAML, are exported through the Azure DevOps REST API and kept as reference files. Run history, logs and any artifacts that matter for audit or support are archived separately, because the Azure retention windows will not carry them forward. The output is an archive folder per pipeline with a short index that a reviewer can open without access to Azure.
Re-create secrets and service connections in Woodpecker
Secret values in Azure Pipelines cannot be read back once they are stored, so the values must come from the system that owns each credential, such as a password vault, a cloud identity or the deployment target. The security owner recreates each secret in Woodpecker's secret store, scoped to the repositories and events that need it, and rotates any credential whose value was never documented. Each service connection is replaced by the credential it wrapped. The check is a test run per secret that shows the value reaches the step that uses it, with no value printed in logs.
Map build steps to container images
Each Azure Pipelines job is rewritten as a Woodpecker workflow where every step runs its commands inside a named container image. Tasks that install tools are replaced by images that already contain those tools, and Woodpecker plugins are used where a published image covers the job. Steps that depend on a Windows agent or on Azure-hosted tasks without a Linux equivalent are flagged and either rebuilt or kept on another runner. The output is a workflow file per repository and a list of exceptions that the engineering lead has accepted in writing.
Pilot the workflow on one repository
The team picks one low-risk repository that builds on Linux and runs the converted workflow alongside the existing Azure pipeline for a set period agreed by the team. Build outputs, test results and deployment effects are compared against the Azure runs, and any differences are logged and fixed in the workflow. The pilot is done when the team has reviewed the comparison and the platform owner has signed off that the converted pipeline produces the same artifacts and deployment results.
Cut over webhooks and retire the Azure pipeline
For each repository, the forge webhook is pointed at the Woodpecker server, the Azure pipeline trigger is disabled, and the first live build is watched by the owning team. Pipelines are moved in batches so that a problem affects one group at a time, with the rollback step documented before each batch. The Azure definition is kept read-only for the agreed retention period. The check is that every batch's builds run from Woodpecker and no Azure trigger remains active.
Retire Azure agents and close the migration
Once every repository has cut over, the self-hosted Azure agents and agent pools are drained and removed, and any Azure service connections and variable groups left unused are deleted. The platform owner updates the runbooks, access reviews and dependency inventory so they show Woodpecker and its agents as the only CI path. The migration closes when the inventory shows zero active Azure pipelines, the archive index is stored with the change records and the Woodpecker agents are documented as owned by a named team.
Questions buyers ask before switching from Azure Pipelines
What does it cost to switch from Azure Pipelines to Woodpecker CI?
The cost is mostly labor and infrastructure, not a license fee, because Woodpecker CI is licensed under Apache-2.0. Cost has four parts: the people who translate pipelines and operate the server and agents, the infrastructure that runs the server, database and agents, the migration of secrets and history, and the ongoing upkeep. Costs go up with the number of pipelines, the amount of Windows or .NET build work that Woodpecker does not cover, and the number of forges you connect. Ask for a quote that lists each component separately and states what recurs each year.
How long does a Woodpecker CI pilot take?
No duration has been established for this switch, so confirm it against a written scope rather than a generic estimate. The length of a pilot depends on how many pipelines you want to trial, how many use Azure Pipelines templates or service connections, whether builds need Windows agents, and how quickly your team can review results. A narrow pilot on Linux container builds typically takes less time than a pilot that includes deployment stages. Ask the provider to show which pipelines are in the pilot and what success criteria they use.
Can our internal team migrate to Woodpecker CI without outside help?
Yes, many teams can, provided they have people who know Linux, containers, YAML pipelines and their forge's webhooks. Woodpecker workflows are YAML files where each step runs in a container image, so the work centers on container images, plugin settings, secrets, and the server and agent setup. Plan for skills in Docker or Kubernetes, PostgreSQL or MariaDB administration for larger instances, and reverse proxy and TLS configuration. An outside partner can take on scope such as hardening, backup and documentation under a written agreement.
Do we have to move Azure Repos to use Woodpecker CI?
No. Woodpecker connects to GitHub, Gitea, Forgejo, GitLab, Bitbucket and Bitbucket Datacenter, so builds can move in-house without moving repositories. Azure Repos is not on that list, so Woodpecker cannot trigger builds from Azure Repos events in its current forge set. If your code lives in Azure Repos, you either keep Azure Pipelines for those builds, mirror repositories to a supported forge, or move the repositories as part of the migration. Confirm the mirroring or repository move with your team before you commit to a plan.
How are classic release pipelines and approvals handled in Woodpecker CI?
Classic release pipelines, task groups and deployment groups do not map one-to-one to Woodpecker workflows. Woodpecker expresses deployment as YAML steps with when filters for branches, events and paths, so stages and conditions can be rebuilt, but manual approvals and environment-level gates need a separate design. Confirm how your deployment targets are reached and which approval steps must remain. For Kubernetes targets, teams often pair CI with a GitOps tool, while non-Kubernetes targets may need custom steps. Document each approval gate in the scope before work starts.
What happens to run history, logs and artifacts during the switch?
Azure Pipelines run history, logs and artifacts do not automatically move to Woodpecker CI. Export what you need before you turn off Azure Pipelines, including YAML definitions already in the repository, run logs and published artifacts that auditors or teams still need. Woodpecker keeps its own history on the server it runs on, so plan where that data is stored and how long it is retained. Secret variables cannot be read back from Azure Pipelines, so they must be re-created in Woodpecker and rotated where needed.
Can Woodpecker CI run Windows builds for our .NET workloads?
Woodpecker is container-first. Its agents run workflows on Docker, Kubernetes or the local machine, and each step runs inside a container image, so Linux container builds are its strong fit. Windows-heavy builds, Windows-specific tooling and TFVC are not covered by this model. Confirm with the Woodpecker documentation and your own environment whether a Windows agent setup meets your needs. If your .NET or Windows builds depend on Windows agents, consider keeping those builds on Azure Pipelines or comparing Jenkins for them.
Questions to settle before you commit to a move
Settle where the source code lives before anything else, because it decides whether Woodpecker CI can run your builds at all. Woodpecker connects to GitHub, GitLab, Gitea, Forgejo, Bitbucket and Bitbucket Datacenter, and the forge documentation does not list Azure Repos or TFVC. If your repositories sit in Azure Repos, moving CI alone is not a like-for-like change, and the move becomes a repository migration as well. Also confirm whether the builds need Windows agents or .NET tooling, since Woodpecker's agents run workflows on Docker, Kubernetes or the local machine and each step runs in a container image. Windows-heavy build chains need a container or agent design that someone has tested, not one assumed from a Linux pipeline.
Next, count the pipelines that depend on Azure-only tasks, service connections and variable groups. Each Azure task has to be replaced by a container image plugin, a script step or a credential store entry, and Woodpecker plugins are container images configured through a settings block that may need adjustment. Ask who owns CI operations after cutover: the server, agents, database (SQLite by default, with PostgreSQL or MariaDB recommended for larger instances), upgrades and the autoscaler, if you use one. Name those owners in writing. If no team can take them, the saving from dropping parallel-job billing may not cover the operating work.
Finally, document the data residency and audit obligations that apply to build logs, artifacts, secrets and deployment records. Hosted and self-hosted CI handle these differently, and the answer should come from your compliance and legal owners, not from the engineering team. Confirm where build logs and artifacts will be stored and how long they are retained, because the migration must export history from Azure Pipelines before the old retention window closes. Plan the secrets as a separate task, since Azure Pipelines secret variables cannot be read back and must be re-created in the new system. A hybrid setup is often the lowest-change path: if your code already lives on GitHub, GitLab, Gitea, Forgejo or Bitbucket, Woodpecker can read those repositories while the rest of the estate stays put. That holds only if the forge is already in use and the audit and residency checks pass.
How DeployOpen helps evaluate, implement or migrate
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure. For Azure Pipelines vs Woodpecker CI, that means first checking which of your repositories, runners and Windows build steps Woodpecker can serve, then building only what the decision needs. Engagements are fixed-scope, with scope and deliverables agreed in writing before work starts.
How we scope
- Inventory which pipelines build Linux containers and which depend on Windows, .NET Framework or Azure Repos features.
- Confirm the forge that will host Woodpecker, such as GitHub, Gitea, Forgejo, GitLab or Bitbucket, and whether multi-forge support is needed.
- Agree in writing the pipelines, deployment targets, secrets handling and build history that fall within the engagement.
How we build
- Set up the Woodpecker server, agents and database in your environment, with PostgreSQL or MariaDB sized to your instance.
- Convert in-scope YAML pipelines to Woodpecker workflows, and test each plugin or step image against your own builds.
- Re-create secrets in the new engine by hand, since stored values in the source CI service generally cannot be exported.
How we hand over
- Deliver written runbooks covering installation, agent scaling, backups, upgrades and the pipelines that stayed on Azure Pipelines.
- Document the secret inventory, access model and build artifact retention so your auditors and security team can review them.
- Walk your platform and security engineers through operating the Woodpecker server and agents before the handover is closed.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after handover, scoped separately from the build.
- Track Woodpecker releases and plan upgrades around the version notes, including security-relevant fixes, with your change process.
- Run security testing of the pipeline and its runners on request, so build infrastructure is checked as part of normal operations.
