Woodpecker CI: aktiver Drone-Fork als KMU-Standard für Gitea und Forgejo

Was ist Woodpecker CI?

Woodpecker CI ist ein Container-natives Continuous-Integration-System, 2019 als Community-Fork von Drone gestartet, nachdem die Lizenz-Politik bei Drone-Maintainer Brad Rydzewski Unklarheit erzeugte. Mittlerweile (Mai 2026) ist Woodpecker in Version 3.x ein eigenständiges, sehr aktives Projekt mit klarer Community-Governance – die Energie, die Drone unter Harness-Eigentum verloren hat, ist hier.

Lizenz: Apache 2.0 für Server und Runner. Keine Open-Core-Klauseln, keine proprietären Module. Vollständig self-host, ohne Sternchen – kostet null.

Architektur: Server-Binary (Go) plus mindestens ein Agent (Runner). Konfiguration über Environment-Variablen oder INI-Datei. Pipelines werden in .woodpecker.yml im Repo definiert. Container-natives Pipeline-Design: jeder Step läuft in einem eigenen Docker-Container. Runner-Typen: Docker (Standard), Kubernetes, Local-Exec, SSH.

Drone-Kompatibilität: bewusst hoch gehalten. .drone.yml-Dateien lassen sich mit minimalen Änderungen zu .woodpecker.yml umschreiben – gleicher kind/type/steps-Schema, gleiche Logik. Drone-Plugins (Docker-Images mit definiertem Input-Schema) funktionieren in Woodpecker direkt, ohne Anpassung. Damit ist eine Migration von Drone zu Woodpecker typischerweise ein halber Tag.

Git-Hoster-Integration: native Unterstützung für Gitea, Forgejo, GitHub, GitLab, Bitbucket, Gogs. Webhook-basiert – Push triggert Pipeline-Run. OAuth-Integration über den jeweiligen Hoster, Standard-Setup.

Mai 2026 Status: Woodpecker 3 stabilisiert die Plugin-Schnittstelle, bringt Multi-Pipeline-Workflows (mehrere .woodpecker.yml-Files pro Repo für parallele Builds), und verbessert die Secrets-Vault-Integration (HashiCorp Vault, AWS Secrets Manager). Community ist sehr aktiv – tägliche Commits, klare Release-Kadenz, lebhafte Discussions auf GitHub.

KMU-Default 2026: für Self-host-CI neben Gitea oder Forgejo ist Woodpecker die rationale Wahl. Drone-Erfahrung ist transferierbar, Lernkurve niedrig, Community lebt.

Warum es zählt

Woodpecker löst für KMU mit Self-host-Git-Setup das CI-Problem: schlank, kostenlos, eng integriert mit Gitea und Forgejo.

KMU-Tauglichkeit (Mai 2026): Setup ist eine docker-compose-Datei mit Server und einem Runner. Konfiguration über wenige ENV-Variablen, OAuth-App im Git-Hoster anlegen, fertig. Lernkurve flach, weil Pipeline-Syntax nahe an Drone (und damit nahe an dem, was viele DevOps-Engineers ohnehin kennen) liegt. Innerhalb eines halben Tages ist eine produktive CI-Plattform aufgesetzt.

CH-DSG-Fit: vollständig self-host auf Hetzner Falkenstein. Apache 2.0 ohne Lock-in. Code, Pipelines, Build-Artefakte, Secrets – alles bleibt on-premise. Für Treuhand- oder Anwaltskanzlei-Mandate ist Woodpecker eine konforme Wahl.

Lizenz und Kosten: Apache 2.0, null pro User-Gebühr, null pro Build-Limit. GitHub Actions ist auf gitlab.com bei Free-Plan auf 2000 Minuten/Monat begrenzt – bei aktiver Entwicklung schnell aufgebraucht. GitLab CI Free-Tier hat 400 Minuten/Monat. Woodpecker self-host: unbegrenzt, nur Hardware-Kosten (Hetzner CX22 ca. CHF 6/Monat).

