Drone

Self-hosted continuous integration, honestly reviewed — including the part where it became something else.

TL;DR

• What it is: Apache-2.0 licensed continuous integration platform — Docker-native, config-as-code, designed to be the opposite of Jenkins [4].
• Who it’s for: Development teams comfortable with Docker who want self-hosted CI/CD without Jenkins overhead. Particularly clean for Gitea-based DevOps stacks [1].
• The big caveat: Drone has been absorbed into Harness Open Source. Drone itself continues as a feature branch; new development happens on Harness. This changes the calculus for new adopters significantly [README].
• Cost savings: Self-hosted on a $10 VPS vs. GitHub Actions overage at scale, CircleCI, or Azure DevOps team plans that climb to $50–$200+/month at serious usage volumes.
• Key strength: Absurdly clean YAML pipeline config committed to your repo. Every pipeline step runs in an isolated Docker container, auto-pulled at runtime — no shared state, no dependency conflicts [website][4].
• Key weakness: Drone as a standalone product is effectively frozen. If you’re starting fresh, you’re choosing between a stable, mature tool and betting on Harness reaching pipeline parity, which isn’t complete yet [README].

---

What is Drone

Drone is a self-hosted continuous integration platform built around one idea: pipelines are code. You commit a .drone.yml file to your repository, and Drone executes it. Every step runs inside its own Docker container, pulled fresh at runtime. No plugin configuration in a web UI, no XML job definitions, no shared state between builds unless you explicitly configure it [website][4].

The homepage pitch — “a self-service Continuous Integration platform for busy development teams” — is accurate in the way that undersells the point. The actual differentiation versus Jenkins, the tool most teams are fleeing, is this: Jenkins is a Java application from 2011 that accumulated plugins and configuration until it became its own infrastructure problem. Drone is a Go binary, a docker-compose file, and a YAML config. That’s the entire pitch, and for a lot of teams, it lands [2][4].

The project has 33,914 GitHub stars, placing it among the most-starred self-hosted CI tools. The license is Apache-2.0 — genuinely permissive, no “Fair-code” restriction, no commercial use limitations, no contributor license friction [4].

The Harness situation deserves its own paragraph. Drone was acquired by Harness and is now part of “Harness Open Source” — an end-to-end developer platform adding source code hosting, developer environments (Gitspaces), and artifact registries on top of the CI core. The GitHub README now reads: “Harness Open Source is an open source development platform packed with the power of code hosting, automated DevOps pipelines, hosted development environments (Gitspaces), and artifact registries.” Drone continues as a feature branch (drone branch on the harness/harness repo) with its own README and ongoing maintenance — but the main line is Harness. The stated goal is eventual feature parity so existing Drone users can migrate without rewriting pipelines. Whether that migration happens smoothly is still an open question [README].

For teams already running Drone: it works, it’s maintained, the feature branch isn’t abandoned. For new adopters: you’re choosing between Drone (mature, stable, feature-frozen) or Harness Open Source (newer, more complete, still reaching parity with Drone’s pipeline surface).

---

Why people choose it

The patterns across reviews are consistent: people choose Drone because it’s not Jenkins, and they stay because the YAML config model genuinely solves the right problem [2][4].

The Jenkins comparison is the primary driver. The saashub.com writeup [4] calls out ease of setup as a top differentiator: “setup and initial configuration are relatively straightforward, making it accessible even for teams with limited DevOps experience.” That’s a low bar to clear, but Jenkins makes it easy to clear — Jenkins requires a running JVM, plugin management through a web UI, a dedicated admin to keep things healthy, and a shared build server that becomes a footgun the moment two teams start using it. Drone’s container isolation model eliminates a whole category of “works on my machine, fails in CI” failures before they happen [4].

The webhookrelay.com piece [2] frames the appeal in terms of control: teams that don’t want cloud dependencies, that need deterministic build environments, that can’t route source code through a third-party CI system. Container-native execution means the same docker pull node:20 that runs locally runs in CI — the environment is reproducible by construction [2].

