Woodpecker forked Drone when the license changed. Here's how the two compare for small teams and homelabs that just want simple container-native CI.
Drone vs Woodpecker CI — Lightweight Self-Hosted CI
I run a small Gitea instance for side projects and a couple of client repos. For years the CI attached to it was Drone. It was fast, it was container-native, and the config was a single YAML file that any junior could read. Then Drone got bought, the licensing shifted, and a fork called Woodpecker showed up carrying most of the same DNA. I've now run both for long enough to have opinions, so here they are.
Drone was open source under Apache 2.0 for most of its life. Harness acquired it, and the project moved to a source-available model with a paid enterprise tier for anything past a certain scale. The code is still readable and you can still self-host, but it isn't the no-strings OSS it used to be.
Woodpecker is the community fork that broke off at that inflection point. It stayed Apache 2.0, fully open source, governed by contributors rather than a vendor. If your reason for self-hosting CI is partly ideological (you want to own the stack with no license asterisks) that difference is the whole story. For a lot of homelabbers and small shops, it is.
Architecturally these two are cousins, and it shows. Both are container-native: every pipeline step runs in a container, and the pipeline itself is defined as a series of steps in a YAML file that lives in your repo. Both use a server-plus-agent model. The server handles the web UI, webhooks from your forge, and scheduling. Agents pick up work and actually run the containers. You can run one agent on the same box or scale out to a fleet.
That means the mental model transfers cleanly. If you know Drone pipelines, you know Woodpecker pipelines. The plugin idea is identical too: a plugin is just a container with a documented set of environment variables, so publishing to S3 or sending a Slack message is a step that pulls an image and runs it.
The YAML dialects have drifted. Early Woodpecker was almost a drop-in for Drone's .drone.yml, but the project has moved on with its own conventions. Modern Woodpecker uses a pipeline or steps block and its own when syntax for conditionals. Here's a Woodpecker pipeline that runs tests then builds an image:
steps:
test:
image: golang:1.22
commands:
- go test ./...
build:
image: plugins/docker
settings:
repo: registry.example.com/myapp
tags: latest
when:
branch: main
event: push
Drone's version is nearly the same file with a kind: pipeline header and a trigger block instead of per-step when. The gap is small but real, and it's the main thing you touch during a migration.
Drone has a longer commercial history, so its plugin catalog is broader and some of the polished integrations (secret managers, enterprise auth, autoscaling on cloud providers) are more mature or gated behind the paid tier. Woodpecker's plugin story is leaner but growing, and because plugins are just containers, most Drone plugins run under Woodpecker with little or no change.
On version control, both cover the usual suspects: GitHub, GitLab, Gitea, Bitbucket. Woodpecker has been notably quick to support Forgejo (the Gitea fork), which matters if you've followed that particular exodus. If your forge is a self-hosted Gitea or Forgejo box, Woodpecker feels like the more natural fit because that community overlaps heavily.
Drone is the older, more battle-tested codebase with a large install base and Harness behind it for support contracts and roadmap. That backing is a genuine asset if you need someone to call.
Woodpecker is younger but the momentum is on its side. Contributor activity is healthy, releases are regular, and the direction is set by people running it rather than a company monetizing it. For a project whose entire pitch is "simple self-hosted CI you fully control," that governance model is more than a footnote.
| Dimension |
Drone (Harness) |
Woodpecker |
| License |
Source-available, enterprise tier |
Apache 2.0, fully OSS |
| Governance |
Vendor (Harness) |
Community |
| Architecture |
Server + agents, container-native |
Server + agents, container-native |
| Config |
.drone.yml, kind: pipeline |
steps / pipeline, when |
| Plugins |
Broad, some enterprise-gated |
Leaner, Drone-compatible |
| VCS support |
GitHub, GitLab, Gitea, Bitbucket |
Plus fast Forgejo support |
| Commercial support |
Yes, via Harness |
Community only |
| Best for |
Teams wanting a vendor backstop |
Self-hosters wanting pure OSS |
If you're already on Drone the move is not dramatic. Woodpecker connects to the same forges, so you re-register the OAuth app, point Woodpecker at your repos, and translate the pipeline files. The translation is mostly mechanical: swap the kind: pipeline header for a steps block, move trigger rules into per-step when clauses, and confirm your plugin images still exist (they usually do). Secrets and the agent setup carry over with minor renaming. Budget an afternoon for a handful of repos, not a week.
Both are aimed at the same person: someone running their own forge who wants CI that is container-native, cheap to operate, and readable without a certification. If you're comparing them against a hosted CI/CD platform, you're already in the self-host camp, so the real question is licensing and who you want steering the project.
Pick Woodpecker if you want CI that is unambiguously open source, community-run, and a clean fit for Gitea or Forgejo. Pick Drone if the Harness relationship is a feature for you: paid support, a longer track record, and a bigger plugin shelf you might one day want.
For a homelab or a small team that self-hosts on principle, we reach for Woodpecker. It keeps everything we liked about old Drone and carries none of the license baggage. Drone still earns its place where a vendor backstop and enterprise features are worth paying for, but for "simple container-native CI I fully own," Woodpecker is the one we install.