Community-Energie: das wohl wichtigste Argument 2026. Wer eine CI-Plattform für die nächsten 3-5 Jahre wählt, sollte ein aktives Projekt wählen. Drone hat unter Harness die Geschwindigkeit verloren – Woodpecker hat sie aufgenommen. Sicherheits-Patches kommen schnell, neue Features kommen regelmässig (Multi-Pipeline-Workflows, verbesserte Secrets-Integration, OpenTelemetry-Support für Pipeline-Tracing).

Migration-Pfad: wer Drone hat, wechselt zu Woodpecker mit überschaubarem Aufwand. Wer Jenkins hat und auf Container-native umstellen will, kann Woodpecker als modernen Nachfolger prüfen – die Pipeline-Syntax ist deutlich klarer als Jenkinsfile (Groovy).

Integration mit Gitea Actions: ein wichtiger Punkt. Seit 2023 hat Gitea eigene Actions (GitHub-Actions-kompatibel). Woodpecker und Gitea Actions sind komplementär – viele KMU nutzen Gitea Actions für einfache Workflows (Build, Test) und Woodpecker für komplexere Multi-Stage-Pipelines. Beide koexistieren technisch problemlos.

Wie es funktioniert

Woodpecker besteht aus Server und Agent. Server orchestriert, Agent führt Jobs aus.

docker-compose.yml-Beispiel mit Gitea als Git-Hoster:

```yaml services: woodpecker-server: image: woodpeckerci/woodpecker-server:v3 ports: ["8000:8000", "9000:9000"] volumes: - woodpecker-server-data:/var/lib/woodpecker environment: WOODPECKER_OPEN: false WOODPECKER_HOST: https://ci.firma.ch WOODPECKER_GITEA: true WOODPECKER_GITEA_URL: https://git.firma.ch WOODPECKER_GITEA_CLIENT: ${GITEA_OAUTH_CLIENT_ID} WOODPECKER_GITEA_SECRET: ${GITEA_OAUTH_CLIENT_SECRET} WOODPECKER_AGENT_SECRET: ${AGENT_SECRET} WOODPECKER_ADMIN: admin restart: unless-stopped woodpecker-agent: image: woodpeckerci/woodpecker-agent:v3 depends_on: [woodpecker-server] environment: WOODPECKER_SERVER: woodpecker-server:9000 WOODPECKER_AGENT_SECRET: ${AGENT_SECRET} WOODPECKER_MAX_WORKFLOWS: 4 volumes: - /var/run/docker.sock:/var/run/docker.sock - woodpecker-agent-data:/etc/woodpecker restart: unless-stopped volumes: woodpecker-server-data: woodpecker-agent-data: ```

Gitea-Seite: OAuth-App in User-Settings > Applications anlegen, Client ID und Secret in das Woodpecker .env eintragen. Woodpecker holt sich Repository-Liste via Gitea-API, User aktivieren Repos per Klick.

Pipeline-Beispiel (.woodpecker.yml):

```yaml steps: build: image: node:20 commands: - npm ci - npm run build test: image: node:20 commands: - npm test deploy: image: alpine/git environment: SSH_KEY: from_secret: deploy_key commands: - apk add openssh - mkdir -p ~/.ssh && echo "$SSH_KEY" > ~/.ssh/id_rsa && chmod 600 ~/.ssh/id_rsa - ssh -o StrictHostKeyChecking=no deploy@server "cd /app && git pull && pm2 restart all" when: branch: main ```

Secrets-Management: in der Woodpecker-UI pro Repo definierbar. Zugriff via from_secret in YAML. Alternativ HashiCorp Vault Plugin für zentrale Secrets-Verwaltung in grösseren Setups.

Multi-Pipeline-Workflows (v3-Feature): mehrere .woodpecker.yml-Files in einem Repo (zum Beispiel .woodpecker/build.yml, .woodpecker/test.yml, .woodpecker/deploy.yml) – laufen parallel oder mit dependencies. Damit lassen sich komplexe Pipelines klar strukturieren statt in einer riesigen Datei zu landen.

Agent-Skalierung: pro Agent WOODPECKER_MAX_WORKFLOWS=N – N parallele Jobs. Mehrere Agent-Container können sich am Server registrieren – horizontale Skalierung. Bei Fairlane läuft ein Agent mit Max 4 – reicht für 20+ Pipelines/Tag.