Ruan Bekker’s dev.to guide [1] gives the clearest portrait of the actual user. He’s building a self-hosted DevOps stack: Gitea for source control, Drone Server for pipeline management, Drone Agent (runner) for build execution, all wired up with Docker Compose. The pipeline config is three lines of YAML — a busybox image running echo commands. That’s the bottom of the complexity curve, but the architecture scales: the same model supports parallel pipelines, multi-arch builds, Kubernetes runners, and custom plugins [1][website].

Where the decision splits against GitHub Actions: GitHub Actions is free at scale for public repos and covers most private-repo teams on GitHub’s paid plans. The reasons to run Drone instead are compliance (code can’t leave your network), cost at high build volume, or wanting CI that’s independent of your SCM provider. Drone integrates with GitHub, GitLab, Bitbucket, and Gitea — it’s not tied to any one platform [website][1].

---

Features

Based on the official website and README:

Pipeline engine:

• Configuration-as-code via .drone.yml committed to the repository [website]
• Each step executes inside an isolated Docker container, auto-pulled at runtime [website]
• Parallel steps and multi-pipeline configurations per repository
• Service containers for dependencies — the homepage example shows a MySQL container running alongside a Node test step [website]
• Cron scheduling for time-based pipeline triggers
• Matrix builds for testing across multiple runtime versions

Platform coverage:

• Any SCM: GitHub, GitHub Enterprise, GitLab, Bitbucket, Gitea [website]
• Linux x64, ARM, ARM64, Windows x64 [website]
• Any language, database, or service that runs in a Docker container [website]
• Kubernetes runner for teams already operating k8s clusters

Plugin system:

• Pre-built plugins: Docker build/push, Kubernetes deployments, AWS S3, ECR, NPM publish, GitHub Releases, Slack notifications, Netlify [website]
• Plugins are Docker images — creating one means writing a container that reads step config from environment variables [website][4]
• Hundreds of community-contributed plugins available [3][4]

Advanced configuration:

• Custom access controls [website]
• Approval workflows [website]
• Secret management — secrets injected as environment variables, never written to logs [website]
• YAML syntax extensions for edge cases [website]

Scalability:

• Single binary + Postgres/SQLite; scales from a one-node Docker setup to a distributed runner fleet [website][4]
• Multiple runner types: Docker, Kubernetes, Exec, SSH [4]
• Drone Server handles coordination; Runners execute builds — architecture separates concerns cleanly [1]

---

Pricing: SaaS vs self-hosted math

Drone self-hosted:

• License cost: $0 (Apache-2.0)
• Infrastructure: a $6–10/month VPS covers most small teams
• No license negotiation, no trial period, no sales call [website]

What you’re replacing:

GitHub Actions:

• Free tier: 2,000 minutes/month for private repos on the free GitHub plan
• Overage rate: $0.008 per Linux minute — a CI-heavy team burning 50,000 minutes/month pays $400 in overage alone, on top of the base plan
• Self-hosted GitHub Actions runners are free to run, but still depend on github.com for orchestration

Azure DevOps (the profiled SaaS competitor):

• Free tier: 1 Microsoft-hosted parallel job, 1,800 minutes/month for private projects
• Additional parallel jobs: $40/month per job — teams with multiple repos or parallel test suites outgrow the free tier quickly

CircleCI:

• Free: 6,000 credits/month (~30 compute-hours on small machines)
• Performance plan: $15/month for 25,000 credits/month — exhausted by a single active repo with parallel jobs

Self-hosted Drone math: A team running 10 repos with moderate CI usage — 20,000 build-minutes/month — might spend $140+/month in GitHub Actions overage or $30–60/month on CircleCI. Drone on a $10 VPS: $10/month, unlimited builds, no per-minute anxiety.

Over a year, the CI bill on managed services can reach $1,000–2,000+ for an active team. Drone self-hosted keeps it near-zero past the initial VPS cost. Drone Cloud pricing for hosted usage is not publicly documented in detail; the website directs to a free cloud offering for small teams [website].

---

Deployment reality check

The setup story is one of Drone’s genuine strengths. The dev.to guide [1] walks through the full stack — Gitea + Drone Server + Drone Agent — in a single docker-compose file. The Harness README gives the current simplified path:

