Woodpecker CI, ganz ohne SaaS im Weg

Server und Agents auf einer kleinen Maschine in Prag oder Covilhã, verdrahtet mit Ihrer eigenen Forge - die Variante von CI, bei der nichts an der Pipeline eine Infrastruktur verlässt, die Sie benennen können.

Tier III zertifiziert ISO 9001 ISO/IEC 27001 ISO 14001 DSGVO-konform

Für wen es ist

Ein Team, das ohnehin schon alles andere selbst hostet

Die Forge gehört Ihnen, die Registry gehört Ihnen, das Deploy-Ziel gehört Ihnen - und CI ist der eine Hop, der das Haus noch verlässt, ausgerechnet der Hop, der den Quellcode hält.

Eine Drone-Installation, die stehen geblieben ist

Woodpecker ist der Fork, der weiterging und Apache-2.0 blieb. Die Migration ist klein; die Frage ist, worauf es laufen soll.

Ein kleines Team, das will, dass CI langweilig ist

Zwei Container, eine YAML-Datei pro Repository, keine Steuerungsebene zum Lernen und kein Minutenzähler zum Beobachten. Es braucht nur einen Ort zum Leben.

Was diese Form Ihnen gibt

  • Server und Agent als zwei Container auf einem Host, klein genug, dass CI aufhört, ein Infrastrukturprojekt zu sein.
  • Jede Forge, die Woodpecker unterstützt - GitHub, GitLab, Gitea, Forgejo oder Bitbucket - auch eine, die Sie selbst im selben Netz betreiben.
  • Agents später als eigene Hosts dazu, alle am selben Server authentifiziert, wenn eine Maschine nicht mehr reicht.
  • Durchgängig Apache-2.0, sodass nichts in der Pipeline davon abhängt, dass ein Anbieter eine kostenlose Stufe beibehält.
  • Eine statische IPv4 aus AS204057, damit Forge-Webhook und Deploy-Ziel beide eine Adresse zum Vertrauen haben.
  • Lokales NVMe für Workspace und Docker-Layer-Cache, warm zwischen den Pipelines.

Nach dem dimensioniert, was die Pipeline tatsächlich tut

Woodpecker selbst ist leicht: der Server ist ein kleiner Go-Prozess mit eingebetteter Datenbank, bis Sie ihn auf Postgres richten, und der Agent ist ein Supervisor, der Container startet. Was den Host verbraucht, ist der Build, genau wie bei jedem anderen Runner - dimensionieren Sie die Maschine also nach dem schwersten Job und geben Sie der Platte Raum für den Layer-Cache, der die zweite Pipeline schnell macht. Die Einstiegsgröße unten trägt Server und Agent zusammen bequem für ein kleines Team. Der eine ehrliche Vorbehalt: ein fester Monats-Host kostet in einer Woche ohne Pushes dasselbe, gehostete CI-Minuten kosten dann nichts.

Ein erster Runner
15.00
pro Monat

Jetzt bestellen
Server und ein Agent zusammen
2 vCPU
4 GB RAM
64 GB NVMe
1 statische IPv4
1 wöchentliches Backup inklusive
Ein Team-Runner
19.96
pro Monat

Jetzt bestellen
Server plus ein paar parallele Workflows
4 vCPU
8 GB RAM
120 GB NVMe
1 statische IPv4
1 wöchentliches Backup inklusive
Ein voller Pool
39.90
pro Monat

Jetzt bestellen
ein eigener Agent-Host neben dem Server
8 vCPU
16 GB RAM
240 GB NVMe
1 statische IPv4
1 wöchentliches Backup inklusive

Woodpecker CI mit Docker Compose installieren

