GitHub Actions vs Woodpecker CI: the smallest honest self-host
GitHub Actions vs Woodpecker CI is a fair fight only if you already know why you would self-host, because Woodpecker is not trying to be cheaper than a hosted runner, it is trying to be small: the project documents its idle footprint as around 100 MB of RAM for the server and 30 MB for an agent, on SQLite, with no external database required. The reason to pick it is usually that your code is not on GitHub at all.
Woodpecker describes itself as a simple, yet powerful CI/CD engine with great extensibility. It is Apache 2.0, at v3.18.1 as of 8 September 2026, and it exists because of a licensing decision: the project was forked from Drone 0.8 in April 2019, after the Drone license changed from Apache 2.0 to a proprietary one, and renamed to Woodpecker that August.
That origin is the most useful thing to know about it. Woodpecker is the branch of that family that stayed permissively licensed, and its own about page draws the contrast directly, describing itself as community-focused software that will stay free and open source while Drone is managed by Harness under a Polyform Small Business license.
Everything below was read from the woodpecker-ci/woodpecker repository, its documentation and its release history on 21 September 2026, and from GitHub's own references for the Actions column.
GitHub Actions against Woodpecker CI, at the scale each is built for (read 21 September 2026)
| GitHub Actions | Woodpecker CI | |
|---|---|---|
| What you run | Nothing, or self-hosted runners if you choose | A server and at least one agent, plus an optional autoscaler. The agent connects to the server over gRPC |
| Resource footprint | Not applicable | The project documents roughly 100 MB of RAM for the server and 30 MB for an agent at idle, and notes it runs on a Raspberry Pi |
| Database | Not applicable | SQLite by default with no installation or configuration. Postgres or MariaDB recommended for larger instances |
| Where the code can live | GitHub only | GitHub, Gitea, Forgejo, GitLab, Bitbucket and Bitbucket Datacenter, with push, tag and pull request events supported on all six |
| Config | .github/workflows/*.yml | .woodpecker.yaml, or several files under .woodpecker/, with a when: block filtering events and branches |
| Extension model | Actions from the marketplace, pinned by tag or commit SHA | Plugins are container images, which means the supply chain is a registry rather than a plugin catalog |
| Execution backends | GitHub-hosted, a managed vendor, or self-hosted runners | Docker, Kubernetes or local, chosen per agent. Several agents can coexist with different backends and job limits |
| What you pay per minute | $0.006 at 2 vCPU on Linux, or $0.0025 on a managed runner at the same size | Nothing. A server and an agent that idle in the low hundreds of megabytes are cheap to host, and they bill between builds |
| Self-healing or retries | None on GitHub-hosted runners; transient failures diagnosed and retried inside the run on Latchkey | None built in. A failed pipeline is restarted by hand or by a new event |
| Setup change required | A file in the repository | A server, an agent, an OAuth application on the forge, and admin rights on each repository so Woodpecker can install its webhook |
The footprint is the feature
Most self-hosted CI asks for a machine. Woodpecker asks for a process. Its readme puts the idle requirement at around 100 MB of RAM for the server and 30 MB for an agent, running on SQLite with nothing else to install, and the documentation suggests Postgres or MariaDB only once the instance gets large. That is small enough that the usual objection to self-hosting, which is that somebody has to own a server, changes character: you are owning a container, not a cluster.
The components are equally plain. The server provides the user interface, processes webhooks from the forge, serves the API and reads the YAML. The agent executes workflows on a Docker, Kubernetes or local backend and connects back over gRPC. Multiple agents can coexist so that backends and job limits can be tuned separately, and an optional autoscaler can start cloud VMs for pending builds and destroy them afterwards.
There is a small operational detail worth copying regardless of which side you pick: Woodpecker publishes no latest container tag, on the stated grounds of preventing accidental major version upgrades. That is a good habit, and it is the opposite of how most people pin their CI images.
The forge question, which is the real decision
GitHub Actions runs on GitHub repositories. That is not a limitation anyone is hiding, it is the product. So if your code is on Gitea, Forgejo, a self-hosted GitLab or Bitbucket Datacenter, the comparison on this page is not really a comparison: Actions is not available to you and Woodpecker is one of a short list of things that is.
Woodpecker supports six forges, and its feature matrix is honest about where support is uneven. Push, tag and pull request events work on all six. The release event is supported on GitHub, Gitea, Forgejo and GitLab but not on either Bitbucket. The deployment event can be triggered from Woodpecker for every forge, but only GitHub can trigger it by webhook.
One prerequisite catches people on first install. Enabling a repository requires admin rights on it, because Woodpecker adds a webhook so it can learn about pushes, pull requests and tags. On a repository somebody else administers, that is a conversation before it is a configuration.
Speed
Not benchmarked yet. Both run your steps in containers, so the wall clock is set by the machine and the cache, and a comparison between our Woodpecker host and GitHub's fleet would report the hardware difference rather than an engine difference.
The one thing that is genuinely different in kind is the local loop. Woodpecker ships woodpecker-cli exec, which runs a workflow file on your own machine before a server exists. On GitHub Actions the equivalent is pushing a branch and waiting, or reaching for a third-party emulator. For a team iterating on pipeline YAML, that difference is worth more minutes than most caching changes.
Cost: the cheapest self-host in this cluster, honestly compared
Ten thousand Linux minutes a month is $60 at GitHub's $0.006 list rate for a 2 vCPU runner, $42 on a Team plan after the 3,000 included minutes, and $25 at $0.0025 a minute on a managed runner at the same size. Woodpecker's software costs nothing, and the server it runs on is small enough to share with something else.
The catch is the same one every self-hosted option has, and it is not the server. It is the agent, which needs to be as fast as the runner it is replacing or your builds get slower, and which bills for every hour it is up rather than every minute it is busy. Woodpecker's 30 MB idle figure is for an idle agent, not for one building your project, and the machine you size for your slowest job is the machine you pay for overnight. The autoscaler exists precisely because of that, and using it means adding a cloud provider and a scaling policy to the list of things you own.
Why there is no recorded run on this page
The figures that make Woodpecker interesting are the project's own published idle footprint, and they are the sort of measurement that only means something taken the same way twice. Ours would report our container runtime on our hardware, and the reader would then have two numbers to reconcile instead of one to check. Where the page needed a fact rather than a measurement, it took it from the documentation and the feature matrix in the repository, both linked below.
When each one is right
- Woodpecker when the code is not on GitHub. This is the deciding case, and everything else on this list is secondary to it.
- Woodpecker when you want a self-hosted CI you can actually read: two processes, a SQLite file, container steps, and a permissive license with no commercial-use clause to check.
- Woodpecker for homelab, hobby and privacy-first setups, where a 100 MB server on hardware you already own is the entire cost.
- GitHub Actions when the code is on GitHub and you want pull request checks, required status checks and merge gating without wiring any of it up.
- GitHub Actions with a different runner when the complaint is the bill rather than the platform. Self-hosting to save $35 a month on 10,000 minutes is a poor trade against changing one line in the workflow.
The verdict
Woodpecker is the most likeable project in this batch and the easiest to recommend for the case it is built for. It is small, permissively licensed, forge-agnostic, and it runs your pipeline locally before a server exists. If your repositories are on Gitea, Forgejo or a self-hosted GitLab, it belongs on your shortlist and GitHub Actions does not belong in the comparison at all. If your repositories are on GitHub, be honest about what you are buying: you would be adding a server, an agent, a webhook per repository and an OAuth application in order to replace something that is already there and already integrated with your pull requests. That trade makes sense for control and for privacy. It rarely makes sense for cost.
Frequently asked questions
What are Woodpecker CI's resource requirements?
Which forges does Woodpecker support?
Is Woodpecker a fork of Drone?
Can I test a Woodpecker pipeline without a server?
woodpecker-cli exec runs a workflow file locally, which the documentation suggests as a way to try a pipeline before installing a server at all. There is no first-party equivalent on GitHub Actions, where the loop is to push a branch and watch the run.Related guides
References
- woodpecker-ci/woodpecker, including the idle footprint in its readme
- Woodpecker administration: server, agent, autoscaler and database
- Woodpecker forges: the six supported and where event support differs
- Woodpecker: the fork history and how it describes the Drone license change
- GitHub Actions runner pricing, read for the per-minute rates quoted here
- GitHub Actions documentation