Why We Chose Woodpecker CI (And You Probably Should Too)
While everyone argues about GitHub Actions and GitLab CI, we quietly run Woodpecker CI. Here is why it became our default for self-hosted pipelines.
It was a Tuesday. A client called us because their CI bill had doubled twice in six months. Not because they shipped more code. Not because they hired anyone new. Because the vendor rewrote the pricing page again, and not a single engineer on the team could explain why.
Let's be clear: this is not a rare story. It is the default story of modern CI/CD. You sign up for a "simple" hosted runner, and five years later you are paying rent on a pipeline you do not control to a company that treats your builds as a recurring revenue stream.
We got off that ride. We run Woodpecker CI for ourselves and for our clients. Not because it is famous. It is not. Not because it is trendy. It never will be. We run it because it is the only CI tool that does not insult our intelligence.
We Picked It Out of Spite
I am not going to pretend we discovered Woodpecker in a moment of wisdom. We found it because we were angry.
We were angry at CI platforms that worked great until an acquisition turned them into lead-generation machines. Angry at tools that locked us to one Git host like a phone contract. Angry at controllers that needed more RAM to do nothing than our databases needed under load. Angry at "custom plugin" meaning "talk to sales." Angry at YAML files so nested and templated that reading them felt like decoding a fever dream.
The pattern is always the same. A tool starts simple, gets popular, attracts investors, and then begins the slow Corporate decay. Prices climb. Self-hosting gets squeezed. Documentation starts sounding like a sales deck. We have watched the same movie so many times we could recite the dialogue.
Woodpecker felt different the first time we deployed it. Not because the marketing was better. There barely is any. It felt different because it was built by people who actually run builds, not by people trying to build a unicorn.
Multi-Forge Is Not a Feature, It Is Freedom
Let's be honest about most CI platforms. They were built for one Git host. Everything else is a poorly maintained checkbox so they can pretend to be neutral.
Woodpecker does not play that game. It speaks natively to:
That is not a feature list. That is the difference between owning your tooling and renting it from a Git host.
Your Git host is a sovereignty decision. Some clients use GitHub because their whole world is there. Others run Forgejo because they want their source code on hardware they bought. A few are stuck on GitLab because an auditor or procurement drone made the call. Woodpecker does not care. Same server. Same pipeline format. Same agents.
With most tools, changing your Git host means rewriting your CI. That is not integration. That is lock-in with extra steps.
Your CI should follow your code. Your code should not follow your CI vendor's business plan.
Independence in a World of License Theater
Here is a short story. Drone CI was great. Then Harness bought it. Then the license changed. Then the self-hosted version started feeling like an advertisement for the enterprise cloud. Then the community did what it always does when a good tool gets ruined: it forked.
That fork is Woodpecker. Apache 2.0. No paid tier. No "contact sales" button. No telemetry dressed up as "product analytics." No terms of service that claim the right to read your build logs.
For us, independence is not a philosophical nicety. It is a contract. When we tell a client "your builds stay inside your network," we need a tool that makes that true. Woodpecker does not phone home. It does not require a vendor account. It does not gate features behind a pricing page that gets rewritten every quarter by someone whose job title contains the word "growth."
And if the project ever stalls, we have the source. That is the deal. With a SaaS CI, a dead feature becomes a support ticket and a price increase. With Woodpecker, a missing feature becomes a patch or a fork. We have compiler access. They have a billing department.
Plugins Are Just Containers
This is the part that made our engineers actually smile. A Woodpecker plugin is a Docker image. Nothing else. No SDK. No manifest format. No marketplace approval process. No prayer circle.
If you can write a shell script and wrap it in a container, you can extend Woodpecker. That is the entire API.
We have built several plugins for our own workflows. Some are public, like opengrep. Some are private. The private ones are not a problem because a plugin is just an image in a registry we control. We push it. We reference it. We run it. Done. No hoops. No enterprise plan. No begging a vendor to let you keep something internal.
A few examples:
- A deployment trigger that talks to our management layer and rolls out after a green build.
- A lint-and-gate step that enforces our internal rules before anyone can merge.
- Private helpers that integrate with client systems we are contractually not allowed to publish.
steps:
deploy:
image: docker.kalvad.com/plugins/nomad-deploy:latest
settings:
app_id: my-app
token:
from_secret: nomad_auth
Look at that. The plugin is an image. The settings are environment variables. There is no magic, no framework, no certification required. If you understand Docker, you already understand Woodpecker plugins.
Compare that to platforms that make you publish to a marketplace, pay a fee, or sign a partner agreement just to run your own code inside your own pipeline. Those platforms are not CI tools. They are app stores wearing a DevOps hat.
Go, Not Java
Now let's talk about the runtime, because this is where a lot of CI platforms embarrass themselves.
A lot of "modern" CI is built on the JVM or similarly heavy runtimes. That sounds fine in a demo. In production, it means your CI controller needs RAM like a small database and starts like a diesel engine in winter.
Woodpecker is written in Go. It is a single static binary. The server is light. The agents are light. The whole thing runs on hardware that would barely boot some competing controllers.
Why do we care? Because we run CI on real machines. Bare metal for us. Bare metal or private VMs for clients. Every watt and every gigabyte is ours to pay for.
The wins are not theoretical:
- The server idles at a fraction of the RAM a JVM-based CI would demand.
- Agents start fast because there is no JVM warm-up circus.
- We deploy it on Alpine Linux without dragging in a JDK.
- Cold starts are seconds, not minutes.
Don't forget, the controller is pure overhead. It is not compiling your code. It is not running your tests. It is just scheduling containers. The smaller it is, the more resources you have for actual work.
If your CI controller needs a garbage collector and a heap dump strategy, your CI controller is doing too much.
Simple Enough to Actually Read
Yes, I wrote that Infrastructure as YAML is Hell. I meant it. Most CI YAML is a fractal of nested conditionals, templating engines, vendor-specific syntax, and secrets that should have stayed in a real programming language.
Woodpecker's pipeline YAML is not that. It is short, flat, and explicit. You define steps. Each step runs a container. Steps run in order unless you group them otherwise. There is no inheritance pyramid. No custom DSL. No 47 levels of abstraction invented by someone who read too much Kubernetes documentation.
steps:
test:
image: golang:1.23-alpine
commands:
- go test ./...
build:
image: plugins/docker
settings:
repo: docker.kalvad.com/app
tags: latest
A junior engineer can read that and know what will happen. That is almost unheard of in CI tooling. The simplicity is not a missing feature. It is a deliberate design choice, and it pays off every time someone has to debug a build at midnight while the rest of the company is asleep.
The Real Reason We Stay
If I had to pick one reason we keep deploying Woodpecker, it would be this: it respects the operator.
It does not try to abstract Docker away from you. It does not hide your agents behind a managed queue you cannot inspect. It does not pretend that a JSON blob written in a web console is "configuration as code." It gives you a server, an agent, a YAML file, and a UI that shows logs without forcing you through three loading screens.
That respect compounds. Onboarding is fast. Debugging is fast. When something breaks, you know where to look.
In a consulting context, that is gold. We cannot afford to spend a day teaching a client's team the proprietary theology of yet another CI vendor. Woodpecker maps cleanly to things they already know: Git, Docker, Linux, YAML. The conversation is about their pipeline, not about the tool's ideology.
If This Sounds Hard, It Is Not For You
I am not going to sell Woodpecker to everyone. It is not a managed SaaS. It will not send you a reassuring invoice every month. You have to run it, update it, and know what a container is.
If your team's idea of troubleshooting is "restart the pod and pray," Woodpecker will not save you. Self-hosting anything will hurt until that changes.
If you want a support chat and a sales team to blame when things go wrong, Woodpecker is the wrong shape. It is infrastructure you own. The responsibility is yours.
And if you are welded to one Git host forever, the multi-forge advantage will not matter to you. You will still get the efficiency and the Docker plugin model, but you will not feel the full relief.
For everyone else, it is worth a serious look.
The Verdict
We run Woodpecker CI because it is the rare tool that gets all five things right at once:
- It talks to any forge, so your Git strategy stays yours.
- It is independent open source, so your builds stay inside your network.
- It extends with plain Docker containers, public or private, without asking permission.
- It is efficient because it is Go, not a JVM furnace.
- It is simple enough that the YAML actually makes sense.
Any one of those is nice. Together, they make Woodpecker the quiet default in our toolbox. We deploy it for ourselves. We deploy it for clients. We publish plugins and keep others private without jumping through corporate hoops. And we sleep better knowing the CI bill will not randomly double next quarter because a sales team needed to hit a number.
The CI market is loud, expensive, and increasingly user-hostile. Woodpecker is none of those things. That is exactly why we trust it.
If you have a problem and no one else can help. Maybe you can hire the Kalvad-Team.
Need a Real CI/CD Team?
Kalvad designs and operates self-hosted CI/CD pipelines for teams tired of slow shared runners and surprise invoices. We deploy Woodpecker on bare metal or behind your firewall, build the private plugins you need, and wire up the observability so you actually see what your builds do. If your pipeline crosses oceans, your compliance forbids public runners, or your bill no longer matches reality, we can plug in. Talk to our infrastructure team.
