Developer tools#Deployment

Woodpecker CI: a container-native CI engine from the Drone community fork

Woodpecker is the community fork of Drone CI: every pipeline step runs in its own container, SQLite to start, about 100 MB server RAM idle, config as code.

Project facts

GitHub Ecosystem
Repositorygithub.com/woodpecker-ci/woodpecker
License
Apache-2.0
Language
Go
Stars
8,005
Data checked
2026-10-15

Snapshot figures reflect the check date and may change over time.

Taking a small team’s “get a pipeline running” contract means deciding more than the steps: where it runs, who maintains it, and who gets paged when it breaks. Woodpecker CI is the community fork of Drone CI — a container-native CI engine written in Go (Apache-2.0, about 8.0k stars as of 2026-10-15) where every pipeline step executes in its own container and the config lives beside the code it builds.

Core features

  • Container-native: each pipeline step runs in a container you specify, so the build environment stops depending on what is installed on the runner machine.
  • Small footprint: the official install docs put the server at about 100 MB and an agent at about 30 MB of RAM idle, with SQLite as the default database — small machines carry it fine.
  • Multiple database backends: PostgreSQL and MySQL alongside SQLite, so the data tier scales with the team.
  • Several install paths: Docker, Docker Compose and Kubernetes all have official documentation, organized by environment.
  • Config as code: .woodpecker.yml travels with the repository, so the pipeline definition is reviewed in the same place as the code it builds.
  • Engineering hygiene on the record: an OpenSSF Best Practices badge, pre-commit.ci and Codecov coverage are visible on the repo’s front page.

Typical use cases

  • A developer delivering “tests and deploy on git push” to a startup: one Compose file for server plus agent, pipeline config in the repo, handover done.
  • A team migrating off Jenkins: once steps are containers, “what is installed on that node” stops being a question; the migration cost concentrates in the pipeline definitions themselves.
  • Resource-constrained self-hosters: one small VPS or a NAS can run it, and the published 100 MB figure makes light deployments easy to plan.

Quick start

The smallest working setup is a Docker Compose file running the server plus one agent; the official install docs walk through each environment and database. Once it is up, put .woodpecker.yml in the repo root and push:

steps:
  test:
    image: golang:1.24
    commands:
      - go test ./...

That is the basic shape. Secrets, matrix builds and registering multiple agents live in their own chapters of the documentation.

Summary

For teams that want self-hosted CI without Jenkins-grade operations, and for engineers delivering CI/CD as a contract — the pitch writes itself once “containerized steps, low footprint, config with the repo” are clear. It is not the right move for teams already locked into one hosted platform’s full stack: the migration has to carry accounts, permissions and the artifact registry with it. Written in Go under Apache-2.0, at 8,005 stars as of 2026-10-15 with pushes the same day — development is active.

Worth knowing before you pick: Drone CI itself is the upstream project maintained by Harness, and the fork’s divergence from that roadmap is worth a read at selection time. Another common self-hosted comparison is Gitea Actions, whose official runner is the least-friction option when your code already lives on a Gitea instance. On the same self-hosting track, Mailflare is another take on the delivery question — it moves domain email onto your own Cloudflare account where Woodpecker keeps the pipeline on your own machine.