Does self-hosting Azure Pipelines alternatives cost less?
Self-hosting moves most of the cost from the vendor's meter to your own infrastructure, storage and staff, so the answer depends on build volume, how many pipelines you run, and who will operate the platform. Jenkins is distributed under the MIT License and Woodpecker CI under Apache-2.0, so neither carries a license fee. That makes the comparison a comparison of components: build agents, controller or server capacity, storage for artifacts and logs, backups, network egress, and the engineering time to run and upgrade the platform. Do not compare a per-parallel-job price with a server bill alone, because the server bill leaves out the people and the agents that do the work.
Start by counting what you pay Azure today in parallel jobs, Microsoft-hosted and self-hosted, and what you would pay for any Managed DevOps Pools or agent virtual machines. Then build a component list for each target: for Jenkins, controller hosting, agent compute (often Kubernetes pods), plugin maintenance and the Configuration as Code files that keep it reproducible; for Woodpecker CI, the server, agents, the database (SQLite by default, with PostgreSQL or MariaDB recommended for larger instances), and any autoscaler VMs. Ask your team which of these costs are one-time and which recur, and which grow with build volume. Plan for the people cost explicitly, since most of the recurring spend in a self-hosted CI platform is staff time for upgrades, security patching and incident response.
Do not assume self-hosting removes per-run charges everywhere. Commercial CI vendors have begun metering self-hosted runners: Atlassian announced a per-concurrent-build-slot charge for premium Bitbucket Pipelines runners from runner version 5, and GitHub announced a per-minute charge for self-hosted GitHub Actions runners before postponing it. Before you sign a new commitment with any vendor you keep as part of a hybrid setup, ask in writing whether self-hosted runners or agents carry any usage fee. For the reader's own estimate, request current pricing from Microsoft for the Azure Pipelines components you still use, and build a quote from your own written scope.
Which cost components move when you replace Azure Pipelines
This table compares each cost component of Azure Pipelines with its self-hosted counterpart in Jenkins or Woodpecker CI, and marks whether the cost is one-time or recurring. Read it as a checklist for a quote: the licence line drops out, but operating hours, agents, storage and migration effort move onto your budget. Ask each provider and your own team to price the rows that apply to your environment.
| Cost component | Azure Pipelines (commercial side) | Jenkins or Woodpecker CI (self-hosted side) | One-time or recurring |
|---|---|---|---|
| Subscription or license | Billed by parallel jobs under the Azure DevOps subscription; confirm current rates on Microsoft's pricing page | Jenkins is MIT-licensed and Woodpecker CI is Apache-2.0, so neither carries a license fee | Recurring for Azure; none for the open-source engines |
| Microsoft-hosted or self-hosted parallel jobs | Parallel jobs are metered; additional jobs add cost as teams and pipelines grow | No job metering; capacity comes from the build agents you provision and run | Recurring |
| Managed DevOps Pools and agent VMs | Managed pools and their VM capacity are billed by Azure; confirm the terms that apply to your organization | Agent VMs are your infrastructure in your cloud account or data center, sized for your peak build load | Recurring (compute and storage) |
| Controller or server hosting | Included in the Azure service; no server for your team to host | A Jenkins controller or Woodpecker server must run on VMs or Kubernetes, with backups of $JENKINS_HOME or the database | Recurring |
| Build agents | Agents are part of the paid service or pool; you do not patch the agent image | You build, patch and scale agents, using dedicated agents so the controller only manages the build environment | Recurring (labor and compute) |
| Storage for artifacts and logs | Retention is set in Azure DevOps; export history before leaving because run data does not transfer as-is | Storage is yours; plan retention for build logs and artifacts from the start | Recurring |
| Migration of YAML and secrets | Pipeline YAML already lives in your repositories; secret values cannot be exported and must be re-entered | Converting pipelines to Jenkinsfiles or Woodpecker YAML and recreating credentials is project work | One-time |
| Support, upgrades and internal skills | Vendor support is covered by the Azure agreement; upgrades happen in the service | Your team or a partner handles plugin upgrades, Java version changes and security patches | Recurring, with a large one-time learning curve |
What moves the comparison most for your organization
The cost gap between Azure Pipelines and self-hosted Jenkins or Woodpecker CI depends less on list rates than on how your builds, teams and people are arranged. Each driver below pushes specific cost lines up or down, so check them against your own environment before comparing totals.
Build volume and concurrency
Azure Pipelines bills for parallel jobs, so the number of builds that must run at the same time sets the subscription size. On the self-hosted side, concurrency is paid for through build agent capacity you provision and run yourself. Ask your team for peak concurrent jobs over a typical month, not the daily average, because peaks decide how many agents you need. Confirm current parallel job pricing and any self-hosted agent terms with Microsoft before you model the numbers.
Windows and .NET build needs
Windows and .NET builds often need dedicated agents with licensed tooling, which can inflate the agent VM line on either side. Jenkins and Woodpecker CI are strongest on Linux container builds, so a Windows-heavy estate may keep some workloads on Windows agents that you operate. Inventory which pipelines require Windows images, Visual Studio components or signing tools, and cost those agents separately from Linux container capacity.
Number of projects and teams
Team count affects whether one shared CI server is enough or whether you run several. The Jenkins scaling guide describes adding controllers for new teams or projects, which adds controller VMs, storage and upgrade effort for each one. A single Woodpecker server with shared agents can absorb more projects at lower overhead, but it puts more teams on one control plane. Count projects, owners and required isolation levels before choosing the layout.
Data volume and retention
Hosted services keep artifacts for limited periods, so the self-hosted side takes on storage for logs, artifacts and any history you need to keep for audit. Retention periods you set become storage line items that grow with build frequency and artifact size. Estimate artifact size per pipeline and decide how long each class must be kept, then price object or block storage against that policy. Export history from Azure Pipelines before its retention ends.
Availability requirements
Availability design drives the controller count and the cost of standby capacity. The Jenkins scaling guide describes a primary and backup controller arrangement behind a proxy such as HAProxy or F5 that routes traffic to the backup if the primary fails. Standby controllers, load balancers and failover testing add recurring infrastructure and operations time. Decide whether a CI outage blocks releases in your environment, and cost redundancy only to the level that answer requires.
In-house operating skills
The largest recurring line in a self-hosted comparison is often people, not servers. Operating Jenkins involves plugin upgrades, controller backups in $JENKINS_HOME and agent maintenance, while Woodpecker involves server, agent and autoscaler operations with a smaller plugin surface. Count the hours your platform or DevOps staff already spend on Azure Pipelines support, then estimate what self-hosted operation would add. Ask any implementation partner for a written scope that names who runs upgrades and on-call support after go-live.
Why migration cost includes secrets and build history
Migrating from Azure Pipelines is not a copy job for secrets. Secret variables in variable groups and the credentials behind service connections generally cannot be read back out of Azure DevOps, so every value your pipelines use for deployments, registries and cloud accounts has to be re-created in Jenkins or Woodpecker CI and, where possible, issued again by the system that owns it. Budget that as recurring engineering time per project rather than a line item in a tool export. Ask your team to inventory every variable group, secure file and service connection per project before any pipeline is rewritten, and to record which credentials are shared across pipelines, since those carry the widest blast radius if they are replaced late.
Hosted CI services hold these values for every connected project, which is why the rotation step belongs in the plan. In its January 4, 2023 incident report, CircleCI told customers to rotate secrets after an attacker exfiltrated environment variables, tokens and keys, along with the encryption keys needed to read them. That incident concerned CircleCI, not Azure Pipelines, but it shows the exposure a hosted CI control plane creates. Confirm with Microsoft and your own administrators what your Azure DevOps organization retains, including deleted pipeline runs, logs and audit records, and for how long, because no Azure retention period is supplied here. Those answers determine how much history you must export and how long old credentials stay live.
Build history and artifacts are a one-time export task, and the cost is mostly the time to script and verify it. Export YAML definitions from the repository, classic pipeline definitions through the REST API, run logs, and any published artifacts your release process depends on, then store them in storage you control with an agreed index. Set a cutoff date for what must be kept for audit or for rebuilding a release, and decide whether older runs are archived or dropped. Verify a sample of exports by re-reading them, because a log that cannot be opened later is not evidence. Keep this work separate from the recurring cost of running Jenkins or Woodpecker, so the migration budget does not hide an ongoing storage commitment.
How to build the comparison with your own numbers
This sequence turns the cost components into a side-by-side model built from your own pipeline usage, storage, infrastructure rates and staffing, so the comparison reflects your environment rather than generic assumptions.
Pull current parallel job and agent usage
The platform or DevOps administrator exports parallel job consumption and agent pool usage from Azure DevOps reporting for the last several months, including peak concurrency and the share of jobs that run on Microsoft-hosted agents versus self-hosted agents. Record the billing meter for each month so the figures match what Microsoft invoices. The step is complete when you have a monthly table of peak and average concurrent jobs for each agent type, with the source report named beside each figure.
Inventory pipelines, projects and build types
Working with the Azure DevOps project owners, list every pipeline, project and repository that triggers builds, and tag each one by language, runtime, whether it needs Windows, and whether it deploys. Include classic release pipelines and any pipeline that depends on a Microsoft-hosted image or a Managed DevOps Pool. The output is an inventory with build frequency per pipeline, which tells you how many Jenkins jobs or Woodpecker workflows you must rebuild and how much concurrency the new platform must absorb.
Size the Jenkins or Woodpecker platform
The platform engineering team sizes the target from the inventory. For Jenkins, that means one or more controllers, dedicated build agents sized to peak concurrency, and any primary and backup controller arrangement you require. For Woodpecker, it means one server, agents that run workflows on Docker or Kubernetes, an optional autoscaler, and a PostgreSQL or MariaDB database, since SQLite is the default and the project recommends a larger database for bigger instances. The output is a written architecture with node counts and CPU and memory per node, labeled as your own assumptions until a vendor or integrator confirms them.
Estimate storage for artifacts and logs
Using your own retention policy, the platform team estimates how much storage build logs, test results and artifacts will consume on the new platform. Start from average artifact size per build and the number of builds you expect to keep, then add headroom for the database and the Kubernetes persistent volume claim if you use the Woodpecker Kubernetes backend. Because hosted services keep artifacts for limited periods, decide how long you need to retain them independently of the vendor. The output is a storage estimate per year with the retention rule written next to it.
Price infrastructure at your own rates
Finance and cloud or data center teams price the sized architecture using your own compute, storage, backup and network rates, including reserved or committed discounts you already hold. Keep Microsoft-hosted parallel job spend and any Managed DevOps Pool spend as separate lines so each cost is traceable. Ask your cloud or hardware provider for current rates rather than using list prices from memory. The output is a monthly and annual infrastructure cost for the target platform next to the current Azure DevOps spend for the same workload.
Cost the one-time migration and secret rebuild
Estimate the one-time work of converting YAML definitions to Jenkinsfiles or Woodpecker workflows, rebuilding service connections and variable groups as credentials, and re-entering secrets whose values cannot be read back from Azure DevOps. Count each pipeline from the inventory and assign effort by complexity, with a separate line for security review and cutover testing. Confirm with your integrator whether their scope is fixed or time-and-materials, and ask for the written scope before comparing. The output is a one-time cost sheet with each assumption labeled.
Add recurring operations and upgrade hours
Estimate the recurring work of running the new platform: applying Jenkins LTS upgrades or Woodpecker releases, updating plugins or Woodpecker plugin images, patching the operating system and Java runtime, monitoring agents, and handling backups of $JENKINS_HOME or the Woodpecker database. Assign these hours to named internal staff or a retained support provider, and show the share of their time this platform takes. The output is a monthly operations hour estimate with the roles that perform it, which is usually the largest variable line in the model.
Compare totals over an agreed period
Build a single model that shows Azure Pipelines cost and the self-hosted cost side by side across one agreed period, with one-time costs spread over that period and recurring costs added monthly. Run a sensitivity check that changes concurrency, storage growth and operations hours, so you can see which assumption moves the result most. Share the model with the platform, security and finance owners and request quotes from written scope for any external work. The output is a comparison that states each assumption, its source and the owner who confirmed it.
Where Jenkins or Woodpecker CI changes the cost profile
Jenkins is distributed under the MIT License, so the software itself carries no per-job or per-agent fee. The recurring cost sits in the machines that run it and the people who keep them healthy. The Jenkins scaling guide recommends dedicated build agents so the controller only handles HTTP requests and manages the build environment, which means you pay for two kinds of compute from day one.
- Controller compute: one or more controller VMs or pods sized to your team count, plus storage for
$JENKINS_HOME, which holds all configuration, plugins and secrets. - Agent capacity: build agents you provision as static machines or Kubernetes pods. These costs recur for as long as the agents run, and your peak concurrent demand sets their size.
- Growth model: the scaling guide describes adding controllers for new teams or projects. Each extra controller multiplies backup, upgrade and monitoring work.
- High availability: a primary and backup controller behind a proxy such as HAProxy or F5 doubles the controller footprint and adds failover testing.
Ask your platform team or implementation partner to model controller count, peak agent demand and backup storage, then compare that model with your current Azure parallel job and agent spend.
The Jenkins homepage states that more than 2,300 community plugins connect Jenkins to the CI/CD toolchain. That breadth is useful, but most of the operating effort in a Jenkins estate is plugin lifecycle: testing upgrades, tracking changes to bundled components and keeping the Java runtime supported. Each of these tasks is recurring staff time, so it belongs in the cost model next to the infrastructure.
- Plugin upgrades: every plugin you depend on needs testing against the current LTS baseline before it moves to production.
- Bundled plugin changes: Jenkins LTS 2.580.1 stopped bundling several plugins, including the bouncycastle API, SSH server and JUnit plugins. Teams that rely on them must install them through the plugin manager and validate that step before the upgrade.
- Java runtime: the support policy lists Java 21 with planned end of support in September 2027 and Java 25 with planned end of support in September 2029. The final LTS release for Java 17 was 2.541.3 in March 2026.
- Configuration as Code: the plugin reads YAML from
CASC_JENKINS_CONFIG(default$JENKINS_HOME/jenkins.yaml) but does not install plugins, so the plugin list must come from Docker images or the Helm chart. - Release cadence: Jenkins picks a new LTS baseline every 12 weeks and ships three LTS releases per baseline in four-week cycles.
Count the plugins your current Azure Pipelines tasks depend on and the Java version your build images need before you estimate upkeep.
Woodpecker CI is licensed under Apache-2.0, and its installation has a smaller set of moving parts than a Jenkins estate. A server provides the UI and API, receives forge webhooks and parses pipeline YAML. Agents run the workflows and connect to the server over gRPC. The main cost decisions are the database you choose and where the agents run.
- Server: one server process handles the UI, API and webhook intake, so the control-plane footprint is small compared with a multi-controller Jenkins design.
- Database: SQLite is the default. The administration documentation recommends PostgreSQL or MariaDB for larger instances, which adds a database to size, back up and patch.
- Agent compute: agents run workflows on Docker, Kubernetes or the local machine, so agent compute is the main recurring line.
- Forge scope: the forge documentation lists GitHub, Gitea, Forgejo, GitLab, Bitbucket and Bitbucket Datacenter. Connecting multiple forges to one server is still experimental, so plan on one forge per server unless you test otherwise.
- Plugins as steps: plugins are container images configured in a settings block. The docs note that Drone plugins generally work but may need adjustments, which is engineering time to budget.
Confirm the expected database size, backup window and forge version against the current Woodpecker documentation before you size the server.
Woodpecker can keep idle capacity low. Its optional autoscaler creates cloud VMs for pending builds, and its Kubernetes backend runs each step in a standalone pod. Both options turn part of the agent bill into burst capacity, but they also add infrastructure to run. Fit matters as much as price: Windows-heavy builds may not suit a container-first engine, so confirm that before you model savings.
- Autoscaler: the component creates cloud VMs for pending builds. Confirm the supported providers, minimum settings and scale-down behavior in the documentation.
- Kubernetes backend: each step runs in its own pod, so compute bills against cluster capacity you may already operate.
- Shared volume: Woodpecker creates a temporary persistent volume claim per pipeline, 10G with ReadWriteMany by default. Storage cost grows with concurrent pipelines, and your storage class must support ReadWriteMany.
- Image pulls: each step pulls a container image, so registry traffic and storage in your region become recurring costs.
- Windows and .NET builds: if your Azure Pipelines workload depends on Windows agents, verify that Woodpecker covers those builds before you count the migration as a saving.
Request a cost model that separates steady agent capacity from burst capacity, and ask the vendor or partner to confirm Windows support for your build types.
Questions buyers ask before comparing Azure Pipelines costs
Is self-hosting Jenkins or Woodpecker CI cheaper than Azure Pipelines overall?
It can be cheaper in license fees, but the answer depends on the components you already run and the people who operate them. Jenkins is MIT-licensed and Woodpecker CI is Apache-2.0, so neither adds a per-parallel-job license. The costs that remain are the controller or server, build agents, storage for logs and artifacts, backups, and the engineering time to upgrade and secure the platform. Compare those components against your current Microsoft-hosted or self-hosted parallel job spend, Managed DevOps Pools or agent virtual machines, and the internal hours you already spend on Azure DevOps administration. Ask your team to model both sides with your real build volume rather than a generic per-minute rate.
How long does a migration from Azure Pipelines take, and what drives the timeline?
The timeline is set by the number of pipelines, the complexity of templates and variable groups, and how many classic release pipelines still need to be mapped. Service connections and secret variables must be re-created because their values cannot be read back from Azure DevOps, so the count of secrets and the number of teams that must supply them is a major driver. Build history, logs and artifacts should be exported before the cutover. Parallel running, where both systems build the same branches for a period, adds time but lowers risk. A fixed-scope written plan should state the pipeline inventory, the cutover approach and the acceptance tests, and it is the right document to compare against any quote.
What does the internal team need to run Jenkins or Woodpecker CI?
Your team needs people who can run a controller or server, manage agents, and handle identity, backups and network paths. For Jenkins, the scaling guide places all configuration, plugins and secrets in the controller's $JENKINS_HOME, so backup and restore discipline is essential. Jenkins Configuration as Code can define settings in YAML, but it does not install plugins, so plugin delivery must be handled through Docker images or the Helm chart. For Woodpecker, the server, agents and database (SQLite by default, with PostgreSQL or MariaDB recommended for larger instances) need an owner. Engineers also need working knowledge of Jenkinsfiles or Woodpecker YAML to migrate pipelines.
Can our own team migrate and operate the platform without outside help?
Many teams can, provided they have someone with Linux, container and CI administration experience and time allocated to the project. The harder parts are usually secret re-creation, pipeline translation for Windows or .NET builds, and building an upgrade routine. Outside help is most useful for fixed-scope work such as designing the architecture, translating a defined set of pipelines, hardening the installation, writing backup and restore procedures, and handing over runbooks. DeployOpen implements, customizes, integrates, hardens, backs up, upgrades and documents self-hosted platforms inside your own infrastructure, and most engagements are fixed-scope with agreed deliverables and timelines.
What recurring work follows a Jenkins or Woodpecker CI deployment?
The main recurring work is version maintenance. Jenkins publishes LTS releases in four-week cycles, with backported fixes only, and its LTS release line picks a new baseline every 12 weeks. For example, Jenkins LTS 2.580.1 was released on September 30, 2026, following 2.568.3 on September 2, 2026. Plan for Java support too: the Jenkins Java support policy lists Java 21 and Java 25 as supported, and the final LTS release for Java 17 was 2.541.3 in March 2026. Plugin maintenance is continuous, and LTS 2.580.1 stopped bundling several plugins, so administrators must install them. Woodpecker releases are less frequent but still need review, for example 3.19.0 on October 7, 2026, which fixed matrix environment variable injection and enforced agent labels on the server.
What should we ask for in a fixed-scope quote for this migration?
Ask for a written scope that lists the pipelines in scope, the target platform and version, and what is excluded, such as release pipelines or Windows agents. The quote should separate one-time work (architecture, pipeline translation, secret re-creation, migration testing, hardening, backup setup and documentation) from recurring work (upgrades, plugin or plugin-image maintenance, monitoring and support). Ask how artifacts, logs and run history will be exported, who supplies secrets, what the acceptance tests are, and what happens during a parallel run. Confirm which infrastructure you provide, such as Kubernetes or virtual machines, and whether any retainer covers upgrades after handover.
Does moving CI off Azure Pipelines carry security risk for our secrets?
It can reduce exposure to a hosted service, but it creates new responsibilities. Hosted CI services hold deployment secrets for every connected project, and CircleCI's January 4, 2023 incident report told all customers to rotate secrets after an attacker exfiltrated environment variables and the keys needed to read them. Moving to a self-hosted engine means you own the secret store, controller access, agent isolation and backups. Ask for a plan that covers credential rotation during cutover, least-privilege service accounts, network placement of the controller, and how backups of $JENKINS_HOME or the Woodpecker database are encrypted and access-controlled.
What to ask for when you compare quotes
Start with the written scope, because a quote is only comparable to another quote when both cover the same work. Ask the partner or internal team to list which Azure Pipelines features are in scope: YAML pipelines and their templates, classic release pipelines, service connections, variable groups, agent pools and any Azure Repos or Azure Boards links that the builds depend on. A quote that silently leaves out classic release pipelines or service connections will look cheaper and then return as change requests. Ask for the list of pipelines and projects by count and name, and ask which of them will be migrated, rewritten or retired.
Then settle who re-creates secrets and how history leaves Azure. Service connections and secret variables cannot be read back from Azure Pipelines, so someone must re-enter their values from the owning systems, and the quote should name that person or team and the approval step that goes with it. Ask how artifacts and run history will be exported before the Azure subscription or organization is shut down, which formats will be used, and whether logs and artifacts are kept for audit. Also confirm which upgrade and support hours are included after cutover, which environments are covered (build, test, staging and production), and whether Jenkins or Woodpecker CI plugin and agent upgrades are priced as recurring work. DeployOpen does not publish a price list. A quote follows from the written scope, so compare proposals against the same scope document.
How DeployOpen scopes a fixed-price CI migration
DeployOpen plans, implements, hardens, documents and supports self-hosted CI platforms inside your own cloud accounts, data centers or air-gapped networks. For Azure Pipelines cost vs self-hosted Jenkins and Woodpecker CI, each engagement starts with a written scope that separates the parts of your current spend that move from the parts that stay, so the comparison is tested against your own pipelines before any work begins.
How we scope
- Inventory parallel jobs, agent pools, Managed DevOps Pools and VM spend against the pipelines that drive them.
- Agree in writing which repositories, pipelines, service connections and variable groups are in and out of scope.
- Confirm the target engine, whether Jenkins or Woodpecker CI, and the forge it must connect to before estimating effort.
How we build
- Convert in-scope YAML pipelines into Jenkinsfiles or Woodpecker workflows, with agents sized to your real build load.
- Re-create secrets and credentials in the target store, since Azure secret values cannot be read back for export.
- Test builds, deployment paths and artifact retention against agreed acceptance checks before any cutover.
How we hand over
- Deliver runbooks for controller or server backup in $JENKINS_HOME or the Woodpecker database, agent rebuilds and upgrades.
- Document the cost model so your team can see which components are one-time and which recur each month.
- Export run history, logs and artifacts in a format agreed at scoping, so records survive the platform change.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Plan Jenkins LTS and Woodpecker release upgrades on a schedule your change board can approve.
- Ask for a quote built from the written scope; DeployOpen does not publish a price list.
