GitHub Actions cost vs self-hosted Woodpecker CI and Jenkins

When does self-hosted CI cost less than GitHub Actions?

Self-hosted CI costs less than GitHub Actions only when the hosted minutes you would otherwise pay for outweigh what it takes to run the engine yourself, and for most teams that comparison turns on build volume and on who will operate the system. Woodpecker CI and Jenkins are free to license, so the hosted per-minute fees and the 2026 price cut are the lines to compare, but the self-hosted side carries servers, storage, upgrades, support and staff time that never appear on a usage report. Start your renewal review by pulling the last twelve months of GitHub Actions usage per repository, including hosted minutes, storage and any Copilot review minutes, and mark which workloads are heavy and steady and which are occasional.

GitHub's announced $0.002 per minute charge for self-hosted runners was postponed, not withdrawn, so it belongs in your risk plan. If your builds already run on self-hosted runners, ask your GitHub account team in writing whether any per-minute metering could return and on what notice. The same question applies to Bitbucket and Atlassian's per-slot pricing for self-hosted runners, which shows that vendors have moved to meter self-hosted capacity. A self-hosted engine removes that exposure for the CI layer, but it does not remove the cost of the build machines, which you already pay for in either model.

Price the self-hosted side by component: the controller or server, the build agents or Kubernetes capacity, database and backup, the time spent on upgrades (Jenkins LTS releases arrive on a fixed cadence and may require plugin installs), on-call coverage and the commercial support contract if you buy one. Costs drop when builds are steady and high in volume and when platform staff already run Kubernetes. They rise with bursty workloads, many plugins, air-gapped requirements or a small team with no one who owns the CI platform. Ask any vendor or partner for a written quote that states the number of agents, storage retention, upgrade responsibility and support hours so the figures can be compared with your renewal.

Which cost components change between GitHub Actions and self-hosted CI

This table sets each cost component of GitHub Actions against the same component when Woodpecker CI or Jenkins runs on your own servers. Read the one-time or recurring column first, because self-hosted costs mostly recur through staff time, upgrades and infrastructure rather than licenses. Confirm current GitHub rates on GitHub's pricing page before you budget.

Cost component	GitHub Actions	Self-hosted Woodpecker CI or Jenkins	One-time or recurring
Hosted minutes	Billed per minute of GitHub-hosted runner time; confirm current rates in GitHub's 2026 pricing changes	Not applicable; build capacity comes from your own servers or VMs	Recurring
Self-hosted runner fees	Runners are free today, but GitHub announced a $0.002 per minute charge before postponing it	No per-minute fee; Woodpecker is Apache-2.0 and Jenkins is MIT	Recurring if a runner fee returns
Storage and artifact retention	Artifacts kept 90 days by default, so long-term copies need export	Storage on your disks or object store, with retention you set	Recurring
Copilot review minutes	Confirm with GitHub whether Copilot review uses Actions minutes and how it is priced	No direct equivalent; any AI review tool is billed by its own vendor	Recurring
License	Subscription tied to your GitHub plan; confirm tiers and seat counts	No engine license fee; review Woodpecker (Apache-2.0) and Jenkins (MIT) terms once	One-time review
Compute and runners	Hosted runner compute is included in billed minutes	VMs, Kubernetes nodes or agents you size and pay for, with optional autoscaling	Recurring
Controller, server and database	Nothing to run or back up	Woodpecker server with SQLite by default, or PostgreSQL or MariaDB for larger instances; Jenkins controller and $JENKINS_HOME backups	One-time setup, recurring operation
Upgrades, plugins and support	Maintained by GitHub; support tiers depend on your plan	Jenkins LTS upgrades, plugin updates and manual installs for unbundled plugins; Woodpecker releases; support by staff or retainer	Recurring
Implementation, migration and skills	Migration means rewriting workflows and re-creating secrets GitHub never exports	Pipeline rewrite, secret re-creation and staff who operate the platform long term	One-time migration, recurring skills

What moves the cost comparison most