docker run -d \
  -p 3000:3000 \
  -p 3022:3022 \
  -v /var/run/docker.sock:/var/run/docker.sock \
  -v /tmp/harness:/data \
  --name harness \
  --restart always \
  harness/harness

One command, one container, running on localhost:3000 [README].

What you actually need for a production Drone install:

• Linux VPS with Docker (2GB RAM minimum, 4GB comfortable for parallel builds)
• A domain and reverse proxy (Caddy or nginx) for HTTPS
• An OAuth app registered with your SCM provider for authentication
• Persistent volume for Drone’s SQLite or Postgres database

What can go wrong:

• The Docker socket mount (/var/run/docker.sock) is required for Docker runner pipelines. On non-standard runtimes — Rancher Desktop, Colima — the socket path differs. The README documents symlink workarounds, but it’s an extra step [README]
• Secret management is basic by default. Secrets live in Drone’s own database. There’s no native Vault or AWS Secrets Manager integration out of the box — you’d need a plugin or workaround for that
• The Harness migration path isn’t fully paved. Drone installed from the feature branch today is stable but on a diverging codebase. Harness pipeline parity with Drone isn’t complete yet, so the migration window isn’t open [README]
• Plugin quality varies significantly. Core plugins (Docker, Slack, S3) are actively maintained. Long-tail community plugins may be broken on newer Drone versions or simply abandoned [3]

Realistic time estimate: 30–60 minutes for a developer comfortable with Docker Compose. Add another hour for HTTPS and SCM OAuth configuration. For a non-technical founder, budget a half-day or have someone set it up once.

---

Pros and cons

Pros

• Clean YAML pipeline config. The .drone.yml format is among the most readable in CI/CD. No proprietary syntax, no web UI state, no shared environment between jobs by default [website][1].
• True container isolation. Every step runs in its own pulled-fresh Docker container. No leaked environment variables, no dependency conflicts between pipeline steps [website][4].
• Apache-2.0 license. Genuinely permissive. No commercial use restrictions, no copyleft requirements [4].
• 33,914 GitHub stars. Established community, years of production deployments across a wide range of team sizes.
• Any SCM. GitHub, GitLab, Bitbucket, Gitea — not locked to one platform [website].
• Multi-arch support. Linux x64, ARM, ARM64, Windows — relevant for teams building for edge devices or testing across architectures [website].
• Lightweight operational footprint. A single Go binary, Postgres or SQLite, Docker. Compared to Jenkins, the maintenance burden is minimal [2][4].
• Scales from laptop to cluster. Same architecture runs on a $10 VPS or across a Kubernetes runner fleet [website].

Cons

• Drone is effectively frozen. Active development is happening on Harness Open Source, not classic Drone. New adopters should evaluate which one they’re actually choosing [README].
• No built-in source control. Drone is CI-only. You need a separate SCM. Harness Open Source adds code hosting, but that’s a different installation [README].
• Basic secret management. No native Vault or cloud secrets integration. Secrets stored in Drone’s own database [website].
• UI is functional, not polished. The interface gets the job done. Teams wanting dashboards, analytics, or granular RBAC will find gaps compared to GitHub Actions or CircleCI [4].
• Plugin catalog is smaller than GitHub Actions. Hundreds of community plugins vs. thousands of GitHub Actions. Long-tail SaaS integrations may not be covered [3][website].
• Migration uncertainty. Teams installing Drone today may face a meaningful migration once Harness reaches full pipeline parity. The timeline for that is not public [README].
• Community support, not enterprise SLAs. No hosted offering with documented response times comparable to CircleCI or GitHub Actions support tiers [website].

---

Who should use this / who shouldn’t

Use Drone if:

• You’re running Gitea or another self-hosted SCM and want CI that integrates cleanly without depending on github.com [1].
• You’re replacing Jenkins and want a container-native, config-as-code tool without learning an entirely new paradigm.
• Your builds target ARM, ARM64, or Windows — Drone’s multi-arch support is well-tested [website].
• You have compliance requirements that prevent routing code through managed CI services.
• You’re comfortable with Docker and want your pipeline config in version control alongside your code.

