What is Woodpecker CI?

Updated

Woodpecker CI is an open-source, free CI/CD engine that runs pipeline steps inside Docker containers. It fits teams or individuals who want a self-hostable continuous integration system that stays simple to operate but can be extended through plugins and multiple interdependent workflows. If you need a hosted-only service or a system that does not rely on Docker for step execution, Woodpecker is not the direct match.

Core characteristics

Open source and free

Woodpecker is and always will be totally free, and its source code is open-source, so you can contribute to help evolve the project. This matters if licensing cost or vendor lock-in is a deciding factor for your CI choice.

Docker-based pipeline execution

Woodpecker uses Docker containers to execute pipeline steps. Each step runs in a container, which means the environment for a step is defined by the image you choose rather than by the host machine's installed tooling.

Extensibility through plugins

If you need more than a normal Docker image, you can create plugins to extend pipeline features. Plugins are the mechanism for packaging custom behavior so it can be reused across pipelines.

Multiple workflows with dependencies

Woodpecker allows you to easily create multiple workflows for a project, and those workflows can even depend on each other. This is useful when a project has distinct stages or targets that should run in a defined order rather than as one flat pipeline.

What problem it solves

Need How Woodpecker addresses it
Avoid CI licensing costs Free and open-source
Reproducible build environments Steps execute in Docker containers
Custom pipeline behavior Plugins extend pipeline features beyond standard images
Multi-stage or multi-target projects Multiple workflows, optionally dependent on each other
Simplicity without losing power Described as simple yet powerful, with extensibility

When to consider it

  • You want a CI/CD engine you can run and inspect yourself, built on Docker.
  • Your pipelines benefit from containerized steps and you are comfortable defining steps as container images.
  • You have project structures that map naturally to several workflows with ordering between them.
  • You may need custom step behavior and are willing to build a plugin rather than only use off-the-shelf images.

When to look elsewhere

  • You require a fully managed CI service and do not want to operate the engine.
  • Your environment cannot use Docker containers for pipeline steps.
  • You need capabilities that are neither covered by standard Docker images nor by writing a plugin.

Next step

To evaluate it concretely, start from the official site and docs: review how a pipeline step is defined as a container, then check the plugin mechanism and the multi-workflow documentation to confirm they match your project's structure.