Six drivers decide whether self-hosting costs less than GitHub Actions for a given team. Each one moves a different line in the total: metered minutes, controller count, storage, standby capacity, support terms and staff time. Work through them in order and write down the figures for your own environment before you compare quotes.

Build minutes and concurrency

Hosted minutes are billed per run, so cost rises with how many jobs run in parallel and how long each one takes. Self-hosted runners carry no minute charge today, but GitHub announced a $0.002 per minute charge for them before postponing it, so the meter could return. Woodpecker agents and Jenkins build agents cost the compute you provision and pay for, and an autoscaler adds cloud VMs only when builds queue. Ask for your peak concurrent job count and average run length.

Repository and team count

Cost grows with the number of repositories, pipelines and teams that trigger builds, and with the number of CI servers you run to keep them apart. Woodpecker can serve many repositories from one server, although connecting multiple forges to one server is still experimental. Jenkins usually grows by adding controllers for new teams or projects, and each controller adds its own upgrades, backups and plugin management. Map repositories to teams and count the controllers before you size the servers.

Artifact and log retention

GitHub Actions keeps artifacts for 90 days by default, and the retention you choose sets how much storage you run. With self-hosting, retention is your decision, so storage becomes a recurring line item, along with backup copies and any legal hold requirements. Object storage for artifacts and database growth for logs both continue every month. Set retention per artifact class, such as release bundles and test reports, and ask compliance how long build evidence must exist.

Availability and failover

A single controller is the cheapest option until it fails, and then it becomes the outage for every pipeline. Jenkins' scaling guide describes a primary and backup controller with a proxy such as HAProxy or F5 that routes traffic to the backup, which means a second server, replicated configuration and a tested failover procedure. Woodpecker uses SQLite by default, and PostgreSQL or MariaDB is recommended for larger instances. Standby capacity is a recurring cost, so define acceptable downtime for release pipelines before you price it.

Edition and support needs

Woodpecker, Jenkins and Gitea are open source under Apache-2.0, MIT and MIT licenses, so the main spend is support and operations, not licensing. Commercial support is optional, and each vendor sets its own terms. Gitea Enterprise from CommitGo, Inc. adds SAML 2.0, audit logging and mandatory two-factor authentication, which matter when auditors ask about access. Support response terms belong in the written quote, whether they come from a vendor or from a DeployOpen retainer.

Skills already on the team

Staff time is often the largest recurring cost, and it depends on what your engineers already know. Jenkinsfile pipelines are code in Declarative or Scripted syntax, and the LTS line brings regular controller and plugin upgrades. Jenkins LTS 2.580.1 stopped bundling several plugins, including the SSH server and JUnit plugins, so administrators must install them separately. Woodpecker uses YAML steps that run in container images, so teams already working with Docker or Kubernetes need less new tooling. Count the hours already spent on pipeline and upgrade work before you compare.

Why a free self-hosted runner today is not a guarantee tomorrow

A self-hosted runner costs nothing to license on GitHub today, but the pricing of self-hosted runners has already moved once. GitHub announced a charge of $0.002 per minute for self-hosted GitHub Actions runners and then postponed it, so the cost of your own runners depends on a vendor decision you do not control. Atlassian has moved in the same direction: from runner version 5, premium Bitbucket Pipelines runners cost $15 per month per concurrent build slot. Neither change required you to move a repository. Metering can be added to a platform you already depend on, which makes the price of your current setup a moving target.

The safer model prices the self-hosted option on compute and staff alone. List the build VMs or Kubernetes nodes, storage for logs and artifacts, the Woodpecker server or Jenkins controller, backup, upgrades and the engineering hours to run them. Keep the engine licenses in the model as stated terms, not as a cost line: Woodpecker CI is licensed under Apache-2.0 and Jenkins under the MIT License, so neither engine carries a per-minute meter. Check each plugin and commercial distribution separately, because a paid add-on, such as a commercial Jenkins distribution, can carry its own terms. Price the GitHub-hosted option in the same table so both sides use the same time period and the same workload.