Server und Agent auf einem Host, in diesem Beispiel mit GitHub verdrahtet. Tauschen Sie den Forge-Block gegen die Variablen für Gitea, Forgejo, GitLab oder Bitbucket, wenn Ihre Forge eine davon ist.

  1. Docker und Compose installieren

    sudo apt install docker.io docker-compose-v2
    sudo systemctl enable --now docker

    Beide Container und jeder Pipeline-Schritt laufen auf diesem Daemon, das ist also die einzige Abhängigkeit, die der Host braucht.

  2. Eine OAuth-Anwendung in Ihrer Forge registrieren

    # GitHub: Settings -> Developer settings -> OAuth Apps -> New OAuth App
    # Homepage URL:     https://ci.example.com
    # Authorization callback: https://ci.example.com/authorize

    Woodpecker meldet Benutzer über die Forge an und liest mit dieser Berechtigung Repositories, die zurückgegebene Client-ID und das Secret sind also das, was der Server braucht. Jede unterstützte Forge hat ein entsprechendes Formular.

  3. Das gemeinsame Agent-Secret erzeugen

    openssl rand -hex 32

    Server und Agents authentifizieren sich mit dieser Zeichenkette gegeneinander, und die Woodpecker-Dokumentation nennt genau diesen Befehl zu ihrer Erzeugung. Halten Sie sie aus der Compose-Datei heraus - legen Sie sie in eine .env-Datei daneben.

  4. Die Compose-Datei schreiben

    services:
      woodpecker-server:
        image: woodpeckerci/woodpecker-server:v3
        ports:
          - 8000:8000
        volumes:
          - woodpecker-server-data:/var/lib/woodpecker/
        environment:
          - WOODPECKER_OPEN=true
          - WOODPECKER_HOST=${WOODPECKER_HOST}
          - WOODPECKER_GITHUB=true
          - WOODPECKER_GITHUB_CLIENT=${WOODPECKER_GITHUB_CLIENT}
          - WOODPECKER_GITHUB_SECRET=${WOODPECKER_GITHUB_SECRET}
          - WOODPECKER_AGENT_SECRET=${WOODPECKER_AGENT_SECRET}
      woodpecker-agent:
        image: woodpeckerci/woodpecker-agent:v3
        command: agent
        restart: always
        depends_on:
          - woodpecker-server
        volumes:
          - woodpecker-agent-config:/etc/woodpecker
          - /var/run/docker.sock:/var/run/docker.sock
        environment:
          - WOODPECKER_SERVER=woodpecker-server:9000
          - WOODPECKER_AGENT_SECRET=${WOODPECKER_AGENT_SECRET}
    volumes:
      woodpecker-server-data:
      woodpecker-agent-config:

    Das ist das Beispiel von upstream. WOODPECKER_HOST ist die öffentliche URL, die Benutzer und Webhooks erreichen, Port 8000 ist die Weboberfläche und 9000 der gRPC-Port, auf dem sich Agents verbinden. WOODPECKER_OPEN=true lässt jeden mit einem Forge-Konto anmelden - schalten Sie es ab, sobald Ihr Team registriert ist.

  5. Starten

    docker compose up -d
    docker compose logs -f woodpecker-agent

    Der Agent verbindet sich mit dem gemeinsamen Secret zum Server und registriert sich beim ersten Kontakt selbst. Läuft er in einer Authentifizierungsschleife, stimmen die beiden Secrets nicht überein - meist, weil die .env-Datei nicht gelesen wurde.

  6. Eine Pipeline hinzufügen

    when:
      - event: push
    
    steps:
      - name: smoke
        image: alpine:latest
        commands:
          - cat /etc/os-release
          - echo "built on $CI_MACHINE"

    Committen Sie das als .woodpecker.yaml, aktivieren Sie das Repository in der Weboberfläche, damit der Webhook angelegt wird, und pushen Sie. Jeder Schritt ist ein Container - deshalb braucht der Agent den Docker-Socket.

Geprüft anhand der offiziellen Dokumentation am 2026-08-15 — Quelle lesen

Was wir nicht sind

  • Wir sind nicht das Woodpecker-Projekt. Woodpecker CI ist ein unabhängiges Apache-2.0-Projekt und nichts hier ist von ihm unterstützt. Wir verkaufen die Maschine, auf der es läuft.
  • Wir hosten Ihre Forge auf dieser Seite nicht. Gitea, Forgejo oder ein selbstverwaltetes GitLab daneben ist ein unkomplizierter zweiter Server, aber eine andere Größe und ein anderes Angebot.
  • Wir schreiben Ihre Pipelines nicht. Das YAML gehört Ihnen; der Host, das Netz und die Adresse gehören uns.
  • Woodpecker wird nicht standardmäßig für Sie verwaltet. Sie betreiben die zwei Container, oder Sie buchen unsere Administration dazu und wir halten sie aktuell und gesichert.
  • Den Docker-Socket in den Agent zu hängen gibt Pipeline-Schritten sehr viel Macht über den Host. So funktioniert dieses Design, und es ist ein Grund, den Agent auf einer Maschine zu halten, die sonst nichts tut.

