Drone CI: Container-natives CI-System mit reduzierter Community-Aktivität

Was ist Drone CI?

Drone CI ist ein Container-natives Continuous-Integration-System, 2014 von Brad Rydzewski gestartet und seitdem ein Pionier im Bereich CI-on-Docker. Die Kernidee: jeder Pipeline-Schritt läuft in einem eigenen Docker-Container, beschrieben in einer einfachen YAML-Datei. Setup-Aufwand niedrig, Lernkurve flach.

Geschichte und Status: Drone wurde 2020 von Harness (eine US-DevOps-Firma) übernommen. Seitdem fokussiert Harness die kommerzielle Harness-Plattform (proprietär) und Drone OSS bekommt weniger Aufmerksamkeit. Mai 2026 ist Drone unter Apache-2.0-Lizenz, das Repository auf github.com/harness/drone weiterhin gepflegt, aber die Release-Kadenz hat deutlich nachgelassen – kein Major-Release in 2025, kleinere Patches in 2025-2026. Die Community-Energie liegt mittlerweile bei Woodpecker (siehe separate Topic-Seite).

Architektur: Drone-Server (Go-Binary) plus mindestens ein Drone-Runner. Konfiguration zentral in der UI oder per ENV-Variablen. Pipelines werden in .drone.yml im Repo definiert. Runner-Typen: Docker (Standard), Kubernetes, SSH, Exec (Shell), Digital-Ocean. Jeder Pipeline-Schritt läuft als ephemerer Container – kein State zwischen Steps ausser über Volumes.

Lizenz: Apache 2.0 für den Open-Source-Kern. Drone Enterprise (zusätzliche Features) ist proprietär und unter Harness-Lizenz. Für Standard-KMU-Nutzung reicht der OSS-Kern.

Funktionsumfang: Multi-Stage-Pipelines, Matrix-Builds, Secrets-Vault (intern oder external wie HashiCorp Vault), Plugin-System (Marketplace mit hunderten Plugins), Webhook-Integration zu Git-Hostern (GitHub, GitLab, Gitea, Bitbucket). Drone integriert sich gut mit allen Standard-Git-Plattformen.

Mai 2026 Verdict: Drone ist funktional solide, aber die Community-Momentum-Frage ist real. Wer Mai 2026 ein neues CI-System wählt, sollte Woodpecker (Drone-Fork, sehr aktiv) statt Drone bevorzugen. Wer Drone bereits in Produktion hat, kann ohne Eile bleiben – Pipelines sind weitgehend identisch und eine spätere Migration zu Woodpecker kostet typischerweise einen halben Tag.

Warum es zählt

Drone hat den Container-nativen CI-Ansatz populär gemacht – viele moderne CI-Systeme (Woodpecker, Gitea Actions, sogar GitLab CI in Teilen) zeigen Drone-DNA. Auch wenn Drone selbst Mai 2026 keine erste Wahl mehr ist, ist das Verständnis seines Konzepts relevant.

Container-Native als Idee: Drone war 2014 eines der ersten CI-Systeme, das Docker als Pipeline-Primitiv nutzt. Statt einen langlebigen Build-Agent mit installierten Tools zu betreiben (Jenkins-Modell), spawnt Drone für jeden Step einen frischen Container mit dem benötigten Image. Vorteil: keine State-Drift zwischen Builds, reproduzierbare Pipelines, leicht zu skalieren. Nachteil: Docker-Pull-Overhead für jeden Job (mit Caches lösbar).

CH-DSG-Fit: Drone self-host läuft auf Hetzner Falkenstein problemlos. Apache 2.0 ohne Klauseln, Code bleibt on-premise. Für Treuhand- oder Anwaltskanzlei-Mandate ist Drone als Toolchain konform – die Frage ist nur, ob es 2026 noch die strategische Wahl ist.

KMU-Tauglichkeit Mai 2026 – bedingt: Wer Drone bereits in Produktion hat, bleibt vorerst. Die Pipelines laufen, Bugs sind selten, Sicherheits-Patches kommen sporadisch. Wer Mai 2026 neu beginnt, sollte Woodpecker wählen – fast identische YAML, aktivere Community, klarere Zukunft. Migration zu Woodpecker später ist nicht riskant, aber wäre ein vermeidbarer Aufwand.

Wann Drone weiterhin sinnvoll bleibt: (1) bestehende Drone-Pipelines mit komplexen Plugins, deren Äquivalent in Woodpecker noch fehlt, (2) Kubernetes-CI-Setups mit dem stabilen drone-runner-kube, (3) Setups mit Drone Enterprise (Harness-Support) und Wartungsvertrag.

Strategischer Punkt: Harness als Mutter-Firma kommerzialisiert die Hauptplattform. Das bedeutet: OSS-Drone wird vermutlich nicht "sterben", aber auch keine dramatischen Features bekommen. Stabilisierungs-Pfad mit kleinen Patches. Für ein KMU, das langfristig auf eine aktive Community angewiesen ist, ist Woodpecker das ehrlichere Tool.

Wie es funktioniert

Drone besteht aus zwei Hauptkomponenten: Server und Runner.

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

```yaml services: drone-server: image: drone/drone:2 ports: ["8080:80"] volumes: - drone-data:/data environment: DRONE_GITEA_SERVER: https://git.firma.ch DRONE_GITEA_CLIENT_ID: ${GITEA_OAUTH_CLIENT_ID} DRONE_GITEA_CLIENT_SECRET: ${GITEA_OAUTH_CLIENT_SECRET} DRONE_RPC_SECRET: ${RPC_SECRET} DRONE_SERVER_HOST: drone.firma.ch DRONE_SERVER_PROTO: https DRONE_USER_CREATE: username:admin,admin:true restart: unless-stopped drone-runner: image: drone/drone-runner-docker:1 depends_on: [drone-server] environment: DRONE_RPC_HOST: drone-server DRONE_RPC_PROTO: http DRONE_RPC_SECRET: ${RPC_SECRET} DRONE_RUNNER_CAPACITY: 2 DRONE_RUNNER_NAME: runner-01 volumes: - /var/run/docker.sock:/var/run/docker.sock restart: unless-stopped volumes: drone-data: ```

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

