GitHub Actions vs Woodpecker CI: when each fits and what the decision turns on
If you run GitHub Actions and want your builds on infrastructure you control while your code stays on GitHub, the question is less about features and more about who operates the build layer. GitHub Actions fits when you want hosted convenience, access to the Marketplace of published actions, and a workflow experience that already sits inside your GitHub Enterprise contract. It also fits when your team has no appetite for running runners, agents or a CI database. Woodpecker CI fits when builds must run on your own servers, Docker or Kubernetes, with pipelines written as container steps and GitHub kept as the forge. Its forge documentation lists GitHub among the supported forges, so the repository, pull requests and webhooks can stay where they are while the pipeline engine moves in-house.
Before committing, confirm what Woodpecker needs from GitHub. Ask whether your organization can register a GitHub OAuth application for the Woodpecker server, who will manage the server, agents and their Docker or Kubernetes backend, and how the SQLite default will be replaced by PostgreSQL or MariaDB for a larger instance. Woodpecker is licensed under Apache-2.0 and its documentation under CC BY-SA 4.0, so the license cost is zero, but the operating work is real: upgrades, agent capacity, backups and access control on the server are your responsibility. The Woodpecker releases page is the place to track changes between versions, including security-relevant fixes.
The decision turns on three questions. First, runner and secret control: GitHub never returns Actions secret values through its API, so any move means re-creating them in the new engine, and a self-hosted engine gives you full control over where those values are stored and who can read them. Second, operating capacity: someone must own the Woodpecker server, agents and autoscaling, and the cost of that person's time usually outweighs the software cost. Third, how many workflows depend on Marketplace actions. Woodpecker uses plugins as container images, and its documentation says Drone plugins generally work but may need adjustments. Count the actions your workflows call today, and list which ones have an equivalent plugin or a short container script. A high count points toward staying on GitHub Actions for a while or planning a phased move.
Which option fits which situation
This table matches common situations to the option that fits best and the reason, based on where secrets are held, how long artifacts are kept and where agents run. Read each row against your own constraints, and treat the fit as a starting point to confirm with a proof of concept in your environment.
| Situation | Better fit | Reason |
|---|---|---|
| Keep GitHub as the forge but run builds on your own runners | Woodpecker CI | Woodpecker connects to GitHub as a forge, so repositories stay put while the server and agents run in your infrastructure. |
| Heavy use of GitHub Marketplace actions | GitHub Actions (or a Gitea or Forgejo migration) | Woodpecker uses container steps and plugins, so each marketplace action needs a plugin or rewrite. Confirm plugin coverage before committing. |
| Small team with no dedicated platform staff | GitHub Actions or a managed option | Woodpecker needs someone to run the server, agents, database and upgrades. Without that owner, the operating burden outweighs the benefit. |
| Kubernetes-based builds with pod-level isolation | Woodpecker CI | The Kubernetes backend runs each step in its own pod, and a shared volume claim passes files between steps, which fits cluster-native teams. |
| Strict secret custody requirements | Woodpecker CI | Secrets stored on your own server remain under your control. GitHub never returns secret values through its API, so you must re-enter them during any move. |
| Long artifact retention or audit trails | Woodpecker CI | Hosted services keep artifacts for limited periods, so you control retention when storage runs on your own infrastructure. Confirm how long your chosen storage keeps logs. |
| Multiple forges or cross-forge pipelines | GitHub Actions or a single-forge migration | Connecting multiple forges to one Woodpecker server is still experimental according to its forge documentation, so avoid relying on it in production. |
| Air-gapped or no-internet builds | Woodpecker CI or Jenkins | Both run without hosted services, but you must confirm plugin and base image sourcing and how they reach your internal registry. |
Where secrets, logs and artifacts live with each option
Before choosing a platform, decide where your deployment credentials and build outputs are allowed to sit. With GitHub Actions, secrets, run logs and artifacts are stored on the vendor side, and each has its own retention behavior. Artifacts default to 90 days, so anything your auditors or incident responders may need later has to be exported before it expires. The GitHub REST API returns secret names but never their values, so the secret values themselves cannot be pulled out and moved. Your team must re-create each one on the new platform from the original source, such as the cloud provider, the registry or the vault that issued it. Confirm the inventory of repository, environment and organization secrets before the migration starts, because each one that is missing from the new platform will fail a deployment, not the build.
With Woodpecker CI, the pipeline data lives in a database that your team selects and operates. Woodpecker uses SQLite by default, and the project recommends PostgreSQL or MariaDB for larger instances, so the database location, backup schedule and access controls become your responsibility. Agents that execute the steps run on machines or Kubernetes clusters you control, and the server that receives forge webhooks and parses pipeline YAML sits in the same environment. Where secrets are stored in Woodpecker and how long build logs are kept depend on your configuration and on the retention you set, so confirm those settings in the Woodpecker administration documentation before you commit to a design. Also confirm where the artifacts and any cache volumes are written in your chosen backend.
This control matters most when pipelines handle regulated data, production cloud credentials or signing keys, because a leaked CI secret can reach production directly. Ask who can read secrets, who can view logs that may echo sensitive values, and whether your evidence requirements, such as build records or deployment history, outlast the vendor's retention period. Whether a platform can meet a specific residency or retention requirement is a question for your own environment and your assessor, so put those questions to the vendor and to your team in writing. A practical first step is to list each pipeline that deploys to production, record where its secrets originate, and decide whether the new location of each secret, log and artifact meets the control your organization requires.
Identity, compliance and trust boundaries to review
Moving builds from GitHub Actions to Woodpecker CI changes who holds secrets, who runs the server and who can change a pipeline. The cards below cover the decisions that shift with that move and the evidence a reviewer will ask for. DeployOpen prepares that evidence for your assessment, but independent auditors and certification bodies issue any audit report or attestation.
Hosted secret exposure
Hosted CI services hold deployment secrets for every connected project. In its January 4, 2023 incident report, CircleCI told all customers to rotate secrets after an attacker exfiltrated environment variables, tokens and keys, along with the encryption keys needed to read them. This is an example of hosted CI risk, not a finding about GitHub. With Woodpecker, the secrets sit in the server you operate, so check who can read them, how the database is encrypted and how a rotation is executed.
Runner trust and agent isolation
A Woodpecker agent runs workflows on Docker, Kubernetes or the local machine, so every step executes code from the repository it was given. Treat pipelines from forks and untrusted pull requests as hostile input. Decide whether agents run on dedicated hosts, whether build containers can reach the agent host or internal networks, and whether production deployments run on separate agents with narrower access.
Server and database administration
A Woodpecker installation has a server that provides the UI and API, receives forge webhooks and parses pipeline YAML, plus agents that connect over gRPC. SQLite is the default database, with PostgreSQL or MariaDB recommended for larger instances. Name the people who administer the server, the database backups, the TLS and gRPC endpoints and the forge OAuth application, because those become your responsibility and an auditor will ask who holds them.
Pipeline access and change control
Pipeline files live in the repository, so anyone who can push to a branch can change what runs on your agents. Define which branches and events may run deployment steps, use protected branches on the forge and review changes to .woodpecker.yaml or .woodpecker/ like any other code change. Confirm how Woodpecker maps forge permissions to its own user and repository roles, and whether signing of pipeline artifacts or images is available in your setup.
Enforced agent labels in 3.19.0
Woodpecker 3.19.0 enforces agent labels on the server and fixes an injection of matrix environment variables into the default clone step. Pin the server and agents to 3.19.0 or a later release, and document the label scheme so jobs cannot land on agents outside the intended trust zone. Verify this behaviour on a test instance before relying on it for segregation of duties.
Audit evidence to prepare
Assessors usually ask for a list of who can change pipelines, who can read secrets, how deployments were approved and where logs are kept. Woodpecker keeps build logs on the server and in its database, so you decide retention and access. DeployOpen can prepare the configuration, access lists, runbooks and test records that support your assessment. Ask your auditor which evidence format they accept before work starts.
How a Woodpecker installation is assembled
A Woodpecker installation has three kinds of component, and the first decision is where each one runs. The server provides the web UI and the API, receives webhooks from the forge, and parses the pipeline YAML. Because the server owns the parsing step, it is the component that decides which workflows are queued and what they are allowed to run. Plan it as a long-running service with its own database. Woodpecker uses SQLite by default and recommends PostgreSQL or MariaDB for larger instances, so confirm the database choice against the number of repositories and build history you expect to keep.
The agents do the actual work. Each agent runs workflows on Docker, Kubernetes or the local machine, and connects back to the server over gRPC. Agents initiate the connection to the server, so they can sit in a network segment that the server reaches on its gRPC endpoint, and the pipeline's build steps never need to run on the server host. Agent labels matter here: the 3.19.0 release enforces agent labels on the server side, so confirm which labels your workflows request and which agents carry them before you rely on routing. The optional autoscaler can create cloud VMs for pending builds and remove them when the queue drains. It is the only component that touches your cloud account to create compute, so its credentials and instance limits deserve the same review as the cloud account itself.
A GitHub event reaches Woodpecker as a webhook. When a push, tag or pull request event fires on a repository that has been activated in Woodpecker, GitHub sends an HTTP request to the Woodpecker server, which validates it using the forge connection configured for GitHub, reads the pipeline definition from the repository, and queues the workflows for an agent. The build status is then reported back to GitHub through the same forge connection, so pull request checks still appear on GitHub. Before cutover, confirm the webhook URL is reachable from GitHub, that the GitHub OAuth or app credentials are stored on the server, and that firewall rules allow the agents to reach the server's gRPC port. The Woodpecker forge documentation is the next read for the exact GitHub settings.
What each option costs over time and what drives it
Moving builds from GitHub Actions to Woodpecker CI changes who pays for compute, storage, servers and upkeep. The cards below separate one-time setup from recurring spend, and name the drivers that move each line up or down, so a quote can be compared line by line.
GitHub-hosted minutes and storage
GitHub bills hosted runner minutes and stored artifacts and logs, and these charges recur with every build. Under the current model, the main drivers are pipeline duration, the number of pushes that trigger runs, the operating system of the hosted runner, and how long artifacts are kept. The default artifact retention is 90 days, so storage spend grows with build volume and retention settings. Ask your team to pull the last three months of billed minutes and storage by repository before comparing any option.
Self-hosted runner charges
Self-hosted GitHub Actions runners run on your hardware, but GitHub has announced a charge of $0.002 per minute for them and then postponed it. That history matters because a per-minute charge on your own compute can return with little notice. Woodpecker agents avoid per-minute metering by design, so the recurring cost becomes the capacity you provision. Check the current GitHub terms before budgeting, and record whether any runner charge applies to your plan.
Woodpecker server, database and agents
A Woodpecker installation needs a server for the UI, API and webhooks, agents that run steps on Docker or Kubernetes, and a database. SQLite is the default, while PostgreSQL or MariaDB is recommended for larger instances. Recurring costs are the virtual machines or cluster capacity behind these components, backups of the database, and the agent fleet, which an optional autoscaler can scale up for pending builds. Ask for the sizing assumptions, the number of agents and the expected concurrent builds in any quote.
Upgrades and plugin maintenance
Woodpecker releases change behavior, so each upgrade needs a test run against your pipelines. The 3.19.0 release, for example, fixed an injection of matrix environment variables into the default clone step and enforces agent labels on the server, which can affect existing configurations. Marketplace actions must be replaced with Woodpecker plugins, and the docs note that Drone plugins generally work but could need adjustments. Ask for a fixed-scope estimate of pipeline porting, plugin replacement and a recurring upgrade cycle, and confirm who tests each release.
Staff time and on-call coverage
Staff time is usually the largest cost and the one most often left out of a comparison. Someone must own the Woodpecker server, the database, agent images, secrets and access, and must respond when the build system fails before a release. GitHub carries that operational load for hosted runners, so the difference is who gets paged. Estimate the hours per month for routine care and for incident response, and name the internal owner. A managed retainer can cover part of this work, and its scope should be written down before work starts.
Secrets and artifact migration effort
Moving off GitHub also carries one-time costs that do not appear on a monthly invoice. GitHub's REST API returns Actions secret names without their values, so every secret must be re-entered from its source system, which takes coordination with each owner. Build artifacts and logs also expire on their own schedule, so history must be exported before retention ends. Ask any provider to list the secrets, repositories and retained artifacts in scope, and to price the one-time migration separately from the recurring run cost.
Moving builds to Woodpecker CI while keeping code on GitHub
This sequence moves build and test execution from GitHub-hosted runners to a self-hosted Woodpecker CI server while repositories, pull requests and code review stay on GitHub. The result is a tested cutover path with exported history, re-created secrets and retired hosted runners.
Inventory workflows and marketplace actions
Your platform or DevOps team lists every workflow file, trigger, job, runner label, environment and secret reference across the repositories in scope. Each marketplace action is mapped to a shell command, a container image or a Woodpecker plugin, and any action with no equivalent is flagged for a decision. Done when every workflow has a documented target shape and the open items have named owners.
Export run history and artifacts before retention expires
Before any cutover, the team pulls run logs, artifacts and release metadata through the GitHub REST API or GitHub CLI and stores them in the organization's own archive. Retention on GitHub Actions is finite, so this export starts early and runs on a schedule until the last hosted run is retired. Done when a sample restore has been checked and the archive location is recorded in the migration plan.
Stand up the Woodpecker server and database
The platform team installs the Woodpecker server in the organization's infrastructure, choosing Docker, Kubernetes or Helm as the deployment method and deciding whether to use the default SQLite database or PostgreSQL or MariaDB for a larger instance. They also plan backups for the database and set the server's public URL so forge webhooks can reach it. Done when the UI loads over the intended hostname and the database backup has been restored once in a test.
Connect GitHub as the forge
An administrator registers Woodpecker with GitHub as the forge, granting it only the repository access that the pilot repositories need. Push, tag and pull request events are then tested on one non-production repository. Because connecting multiple forges to one server is still experimental, the team confirms the single-forge setup before scaling. Done when a test push and a test pull request both trigger a pipeline and report status back to GitHub.
Translate jobs into container steps and plugins
Developers rewrite each workflow as a Woodpecker YAML file, placing every step in a named container image and replacing marketplace actions with plugins from the Woodpecker plugin index or with plain commands. Event, branch and path filters are carried over, and build matrices are rebuilt where needed. Done when each translated pipeline passes on a branch and produces the same test and build results as its GitHub Actions run.
Re-create secrets that GitHub never exports
GitHub's API returns secret names without values, so the owners of each deployment credential must re-enter the values in Woodpecker, scoped to the repositories and events that need them. Old GitHub secrets are rotated rather than copied where the credential allows it. Done when every pipeline that uses a secret has been run once and the team has recorded who owns each credential.
Run parallel pipelines and verify
Both systems run side by side for a defined review period. Woodpecker workflows in the .woodpecker/ directory run as parallel workflows with depends_on ordering, so the team checks that test, build and deploy stages still wait for the right predecessors. Results, timings and failures are compared on every change. Done when the team agrees the Woodpecker results match the GitHub results on all pilot repositories.
Cut over webhooks and retire hosted runners
Once parallel results match, the team disables the GitHub Actions workflows for the migrated repositories, confirms that Woodpecker is the only pipeline triggering on pushes and pull requests, and removes self-hosted runner registrations no longer in use. Runner-related settings are reviewed in the repository's Actions settings. Done when no workflow runs on GitHub for the migrated repositories and the final history export is stored.
Questions buyers ask before choosing Woodpecker CI
How much work does a migration from GitHub Actions to Woodpecker CI take?
The effort depends mostly on how many repositories, workflows and marketplace actions you run, how many secrets must be re-created by hand, and how much build history you need to keep. Woodpecker reads its own YAML, so each workflow is rewritten as container-based steps, and each marketplace action needs either a Woodpecker plugin or a script step. Ask for a written inventory of repositories, workflows, actions and secrets before any quote is agreed, because that inventory sets the scope. Your own environment will also matter, including whether you already run Kubernetes or Docker hosts for agents. Treat any duration you hear from a vendor or partner as a hypothesis until it is tied to that inventory.
Can a small team run Woodpecker CI without outside help?
A small team can run Woodpecker CI itself if it has someone comfortable with containers, a reverse proxy, backups and a database. The server handles the UI, API, webhooks and pipeline parsing, agents run the workflows over gRPC, and an optional autoscaler can add cloud VMs for pending builds. Woodpecker uses SQLite by default, while PostgreSQL or MariaDB is recommended for larger instances, so a growing installation adds database work. Plan for ongoing upgrades, plugin maintenance and on-call time, since none of these are handled by the project for you. Confirm the staffing hours your team can actually spare before deciding between self-operation and a support retainer.
What skills does a team need to operate Woodpecker CI?
You need working knowledge of three areas. The first is containers, because every workflow step runs its commands inside a specified image and plugins are container images configured through a settings block. The second is Kubernetes if you choose the Kubernetes backend, where each step runs in a standalone pod and a temporary persistent volume claim shares files between steps, with a default size of 10G and ReadWriteMany access. The third is database administration, covering backups, upgrades and connection tuning for PostgreSQL or MariaDB. Pipeline YAML and Git forge administration are also needed. Confirm which of these skills already exist in your platform team before you commit to a design.
Can GitHub Marketplace actions be replaced in Woodpecker CI?
Many Marketplace actions can be replaced, but not all of them one for one. Woodpecker plugins are container images listed in the plugin index, and the Woodpecker documentation notes that Drone plugins generally work but may need adjustments. Actions that only wrap a single CLI or API call are usually simple to replace with a plugin or a script step. Actions that depend on GitHub-specific context, such as GITHUB_TOKEN permissions, the GitHub API or composite logic, need manual rework. Build a list of every action your workflows call, mark each as a plugin match, a script rewrite or a removal, and review the list with the teams that own those pipelines.
How do CI secrets move from GitHub to Woodpecker CI?
Secrets cannot be exported from GitHub. The REST API returns Actions secret names without their values, so each secret must be re-entered in Woodpecker from the original source system or a fresh credential. Treat this as a rotation event: issue new deploy keys, registry tokens and cloud credentials where possible, and scope each one to the repository or environment that needs it. Record who owns each secret, where it is stored and when it was last rotated. Hosted CI incidents have shown why this matters, since a provider can be compromised and tell customers to rotate everything. Confirm with your security team how Woodpecker secrets will be encrypted and who can read them.
Does moving CI to Woodpecker CI also mean moving our code?
No. Woodpecker connects to GitHub as a forge and reacts to push, tag and pull request events, so repositories, pull requests and code review can stay on GitHub. This lets you move the build engine in-house without a Git hosting migration in the same project. Be aware that Woodpecker documentation says connecting multiple forges to one server is still experimental, so plan a single forge per server. Also confirm that your GitHub App or OAuth setup, webhook delivery and network path from GitHub to your Woodpecker server are approved by your network and security teams.
When should we hire outside help for a Woodpecker CI migration?
Consider outside help when the inventory is large, when secrets are spread across many teams, when you need an audited build path, or when no one on staff can own the platform after go-live. A fixed-scope engagement works well when the scope, deliverables and timeline are agreed in writing before work starts. DeployOpen plans, implements, integrates, hardens, backs up, upgrades and documents self-hosted platforms inside your own infrastructure, and can run security testing and prepare evidence for compliance assessments. DeployOpen does not issue audit reports or certifications. Ongoing support and upgrades are available as retainers, and a quote follows from the written scope.
Official sources to check before deciding
Start with the Woodpecker about page, because it sets the license and history terms of this decision. Woodpecker CI is licensed under Apache-2.0, and its documentation is under CC BY-SA 4.0. Confirm both licenses against the repository before you record them in a procurement or architecture file. The about page also explains the 2019 fork of Drone 0.8 after Drone moved to a proprietary license, and Drone is now managed by Harness under the Polyform Small Business license. Read that history alongside your own legal review, and ask your counsel whether the Apache-2.0 terms fit how your organization plans to modify or redistribute pipeline plugins and images.
Read the GitHub pricing change page before you size the migration. It covers the 2026 pricing changes for GitHub Actions, including the announced charge of $0.002 per minute for self-hosted runners, which GitHub later postponed. Because that charge was announced and then postponed, treat self-hosted runner cost as a variable you must confirm, not a settled number. Ask GitHub in writing whether any per-minute charge applies to your plan, which runners it covers, and when it would start. Keep the answer with its date. Your Woodpecker business case depends on which hosted minutes, storage and Copilot review usage you still pay for while the forge stays on GitHub.
Check the Woodpecker releases page before you choose a version to pin. The most recent entries on the page at the time of writing are 3.19.0 (October 7, 2026), 3.18.0 (August 24, 2026) and 3.18.1 (September 2026). The 3.19.0 notes describe a fix for injection of matrix environment variables into the default clone step and a change that enforces agent labels on the server. Review your matrix pipelines and agent label assignments before you upgrade, and test the upgrade on a staging server. Confirm the current release yourself, since the list changes, and watch the repository for security notices.
How DeployOpen helps evaluate and implement the switch
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure. For a move from GitHub Actions to Woodpecker CI, the work starts with a written scope that separates the CI engine change from any change to where your code lives.
How we scope
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- The scope inventories workflows, marketplace actions, secrets, artifacts and the runner fleet GitHub Actions uses today.
- Decisions on forge connection, Docker or Kubernetes agents, and database choice are recorded before any pipeline is rewritten.
How we build
- Woodpecker is installed with a server, agents and a database sized to your scope in your cloud account or data center.
- Workflows are translated into container-based steps, with marketplace actions mapped to Woodpecker plugins or rebuilt where none exists.
- Pipelines are tested on branches and pull requests alongside GitHub Actions until results match before cutover.
How we hand over
- You receive documentation covering the server, agents, pipeline YAML conventions, plugin list and secret handling.
- Secrets are re-created in Woodpecker by your team, since GitHub does not export secret values, and the process is recorded.
- Runbooks cover upgrades, agent scaling, backups of the database and an export of run history and artifacts kept before retention expires.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Upgrades to new Woodpecker releases are planned, tested on a non-production server and then applied.
- Security testing of the pipeline and its runners can be scoped separately if your assessors require evidence.