Die Teile, die Teams zu spät entdecken

  • WOODPECKER_AGENT_SECRET hat zwei Betriebsarten. Derselbe Wert auf Server und allen Agents ist ein System-Token; ein Token pro Agent entsteht, indem Sie den Agent zuerst in der Oberfläche registrieren - was Sie wollen, sobald mehr als ein Team den Host erreichen kann.
  • Jede sensible Variable hat auch eine _FILE-Form, sodass das Secret aus einer eingehängten Datei gelesen werden kann, statt in der Compose-Datei oder der Umgebung zu stehen.
  • Die eingebettete Datenbank ist für den Anfang in Ordnung und trotzdem das, was zuerst umzieht. Richten Sie den Server auf Postgres, bevor die Installation für irgendjemanden wichtig wird.
  • WOODPECKER_OPEN=true heißt, jedes Konto in der verbundenen Forge kann sich anmelden. Am ersten Tag bequem, am dreißigsten falsch.
  • Der Agent braucht den Docker-Socket, weil jeder Schritt ein Container ist - was der Pipeline faktisch root auf diesem Host gibt. Halten Sie den Agent-Host langweilig und getrennt.
  • WOODPECKER_HOST muss die URL sein, die die Forge tatsächlich erreichen kann, nicht die interne - der Webhook wird dagegen angelegt, und eine private Adresse dort erzeugt Pipelines, die nie auslösen.

Gehostete CI-Minuten gegen einen eigenen Runner

Gehostete CI-Minuten des AnbietersEin Runner bei DCXV
Wofür Sie zahlenJede Minute jedes Jobs, so lange das Projekt existiertEin fester Monats-Host, was die Pipeline in dem Monat auch tut
Ein Build, der langsamer wirdKostet jeden Monat mehr, in dem er langsam bleibtKostet nichts extra - die Maschine ist bereits bezahlt
Docker-Layer-CacheBei jedem Job kalt, sofern Sie ihn nicht selbst hoch- und herunterladenWarm auf lokalem NVMe, zwischen Jobs und zwischen Tagen
ParallelitätEine Tarifstufe, die Sie hochbuchenEine Zahl, die Sie in Ihrer eigenen Konfigurationsdatei setzen
Wo der Checkout landetEine geteilte Flotte, oft in einer Region, die Sie nicht festlegen könnenEine Maschine in Prag oder Covilhã, unter einem zyprischen Vertrag
Ausgehende AdresseEin großer geteilter Bereich, den nichts freigeben kannEine statische IPv4 aus AS204057, Ihre zum Freigeben
Was die Maschine tragen kannWas das Runner-Image zufällig mitbringtJede Toolchain, Lizenz oder jedes Fixture-Set, das Sie einmal installieren

So kommt das auf Ihrem Host in Gang

1

Sagen Sie, was die Pipeline tut

Der schwerste Job, den Sie heute fahren, wie viele davon gleichzeitig laufen sollen und ob Container-Images gebaut werden. Das reicht, um einen Host ohne Raten zu dimensionieren.

2

Wir übergeben die Maschine

Prag oder Covilhã, Root-Zugang und eine statische IPv4, in unter zehn Minuten. Bringen Sie Ihr eigenes Image mit, wenn der Runner schon darin steckt.

3

Folgen Sie der Anleitung auf dieser Seite

Es ist die Abfolge des Herstellers, aus dessen aktueller Dokumentation genommen statt aus einem Blogbeitrag, und sie dauert auf einem sauberen Host wenige Minuten.

4

Snapshot machen, dann den zweiten dazunehmen