Pipeline-Beispiel (.drone.yml):

```yaml kind: pipeline type: docker name: default

steps: - name: build image: node:20 commands: - npm ci - npm run build - name: test image: node:20 commands: - npm test - name: deploy image: alpine/git environment: SSH_KEY: from_secret: deploy_key commands: - apk add openssh - echo "$SSH_KEY" > /tmp/key && chmod 600 /tmp/key - ssh -i /tmp/key deploy@server "cd /app && git pull && pm2 restart all" when: branch: [main] ```

Secrets werden in der Drone-UI pro Repo definiert, nicht in YAML. from_secret in YAML referenziert sie.

Runner-Skalierung: pro Runner DRONE_RUNNER_CAPACITY=N – N parallele Jobs. Mehrere Runner-Container können sich am Server registrieren, damit horizontale Skalierung. Für KMU mit 5-20 Pipelines/Tag reicht ein Runner mit Capacity 2-4.

Plugin-System: Drone-Plugins sind einfach Docker-Images mit definiertem Eingabe-Schema (Environment-Variablen). Beispiele: docker (Build und Push), slack (Notification), s3-upload, downstream (Multi-Project-Trigger). Hunderte Plugins im Drone-Marketplace verfügbar.

Setup in 5 Schritten (oder Migration zu Woodpecker)

1. 01Prüfen ob Neuanlage nötig – Mai 2026 ist Woodpecker die strategischere Wahl. Bestehendes Drone bleiben, neue Setups Woodpecker.
2. 02Falls Drone weiterhin: docker-compose mit drone/drone:2 plus drone-runner-docker, OAuth-App im Gitea/GitLab/GitHub anlegen, RPC-Secret generieren.
3. 03nginx-Reverse-Proxy auf drone.firma.ch mit Lets-Encrypt-Zertifikat, Rate-Limit auf /login.
4. 04Erstes Repository in Drone-UI aktivieren, .drone.yml mit Build-Step schreiben, Pipeline triggern, Logs in der UI verifizieren.
5. 05Auto-Update via Watchtower oder Cron monatlich, Telegram-Alert bei fehlschlagenden Pipelines, Backup des Drone-Data-Volume.

Wann Drone (noch) einsetzen

Drone ist Mai 2026 die richtige Wahl in spezifischen Konstellationen: (a) bestehende Drone-Installation mit funktionierenden Pipelines – Migration ist Aufwand ohne sofortigen Mehrwert, (b) Kubernetes-CI mit drone-runner-kube, der weiterhin stabil ist, (c) Setup mit Drone-Enterprise-Support-Vertrag via Harness.

Für Neu-Installationen Mai 2026: Woodpecker wählen statt Drone. Funktional fast identisch, Community deutlich aktiver, klarere Zukunft.

Konkrete Bestands-Fälle: Ein KMU, das seit 2022 Drone mit Gitea betreibt – 50 Repos, 30 Pipelines pro Tag. Migration zu Woodpecker wäre ein halber Tag Arbeit, aber kein dringender Mehrwert. Bleiben ist OK. Eine Kubernetes-CI-Plattform, die drone-runner-kube produktiv nutzt – der Kubernetes-Runner ist stabiler als der Woodpecker-Äquivalent (Stand Mai 2026), bleiben ist die rationale Wahl.

Wichtig: Drone weiterhin patchen. Security-Patches kommen zwar sporadisch, aber sie kommen. Manueller Update-Cron monatlich oder die Drone-Images automatisch via Watchtower aktualisieren.

Wann NICHT

Drone ist die falsche Wahl, wenn (a) das Setup neu gebaut wird Mai 2026 – Woodpecker ist die strategisch bessere Wahl, (b) sehr spezifische neue Plugins gewünscht sind – die Drone-Plugin-Community ist eingeschlafen, (c) Compliance-Anforderungen schnelle Sicherheits-Patches verlangen – Drone-Patches sind sporadisch, (d) das Team auf Innovation/Features wartet – die wird nicht kommen.

Fallen: Drone ohne regelmässige Updates laufen lassen – Security-Patches sind sporadisch, aber wichtig. Drone-Plugins aus dem Marketplace nutzen, ohne deren Maintainer-Status zu prüfen – viele Plugins sind unmaintained. Drone Enterprise lizenzieren, ohne den Support-Umfang von Harness zu prüfen – Harness fokussiert die Haupt-Plattform, OSS-Drone bekommt weniger.

Nicht-empfohlene Muster: neue CI-Strategie aufbauen mit Drone als zentraler Komponente – Migrations-Aufwand später ist unnötig. Drone und Woodpecker parallel betreiben – beide Engines koexistieren technisch, aber zwei UIs und zwei Pipeline-Sprachen sind Konfigurations-Schmerz. Drone als CI für GitLab wählen – GitLab CI integriert ist deutlich tighter.

Vor- und Nachteile

Häufige Fragen

Verwandte Themen

Quellen

1. Drone CI – Documentation · 2026-05
2. Drone – GitHub repository (Harness) · 2026-04
3. Harness – Drone OSS stewardship · 2026-03
4. Drone to Woodpecker migration guide · 2026-04