Ask GitHub for its current terms on self-hosted runners in writing before you sign or renew. Confirm whether any per-minute or platform fee applies to runners you host, whether the postponed charge is still pending, how the terms differ between GitHub.com and GitHub Enterprise Server, and how much notice you receive before a change takes effect. Record the answers with the date you received them, and review them at each renewal. Then set a trigger in your own plan, such as a written change to runner pricing, that reopens the cost comparison. The GitHub pricing changes page is the starting point for that review, but the written answer from your account team is the document to file.

How to build the comparison with your own numbers

This sequence turns GitHub Actions invoices and run history into a per-year cost view that sets your hosted minutes against the servers, maintenance and staff time of a self-hosted Woodpecker CI or Jenkins setup.

Export the pipeline inventory from GitHub
Platform or DevOps engineers pull three to six months of workflow run history through the GitHub REST API or GitHub CLI before retention expires, recording run counts, billed minutes per runner type, artifact sizes and the number of repository and organization secrets. Use the exported run data rather than memory, because artifacts expire on the retention period set in your repository settings. The step is done when you have a spreadsheet with one row per repository and month, and each row shows minutes, runner type and artifact volume. Confirm the retention periods that apply to your own organization before you rely on any figure.
Size peak concurrency from run timestamps
Engineers use the run start and end times from the export to find how many jobs ran at the same time at busiest hours, not the monthly average. This peak sets how many build agents or executors you must provision, and it drives the cost of the self-hosted side more than total minutes do. Record the peak per week and note any release windows that spike it. The step is complete when you have one peak-concurrency figure per month and a list of the jobs that need Linux, Windows or macOS capacity.
Price hosted minutes from your own invoice
Finance and the platform lead compare the billed GitHub Actions minutes and storage on your invoices with the runner type each minute was billed for, because hosted rates differ by runner and the rates can change. Use the current pricing shown on your invoice or on GitHub's pricing changes announcement, and note whether self-hosted runner minutes are charged in your account at the time you run the model. The output is a per-year hosted cost line that includes Actions minutes, storage and any Copilot review minutes you pay for separately. Ask your GitHub account contact to confirm the rates that apply to your plan.
Cost the Woodpecker or Jenkins servers
The infrastructure owner prices the controller or Woodpecker server, the agents sized to the peak from step two, and the database, which Woodpecker recommends moving from SQLite to PostgreSQL or MariaDB for larger instances and Jenkins expects to hold its backed-up $JENKINS_HOME. Use your own cloud or data center rates, include storage for artifacts and backups, and add a second controller if you need a primary and backup arrangement. The step is done when each server, agent pool and database has a monthly and annual cost, with the autoscaler cost listed separately if you plan to use one.
Add upgrade and plugin maintenance hours
Platform engineers estimate the recurring hours for applying Jenkins LTS releases, reviewing plugin updates, testing Java runtime support changes and, for Woodpecker, upgrading the server, agents and any plugin images. Record these as hours per quarter from your own team's experience, since no benchmark figure is supplied here, and include the Jenkins plugins that a release may stop bundling. Multiply the hours by an internal loaded rate. The output is an annual maintenance line that you can compare directly with the hosted minutes from step three.
Add support and staff time
Engineering managers add the support model you choose, whether that is in-house on-call time, a vendor support contract for an open-source distribution, or a retainer with an implementation partner, and the staff time to convert workflows, rebuild plugin chains and answer developer tickets. Ask any partner for a fixed-scope written quote, and note which parts are one-time and which recur. The step is complete when the one-time migration effort and the recurring support line sit in separate rows.
Add the migration line item for secrets and artifacts
Security and platform leads add a dedicated line for work that cannot be automated, because GitHub's REST API returns Actions secret names without their values, so each secret must be re-entered from its source system, and artifacts and run history must be exported before they expire. Estimate the number of secrets from the count in step one and the hours needed to re-create and verify each one, then add a rotation step if any credential may have been exposed. This line is one-time, and its size depends on how many secrets and artifacts you hold.
Run a side-by-side per-year comparison
Finance and the platform lead place the hosted cost from steps three and six next to the self-hosted costs from steps four, five and seven in one table, with a year-one column that includes migration and a steady-state column that excludes it. Run the model for the current hosted rates and again for a higher-rate scenario, and label any scenario as illustrative. The check that closes the sequence is a signed comparison that names every assumption, the peak concurrency used, and the people who own each recurring line.