Consider Harness Open Source instead if:

• You’re starting fresh and want a full DevOps platform (code hosting + CI/CD + developer environments + artifact registries) rather than CI only [README].
• You want to bet on the project where active development is happening, not the stable feature branch.

Consider Woodpecker CI instead if:

• You want the Drone model — container-native, YAML pipelines, simple setup — but without the acquisition uncertainty. Woodpecker CI is a community fork of Drone with active, independent development and compatible pipeline syntax.

Skip Drone if:

• You’re already on GitHub with a team plan — GitHub Actions self-hosted runners give the same isolation model without running a separate CI server.
• You need SSO, audit logs, and enterprise RBAC out of the box.
• Your team isn’t comfortable operating Docker infrastructure.
• You need the 5,000+ actions available on GitHub’s marketplace. Drone’s plugin catalog is hundreds, not thousands [website].

---

Alternatives worth considering

• Woodpecker CI — Community fork of Drone with ongoing independent development. Compatible pipeline syntax, same container model, no acquisition baggage. The most direct alternative for teams that want Drone without the Harness trajectory.
• Harness Open Source — The direct successor. Adds code hosting, developer environments (Gitspaces), artifact registries. Same CI core, broader platform scope [README].
• Gitea Actions / Forgejo Actions — If you’re already self-hosting Gitea or Forgejo for source control, their built-in Actions (GitHub Actions-compatible syntax) eliminate the need for a separate CI server.
• GitHub Actions — The path of least resistance for GitHub users. Managed, massive action catalog, free for public repos. Self-hosted runners available for local execution.
• Jenkins — The incumbent. Feature-rich, plugin-rich, operationally expensive. Worth it only if you have existing Jenkinsfile investments and a team to maintain it.
• GitLab CI — Built into GitLab, excellent if you’re already self-hosting GitLab. No separate CI server required, well-documented, actively developed.
• Concourse — Another container-native, config-as-code CI tool. More principled architecture, steeper learning curve, smaller community than Drone.

For a non-technical founder building a self-hosted DevOps stack from scratch in 2026, Harness Open Source or Forgejo + Forgejo Actions is the more defensible starting point than classic Drone, given where active development is going.

---

Bottom line

Drone earned its 33,914 stars by solving a real problem: making self-hosted CI/CD something a developer could set up in an afternoon instead of spending a week fighting Jenkins. Container isolation, YAML-as-config, Apache-2.0 license, multi-arch support — the fundamentals are solid and the production track record is long. The complication is that Drone the independent product is now Drone the feature branch. Harness is where the roadmap lives. For existing Drone users, there’s no fire — the branch is maintained, migrations aren’t urgent, and the pipeline syntax you know still works. For new adopters, the honest answer is to evaluate Woodpecker CI (the community fork) or Harness Open Source alongside Drone itself, because both represent clearer long-term bets. If you’re escaping Jenkins and want the Drone model today, Woodpecker CI gets you there without the acquisition uncertainty. If you want to build on the platform Harness is investing in, start there. Either way, a $10 VPS with a docker-compose file still beats paying per build minute forever.

---

Sources

1. Ruan Bekker, dev.to — “Self Hosted CICD with Gitea and Drone CI” (February 11, 2020). https://dev.to/ruanbekker/self-hosted-cicd-with-gitea-and-drone-ci-200l
2. WebhookRelay Blog — “Setting up simple, self-hosted & fast CI/CD solution with Drone.io”. https://webhookrelay.com/blog/using-drone-for-simple-selfhosted-ci-cd/
3. SourceForge — “Drone Reviews in 2026”. https://sourceforge.net/software/product/Drone/
4. SaaSHub — “Drone.io reviews. Is Drone.io good?”. https://www.saashub.com/drone-io

Primary sources:

• Official website: https://www.drone.io
• GitHub repository (Harness/Drone): https://github.com/harness/drone (33,914 stars, Apache-2.0 license)
• Drone feature branch README: https://github.com/harness/harness/tree/drone
• Harness Open Source documentation: https://developer.harness.io/docs/open-source