Machen Sie einen Snapshot, sobald die erste Pipeline grün ist - dann ist die nächste Maschine eine Wiederherstellung statt eines Neuaufbaus. Ein Pool wächst durch weitere Hosts, nicht dadurch, einen riesig zu machen.

Warum uns wählen

  • Tier-III-zertifizierte Einrichtungen, 99,982 % Facility-SLA
  • Eigenes Netz, AS204057, IPv4 und IPv6 Dual-Stack
  • Support 24/7/365 mit rund 10 Minuten durchschnittlicher Reaktionszeit
  • Zyprische Gesellschaft, EU-Gerichtsbarkeit, DSGVO-konform seit 2007

FAQ

- Was ist Woodpecker CI?

Eine leichtgewichtige CI-Engine unter Apache-2.0, aus Drone geforkt, die als Server plus ein oder mehrere Agents läuft. Jeder Pipeline-Schritt ist ein Container, Pipelines sind eine YAML-Datei im Repository, und die Anmeldung läuft über Ihre Forge. Unterstützt werden GitHub, GitLab, Gitea, Forgejo und Bitbucket, auch selbst betriebene Instanzen

- Wie installiere ich Woodpecker CI?

Docker Compose ist der dokumentierte Weg: ein Container woodpecker-server mit Port 8000 und ein Container woodpecker-agent mit eingehängtem Docker-Socket, die sich ein mit openssl rand -hex 32 erzeugtes Secret teilen, dazu Client-ID und Secret der OAuth-Anwendung Ihrer Forge. Die Compose-Datei von upstream und die Schritte drumherum stehen auf dieser Seite

- Was ist WOODPECKER_AGENT_SECRET und wie erzeuge ich es?

Es ist das gemeinsame Secret, mit dem sich Server und Agents authentifizieren, und die Woodpecker-Dokumentation nennt openssl rand -hex 32 zu seiner Erzeugung. Denselben Wert überall zu setzen macht daraus ein System-Token; den Agent zuerst in der Oberfläche zu registrieren gibt diesem Agent stattdessen ein eigenes Token - was Sie wollen, sobald mehr als ein Team den Host erreichen kann. Jede sensible Variable hat auch eine _FILE-Form, sodass der Wert aus einer eingehängten Datei gelesen werden kann

- Welche Servergröße braucht Woodpecker?

Die Software selbst ist leicht - der Server ist ein kleiner Go-Prozess mit eingebetteter Datenbank, bis Sie ihn auf Postgres richten, und der Agent ist ein Supervisor, der Container startet. Was die Maschine verbraucht, ist der Build. 2 vCPU, 4 GB und 64 GB NVMe tragen Server und Agent zusammen für ein kleines Team; nehmen Sie einen eigenen Agent-Host, sobald sich Pipelines stauen

- Warum braucht der Agent den Docker-Socket?

Weil jeder Pipeline-Schritt ein Container ist, den der Agent auf dem Daemon des Hosts startet. Das gibt Pipeline-Schritten faktisch root auf dieser Maschine, was das Design ist und keine Fehlkonfiguration - und es ist der Grund, den Agent auf einem Host zu halten, der sonst nichts tut, was billig ist, wenn eine zweite Maschine 15 EUR im Monat kostet

- Meine Pipelines lösen nie aus. Was ist falsch?

In neun von zehn Fällen ist es WOODPECKER_HOST. Dieser Wert ist die öffentliche URL, die die Forge beim Anlegen des Webhooks verwendet - eine interne Adresse dort erzeugt eine Installation, die gesund aussieht und nie einen Push empfängt. Der zweite häufige Fall ist WOODPECKER_OPEN=true, kein Auslöseproblem, aber es heißt, dass jedes Konto in Ihrer Forge sich anmelden kann - am ersten Tag bequem, am dreißigsten falsch

Wenn Sie Hilfe benötigen oder zusätzliche Fragen haben, wenden Sie sich bitte an die Manager oder schreiben Sie an das Support-Team unter support@dcxv.com

Bereit anzufangen?

Monatliche Abrechnung, keine Einrichtungsgebühr, keine Bindung

Cloud-Server ab 15 €/Mon.