Woodpecker CI or Jenkins: which costs more to run

Woodpecker runs as a server plus agents. The server provides the UI and API, receives forge webhooks and parses pipeline YAML, while agents run workflows and connect to the server over gRPC. Agents can run steps on Docker, Kubernetes or the local machine, and an optional autoscaler can create cloud VMs for pending builds. The Apache-2.0 engine has no license fee, so the recurring cost sits in machines, the database and the people who operate them. The Woodpecker administration documentation covers the server and agent layout in detail.

Server and database: Woodpecker uses SQLite by default. The documentation recommends PostgreSQL or MariaDB for larger instances, which adds a database service to back up and patch.
Agents on Docker or Kubernetes: On Kubernetes, each step runs in its own pod and a temporary persistent volume claim (10G and ReadWriteMany by default) shares files between steps, so your storage class and cluster capacity drive the bill.
Plugin upkeep: Plugins are container images configured through settings blocks. The docs say Drone plugins generally work but may need adjustments, so budget time for the plugins your pipelines use.
Helm chart: A Helm chart installation is documented, which reduces hand-written manifests but still needs a platform team that operates Kubernetes.

Before quoting, confirm the database size, the storage class for shared volumes and which plugins your current workflows depend on.

Jenkins runs as a controller that serves the UI and schedules work, with build agents that execute the builds. The Jenkins scaling guide recommends dedicated agents so the controller only handles HTTP requests and manages the build environment. Jenkins is MIT licensed and offers more than 2,300 community plugins, so the recurring cost is controller and agent capacity, plugin maintenance and upgrade effort.

Controller and agents: Dedicated agents keep build load off the controller. Agent count and size follow your pipeline concurrency, which you should measure in your own environment.
Backups of $JENKINS_HOME: Configuration, plugins and secrets all live in $JENKINS_HOME on the controller, so backing up and restoring that directory is the core recurring task. Configuration as Code can read settings from jenkins.yaml, but it does not install plugins.
LTS cadence: A new LTS baseline is picked about every 12 weeks, with three LTS releases per baseline in four-week cycles. LTS 2.580.1 was released on September 30, 2026, so plan a recurring upgrade window. Check the Jenkins LTS changelog before each cycle.
Plugins no longer bundled: LTS 2.580.1 stopped bundling several plugins, including the bouncycastle API, SSH server and JUnit plugins. Administrators who rely on them must install them through the plugin manager.
Java support and high availability: Java 21 has a planned end of support in September 2027 and Java 25 in September 2029. For high availability, the scaling guide describes a primary and backup controller behind a proxy such as HAProxy or F5.

Before quoting, confirm the Java version on each controller and agent, the plugin inventory against the LTS changelog and who runs the restore tests.

Costs teams forget on each side

Moving from GitHub Actions to self-hosted Woodpecker CI or Jenkins changes where cost lands, not only how much it is. The items below are the ones that rarely appear in a first estimate, and most of them are one-time migration work or recurring operating duties that a quote should name explicitly.

Build history export before retention ends

GitHub Actions keeps run logs and artifacts for a limited period, and the default is 90 days. Anything you need for audit, incident review or rollback history has to be pulled out through the API or CLI before it expires, and that export is planned effort the first time you do it. Ask your provider to scope the export as a deliverable, including how long archived logs must be kept and where they are stored.

Secrets that must be re-created

GitHub's REST API returns secret names but never their values, so deployment keys, registry tokens and signing credentials cannot be copied out automatically. Each one has to be reissued or re-entered in the new CI system, and the owners of those credentials must approve the rotation. Treat this as a dependency list to build with your security team, not a one-line task in the migration plan.

Workflow and action rewrites

Marketplace actions do not run unchanged on Woodpecker, which uses container-based steps and plugins instead. Each uses: reference becomes a plugin block, a shell command in a container image, or a custom image you build and maintain. Count the distinct actions your workflows call, because that list, not the number of repositories, sets the rewrite effort and the test cycle.