Setup in 5 Schritten

1. 01docker-compose mit woodpeckerci/woodpecker-server:v3 und woodpeckerci/woodpecker-agent:v3, Agent-Secret generieren.
2. 02OAuth-App im Gitea/Forgejo/GitHub anlegen, Client ID + Secret in das Woodpecker .env eintragen, Server starten.
3. 03nginx-Reverse-Proxy auf ci.firma.ch mit Lets-Encrypt-Zertifikat, gRPC-Port 9000 zwischen Server und Agent ggf. über Docker-Netzwerk geschützt.
4. 04Erstes Repository in Woodpecker-UI aktivieren, .woodpecker.yml mit Build-Step schreiben, Push triggern, Logs in der UI verifizieren.
5. 05Secrets in der UI pro Repo definieren (deploy_key, registry_password, api_token), Pipeline auf main-Branch deploy aktivieren.

Wann Woodpecker einsetzen

Woodpecker ist die richtige Wahl, wenn (a) das Setup Self-host-Git mit Gitea oder Forgejo hat, (b) CI-Pipelines container-nativ sein sollen, (c) ein schlankes System gewünscht ist (keine GitLab-Komplexität), (d) Drone-Erfahrung im Team vorhanden ist oder leicht übertragbar.

Konkrete KMU-Fälle: Eine Treuhand-Plattform mit Gitea für Code und Woodpecker für Build/Deploy von Bexio-Integrationen. Eine Anwaltskanzlei mit selbst-entwickelter Mandanten-Plattform – Gitea hostet Code, Woodpecker baut Container und deployt nach Push auf main. Eine SaaS-Boutique mit 5-15 Entwicklern – Gitea plus Woodpecker plus Gitea-eigene Container-Registry deckt die gesamte Software-Lieferkette ab.

Migration von Drone: typischer Fall im Mai 2026. .drone.yml zu .woodpecker.yml umschreiben (sehr ähnliches Schema), Secrets in Woodpecker-UI neu anlegen, Webhooks im Git-Hoster umstellen. Halber Tag Arbeit für 20-50 Pipelines.

Auch sinnvoll als CI für Open-Source-Projekte, die ohne GitHub Actions auskommen wollen – Codeberg-Projekte zum Beispiel nutzen Woodpecker als Standard-CI.

Wann NICHT

Woodpecker ist die falsche Wahl, wenn (a) das Setup bereits GitLab CE/EE nutzt – integriertes GitLab CI ist tighter, (b) GitHub Actions-Marketplace-Plugins zentral gebraucht werden – Woodpecker hat keinen Marketplace, (c) extrem komplexe Multi-Cloud-Deployments nötig sind – Jenkins oder spezialisierte Tools wie ArgoCD fügen sich besser ein, (d) das Team auf eine vollständige DevOps-Plattform (Issues+CI+Registry+Security) hofft – Woodpecker ist nur CI.

Fallen: Woodpecker-Agent ohne Resource-Limits laufen lassen – ein fehlerhafter Build kann den Host füllen. Memory- und CPU-Limits pro Agent setzen. Secrets in Klartext in .woodpecker.yml schreiben – immer über UI-Secrets oder Vault-Plugin. Docker-Socket-Mount ohne Bewusstsein einsetzen – gibt dem Runner Root-Äquivalente Rechte am Host. Bei Mandanten-Setups via Docker-in-Docker oder Rootless-Docker isolieren.

Nicht-empfohlene Muster: Woodpecker plus Drone parallel betreiben – beide tun dasselbe, zwei UIs sind Konfigurations-Schmerz. Woodpecker ohne TLS-Reverse-Proxy direkt ins Internet exponieren – Brute-Force auf /login. Pipeline-YAML als Geheimnis betrachten – sollte versioniert und reviewable im Repo liegen.

Vor- und Nachteile

Häufige Fragen

Verwandte Themen

Quellen

1. Woodpecker CI – Documentation · 2026-05
2. Woodpecker CI – GitHub repository · 2026-04
3. Woodpecker 3 – Multi-pipeline workflows · 2026-03
4. Codeberg – Woodpecker as default CI · 2026-04