Drone CI: container-native CI with reduced community activity

What is Drone CI?

Drone CI is a container-native continuous integration system, started in 2014 by Brad Rydzewski and a pioneer in CI-on-Docker. Core idea: every pipeline step runs in its own Docker container, described in a simple YAML file. Low setup effort, gentle learning curve.

History and status: Drone was acquired in 2020 by Harness (a US DevOps company). Since then Harness focuses on the commercial Harness platform (proprietary) and Drone OSS receives less attention. May 2026: Drone is still under Apache 2.0, the repository on github.com/harness/drone still maintained, but the release cadence has dropped clearly – no major release in 2025, smaller patches through 2025-2026. Community energy now sits with Woodpecker (see its own topic page).

Architecture: Drone server (Go binary) plus at least one Drone runner. Configuration central in the UI or via env vars. Pipelines are defined in .drone.yml in the repo. Runner types: Docker (default), Kubernetes, SSH, Exec (shell), Digital Ocean. Each pipeline step runs as an ephemeral container – no state between steps except via volumes.

Licence: Apache 2.0 for the open-source core. Drone Enterprise (extra features) is proprietary under the Harness licence. For standard SME use, the OSS core is enough.

Feature scope: multi-stage pipelines, matrix builds, secrets vault (internal or external like HashiCorp Vault), plugin system (marketplace with hundreds of plugins), webhook integration to Git hosters (GitHub, GitLab, Gitea, Bitbucket). Drone integrates well with all standard Git platforms.

May 2026 verdict: Drone is functionally solid, but the community-momentum question is real. Anyone picking a new CI system in May 2026 should prefer Woodpecker (Drone fork, very active) over Drone. Anyone with Drone already in production can stay without rush – pipelines are largely identical and a later migration to Woodpecker typically costs half a day.

Why it matters

Drone popularised the container-native CI approach – many modern CI systems (Woodpecker, Gitea Actions, even GitLab CI in parts) show Drone DNA. Even if Drone itself is no longer the first pick in May 2026, understanding its concept matters.

Container-native as idea: Drone was, in 2014, one of the first CI systems to use Docker as a pipeline primitive. Instead of running a long-lived build agent with installed tools (Jenkins model), Drone spawns a fresh container per step with the required image. Advantage: no state drift between builds, reproducible pipelines, easy to scale. Disadvantage: Docker pull overhead per job (solved with caches).

CH DSG fit: Drone self-host runs on Hetzner Falkenstein without issue. Apache 2.0 without clauses, code stays on-premise. For fiduciary or law-firm mandates, Drone as a toolchain is compliant – the only question is whether it remains the strategic choice in 2026.

SME suitability May 2026 – conditional: anyone with Drone already in production stays for now. Pipelines run, bugs are rare, security patches arrive sporadically. Anyone starting fresh in May 2026 should pick Woodpecker – almost identical YAML, more active community, clearer future. Later migration to Woodpecker is not risky but would be avoidable effort.

When Drone still makes sense: (1) existing Drone pipelines with complex plugins whose Woodpecker equivalent does not yet exist, (2) Kubernetes CI setups using the stable drone-runner-kube, (3) setups with Drone Enterprise (Harness support) and a maintenance contract.

Strategic point: Harness as parent company commercialises the main platform. That means: OSS Drone is unlikely to "die", but will not get dramatic new features either. A stabilisation path with small patches. For an SME relying long-term on an active community, Woodpecker is the more honest tool.

How it works

Drone consists of two main components: server and runner.

docker-compose.yml example with Gitea as the Git host:

```yaml services: drone-server: image: drone/drone:2 ports: ["8080:80"] volumes: - drone-data:/data environment: DRONE_GITEA_SERVER: https://git.firm.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.firm.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 side: create OAuth app in Settings > Applications, paste Client ID and Secret into Drone .env. Drone fetches the repo list via the Gitea API; users activate repositories by click.

Pipeline example (.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 are defined in the Drone UI per repo, not in YAML. from_secret in YAML references them.

Runner scaling: per runner DRONE_RUNNER_CAPACITY=N – N parallel jobs. Multiple runner containers can register with the server for horizontal scaling. For an SME with 5-20 pipelines/day, one runner with capacity 2-4 suffices.

Plugin system: Drone plugins are simply Docker images with a defined input schema (environment variables). Examples: docker (build and push), slack (notification), s3-upload, downstream (multi-project trigger). Hundreds of plugins available in the Drone marketplace.

Setup in 5 steps (or migration to Woodpecker)

1. 01Check whether new install is needed – May 2026 Woodpecker is the strategically better pick. Existing Drone stays, new setups go Woodpecker.
2. 02If Drone continues: docker-compose with drone/drone:2 plus drone-runner-docker, create OAuth app in Gitea/GitLab/GitHub, generate RPC secret.
3. 03nginx reverse proxy at drone.firm.ch with Lets-Encrypt cert, rate limit on /login.
4. 04Activate first repository in Drone UI, write .drone.yml with build step, trigger pipeline, verify logs in UI.
5. 05Auto-update via Watchtower or monthly cron, Telegram alert on failing pipelines, backup the Drone data volume.

When to (still) use Drone

In May 2026 Drone is the right choice in specific constellations: (a) existing Drone install with working pipelines – migration is effort without immediate value, (b) Kubernetes CI with drone-runner-kube, which remains stable, (c) setup with a Drone Enterprise support contract via Harness.

For new installations in May 2026: pick Woodpecker instead of Drone. Functionally almost identical, community markedly more active, clearer future.

Concrete legacy cases: an SME running Drone with Gitea since 2022 – 50 repos, 30 pipelines per day. Migration to Woodpecker would be half a day of work, but no urgent value. Staying is fine. A Kubernetes CI platform using drone-runner-kube in production – the Kubernetes runner is more stable than the Woodpecker equivalent (as of May 2026), staying is the rational choice.

Important: keep patching Drone. Security patches arrive sporadically, but they arrive. Monthly manual update cron or auto-update the Drone images via Watchtower.

When not to use

Drone is the wrong choice when (a) the setup is being built fresh in May 2026 – Woodpecker is the strategically better pick, (b) specific new plugins are desired – the Drone plugin community is dormant, (c) compliance requires fast security patches – Drone patches are sporadic, (d) the team is waiting for innovation/features – none coming.

Pitfalls: running Drone without regular updates – security patches are sporadic but important. Using Drone plugins from the marketplace without checking maintainer status – many plugins are unmaintained. Licensing Drone Enterprise without checking the Harness support scope – Harness focuses the main platform, OSS Drone gets less.

Anti-patterns: building a new CI strategy with Drone as central component – migration effort later is avoidable. Running Drone and Woodpecker in parallel – both engines coexist technically, but two UIs and two pipeline languages are configuration pain. Picking Drone as CI for GitLab – integrated GitLab CI is markedly tighter.

Trade-offs

FAQ

Related topics

Sources

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