Woodpecker plugin adjustments

Woodpecker's documentation says Drone plugins generally work but may need some adjustments. Plugins that depend on Drone-specific settings or on environment behavior should be tested one by one, and you should confirm which plugins your pipelines use against the plugin index before committing to a timeline. Budget test runs for each plugin you adopt, and record the image tags you pin so upgrades are deliberate.

Kubernetes volumes for shared pipeline files

On Kubernetes, Woodpecker runs each step in its own pod and creates a temporary persistent volume claim to pass files between steps. The default claim is 10G with ReadWriteMany access, so your storage class must support that access mode and the capacity must fit your largest builds. Check quotas, storage cost and cleanup behavior with your platform team before sizing the cluster.

Jenkins upgrades and on-call coverage

Jenkins moves to a new LTS baseline every 12 weeks, and some plugins stop being bundled, so plugin installs and controller upgrades become recurring maintenance. Someone must also be on call when builds fail at night, when agents run out of disk, or when the controller goes down. Ask any quote to cover the upgrade calendar, the plugin inventory, and who responds outside business hours, since these costs recur every year.

When a full Gitea forge changes the math

A Gitea forge changes the cost comparison because it replaces more than the CI engine. Gitea is MIT licensed and combines Git hosting, code review, package management and CI/CD in one self-hosted service, with Gitea Actions as its built-in CI. If you only price Woodpecker CI or Jenkins against GitHub Actions minutes, you leave out the cost of moving repositories, pull requests, issues and the registries that GitHub currently supplies. Model the forge as its own project with its own line items, not as a side effect of the CI decision.

Two lines should be modeled separately from the server and storage costs: repository migration and user accounts. Repository migration covers the transfer of Git history, issues, pull requests and releases, plus the re-creation of CI secrets, which GitHub never exports. User account work covers mapping every developer, bot and service identity to a Gitea account, deciding how single sign-on will be wired and reviewing team and organization permissions. Ask any implementation partner to quote these as distinct items with named owners, because they recur as a one-time effort only if the repository count and identity model stay stable.

If you want paid support, Gitea offers two routes. Gitea Enterprise, sold by CommitGo, Inc., adds SAML 2.0 service provider support, audit logging, IP allowlisting and mandatory two-factor authentication, among other features. Gitea Cloud is a managed alternative to self-hosting. Before you choose, confirm the current Gitea release line you plan to run. The documented lines are v28.0.0, released September 29, 2026, and v28.1.0, released October 6, 2026, so check which one your upgrade plan targets and what each upgrade requires from your team.

Frequently asked questions about CI cost and effort

How much does self-hosting Woodpecker CI or Jenkins cost?

The software license is not the main cost. Both Woodpecker CI (Apache-2.0) and Jenkins (MIT) are free to run, so the bill is made of infrastructure, people and support. Infrastructure covers the controller or server, the agents or build nodes, storage for logs and artifacts, and database hosting. People cover the time to install, configure, secure, back up and upgrade the system. The main drivers are how many builds run in parallel, how long builds take, how many projects and teams share the system, and whether you need high availability. Ask any quote to split one-time setup from recurring operations, and to show the assumptions behind each line.

Can our team run Woodpecker or Jenkins ourselves, and what skills do they need?

Yes, many teams run them in-house, but the work needs more than a single admin. Woodpecker needs someone comfortable with containers, Kubernetes or Docker agents, a SQL database such as PostgreSQL or MariaDB for larger instances, and the OAuth setup for your forge. Jenkins needs skills in Java-based server administration, plugin management, Jenkinsfile pipelines and agent configuration. Both need backup discipline, since Jenkins keeps its configuration, plugins and secrets in $JENKINS_HOME on the controller. Check whether your platform team already covers these skills and who is on call for failed builds.

How long does a CI migration take, and what drives the timeline?

