Drone
Container-based continuous delivery platform
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
act
CI/CD & BuildRun GitHub Actions workflows locally for fast feedback
Replaces GitHub Actions
Jenkins
CI/CD & BuildExtensible open-source automation server for CI/CD
Replaces CircleCI
Argo CD
CI/CD & BuildDeclarative GitOps continuous delivery for Kubernetes
Replaces Spinnaker
Argo Workflows
CI/CD & BuildContainer-native workflow engine for Kubernetes
Replaces Airflow
Dagger
CI/CD & BuildProgrammable CI/CD engine that runs pipelines as code
Replaces GitHub Actions, CircleCI
Bytebase
CI/CD & BuildDatabase DevOps and CI/CD for schema changes
Replaces Liquibase, Flyway