GitHub Actions vs Woodpecker CI: Self-Hosting Compared

DEV Community

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. What each side asks you to operate. The memory figures are the idle footprint the Woodpecker project publishes for its server and agent, not a measurement taken here. 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. Comparison 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 coe...

Powered by Readybot.io*