The timeline depends on the number of pipelines, how much each one relies on vendor-specific features, and how many secrets must be re-created by hand. Pipelines built from plain shell commands and container images move faster than those using marketplace actions or orbs, which need replacement plugins or steps. Other drivers include the number of forges and repositories involved, how much build history you must export before retention expires, and how the new system is tested beside the old one. Ask for a timeline in the written scope, broken into inventory, pilot pipelines, cutover and decommissioning.

What do we need to provide for a CI engagement?

The work needs access and decisions from your side. Expect to provide a list of repositories and pipelines in scope, read access to existing CI configuration, the target infrastructure and cloud accounts, and named owners who can approve changes to build and deployment paths. You will also need to identify which secrets are used, since GitHub does not return secret values through its API and each one must be re-entered in the new system. Clarify who signs off on security controls, how access to the CI server is granted, and which compliance evidence you need to keep.

Does GitHub still host our repositories if we use Woodpecker CI?

Yes. Woodpecker CI can connect to GitHub as a forge, so repositories, pull requests and code review can stay on GitHub while builds run on infrastructure you control. Woodpecker's forge documentation lists GitHub among the supported forges with push, tag and pull request events. Confirm the exact webhook, OAuth app and network path your security team requires, and note that the documentation says connecting multiple forges to one server is still experimental. Your repository hosting costs under GitHub stay as they are, so this option changes only the CI portion of the bill.

What happens to our secrets and build artifacts during a move?

Secrets and artifacts generally need to be handled manually, so plan for them early. GitHub's REST API returns Actions secret names without their values, so each secret must be re-created in the new system from its source. Hosted CI also keeps artifacts for limited periods: GitHub Actions defaults to 90 days, so run history and artifacts you need should be exported before retention expires. Rotate credentials that were stored in the old platform, and confirm with your security team which secrets to rotate rather than copy. Ask the provider how the new system protects stored secrets and who can read them.

How often do upgrades happen, and who carries the work?

Upgrades recur for the life of the system, and the cadence depends on the project. Jenkins picks a new LTS baseline every 12 weeks, then ships three LTS releases for that baseline in four-week cycles, and plugin and Java support changes can require action between them. Woodpecker publishes regular releases, so track the release notes and test agents and plugins in staging before rolling out. Whoever runs the system owns these upgrades, so your quote should show who applies security fixes, who tests plugin compatibility and what a retainer for ongoing upgrades would cover.

What should a CI cost comparison include beyond the vendor invoice?

A fair comparison counts every component, not just the vendor line. On the hosted side, include minutes or credits, storage for logs and artifacts, any metered self-hosted runner charges, and add-ons such as code review minutes. On the self-hosted side, include servers or Kubernetes capacity, storage, database, load balancing, backups, monitoring, upgrades, support contracts and staff time. The GitHub announcements of a per-minute charge for self-hosted runners, later postponed, show why runner pricing can change, so model that risk. Ask any provider to put its assumptions in writing.

How DeployOpen scopes a fixed-price CI cost and migration review

DeployOpen approaches GitHub Actions cost versus self-hosted Woodpecker CI and Jenkins by first agreeing a written scope that lists every cost component in your environment. We plan, implement, harden, document and hand over the self-hosted platform inside your own infrastructure, and support is available as a retainer.

How we scope

We inventory current GitHub Actions usage, runner hours, storage and secrets before any quote is written.
The written scope names which repositories, workflows and runners move, and which stay on GitHub.
We agree in writing what is excluded, such as forge migration, plugin rewrites or Kubernetes changes.

How we build

We install Woodpecker CI or Jenkins in your cloud account, data center or air-gapped network as agreed.
We configure agents, container or Kubernetes backends, and backups of Jenkins home or the Woodpecker database.
We run security testing on the pipeline platform and document the results against the agreed scope.

How we hand over

We deliver runbooks for upgrades, agent scaling, backups and secret rotation in your own documentation set.
We record what was migrated, what was re-created by hand, and which GitHub-only features were replaced.
We walk your platform and security teams through the handover so operation stays with your staff.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover.
Retainer scope is agreed in writing, including which Woodpecker or Jenkins releases are covered.
Ask us to prepare evidence for compliance assessments, while independent auditors issue any attestation.