DR

Drone

Container-based continuous delivery platform

CI/CD & Build ★ 38.4k stars Medium setup Apache-2.0

Drone is a container-based continuous integration and delivery platform that runs each pipeline step in an isolated container. It targets teams wanting CI defined entirely in code. It is deployed via Docker.

Key features

  • Pipelines defined as code
  • Every step runs in a container
  • Many Git provider integrations
  • Plugin ecosystem

Pros & cons

Strengths

  • Clean container model
  • Configuration as code
  • Scales with runners

Trade-offs

  • Now under commercial steward
  • Spurred the Woodpecker fork

Drone replaces

Last reviewed Aug 26, 2026 · 797 words

Drone invented the pipeline model everyone now copies, every step in its own container, defined in a YAML file next to the code, and in 2026 I would not start a new install of it. Harness bought the project in 2020, moved its attention to the Gitness successor, and the Drone repository has settled into maintenance. The community fork Woodpecker CI carries the same design forward with active development and a near-compatible pipeline format. This guide covers how Drone works, because the model is still the right one, and where to get that model from now.

The model is the reason it mattered

A .drone.yml in the repository root declares a pipeline; each step names an image and a list of commands, and Drone runs the step inside that image with the workspace mounted. There is no build agent with Node, Python and Go preinstalled and drifting; the toolchain is whatever image you name.

kind: pipeline
type: docker
name: default

steps:
  - name: test
    image: golang:1.22
    commands:
      - go test ./...
  - name: build
    image: golang:1.22
    commands:
      - go build -o app .
    when:
      branch: [main]

Plugins are just images with a documented set of settings, so publishing to a registry or posting to chat is one more step. Every CI that came after borrowed pieces of this.

Server plus runner, and a forge to hang it on

Drone is 2 processes. The server (image drone/drone:2) talks to your Git forge for OAuth login and webhooks and holds the build queue; runners (drone/drone-runner-docker:1 for the common case) pull jobs from the server and execute them against a local Docker socket. Both are Go binaries that sit inside the catalogue's 256 MB comfortably. With Gitea as the forge, the server needs an OAuth application registered in Gitea and these variables:

environment:
  DRONE_GITEA_SERVER: https://git.example.com
  DRONE_GITEA_CLIENT_ID: from-gitea-oauth-app
  DRONE_GITEA_CLIENT_SECRET: from-gitea-oauth-app
  DRONE_RPC_SECRET: shared-with-runners
  DRONE_SERVER_HOST: ci.example.com
  DRONE_SERVER_PROTO: https

The runner needs DRONE_RPC_HOST, DRONE_RPC_PROTO, the same DRONE_RPC_SECRET, and the Docker socket mounted. Runners scale horizontally: a second machine with a runner and the same secret starts taking jobs, which is a cleaner story than most CI systems offer at this size. State is a SQLite file under /data on the server by default, or Postgres if you set DRONE_DATABASE_DRIVER. The separate drone CLI adds drone exec, which runs a pipeline locally against your own Docker daemon; it is the fastest way to debug a YAML change without pushing 6 commits named "fix ci". Secrets are stored per repository in the UI or through the CLI and injected into steps as environment variables, never written into the YAML.

The licence history is why the forks exist

Drone was Apache-licensed through its 0.8 series. The 1.0 release in 2019 moved the server under a non-commercial licence with a build limit, and that is the event that produced Woodpecker: a fork of the last permissive version that kept the container model and has been maintained by the community since. The catalogue lists Apache-2.0 for the code today, but the momentum had moved by the time the terms softened. The notes on who pays for open source cover why this pattern keeps repeating.

For a self-hoster the practical consequences are 3. Woodpecker reads .woodpecker.yml with a close syntax, so migrating a Drone pipeline is usually a rename and a few key changes. Woodpecker's Gitea and Forgejo integrations are first-class because those communities overlap heavily. And most of Drone's plugin images still work in Woodpecker, so the ecosystem transferred with the fork.

Where Drone still shows up

Existing installs that work. Drone is stable, small and does not break, so a team with a 2021 setup has no forcing reason to move. And its lineage continues inside Gitness, Harness's all-in-one Git host with Drone-compatible pipelines built in, which is the closest thing to a successor from the original author. If you like the Drone pipeline dialect and want a single container for both code and CI, that is where it went. The broader CI/CD category has the rest.

What I'd do

New install: Woodpecker beside Gitea or Forgejo, with the pipeline above translated to .woodpecker.yml; you get the same container model, active maintenance and no licence worry. Existing Drone: leave it running until something you need is missing, keep the SQLite file in your backups, and test the Woodpecker migration on one repository first. Do not build anything new on Drone itself; the design won, and the project that carries it now has a different name.

Compare Drone

10 head-to-head comparisons.

Similar ci/cd & build apps