Woodpecker CI

Background

Woodpecker is a community fork of Drone, created after Drone moved to a licence that restricted commercial self-hosting. It is Apache 2.0 and community governed, with no paid edition where features are held back — the thing that prompted the fork in the first place.

How it works

A .woodpecker.yml in the repository declares steps, each running in a container image. The model is close to Drone and recognisable to anyone who has written GitLab CI or GitHub Actions: declare an image, give it commands, chain steps.

The server is a single binary with a database, and agents run the pipeline steps. It is modest enough to run the whole thing on one small VM, which is a real distinction — Jenkins with a few plugins or a Concourse cluster both want meaningfully more.

Forge support covers GitHub, GitLab, Gitea, Forgejo and Bitbucket. The Gitea and Forgejo support matters: teams running self-hosted git often find CI options thin, and Woodpecker is one of the few that treats those forges as first class rather than an afterthought.

Where it fits

Woodpecker suits self-hosted setups on limited hardware — homelabs, small teams, and organisations that must keep CI inside their own network without funding a platform team. On that brief it does well, and the licence means that will not change.

What you give up

The plugin catalogue is small. Common tasks have plugins; anything specific means writing a step that runs a container you build yourself. That is workable but it is work that GitHub Actions users would not do.

Documentation is reasonable but thinner than larger projects, and obscure problems have fewer existing answers. The community is active and the project maintains steady releases, but it is a volunteer-scale effort rather than a vendor-backed one.

Self-hosting is also the only option — there is no hosted Woodpecker to fall back on if nobody wants to operate it.

Coming from Drone

Pipeline syntax is close enough to Drone that migration is mostly mechanical — rename the file, adjust a few keys, and most pipelines run. Plugins written as containers generally work unchanged, since a plugin is an image with an entrypoint rather than a framework-bound extension.

The reason to do it is licensing. Drone's move to a restrictive licence meant self-hosted commercial use required a paid agreement, and Woodpecker exists specifically so that is not a question. Apache 2.0 with community governance means there is no vendor able to repeat the change.

Resource footprint in practice

Server plus one agent runs comfortably on a 1 GB VM for light workloads, and agents scale horizontally for more. Compared with Jenkins — where the JVM alone wants more than that before any build runs — this is the practical appeal for homelabs and small teams.

The ceiling is correspondingly lower. Large build fleets, complex matrix builds and heavy artifact handling are where mainstream platforms have invested and Woodpecker has not.