drone.io

What is Drone CI?

Drone CI is a self-service continuous integration and delivery platform aimed at development teams that want to automate building, testing and shipping software. Its defining idea is that pipelines are defined as code in a simple YAML file committed to your Git repository, and every pipeline step runs inside its own isolated Docker container that is pulled at runtime. That combination keeps build environments reproducible and prevents jobs on a shared server from interfering with each other.

Drone CI

What it does

• Configuration as code. A pipeline file lives alongside your source, so changes to the build are reviewed and versioned like any other code.
• Container-per-step execution. Each step names a Docker image and commands to run inside it, which means the toolchain is whatever image you choose rather than whatever happens to be installed on the build machine.
• Services alongside steps. You can declare backing services such as a database container and expose ports to the pipeline, which is useful for integration tests.
• Broad source-control support. It integrates with common Git hosting systems, so pipelines trigger from normal push and pull-request activity.
• Cross-platform runners. It supports several operating systems and CPU architectures, including Linux on x64, ARM and ARM64, plus Windows x64.
• Plugins. Pre-configured container steps cover common tasks such as publishing packages, creating releases, deploying to cloud storage, and sending chat notifications; you can also write your own.
• Customization and governance. Access controls, approval workflows, secret management and YAML extensions are available for teams that outgrow the basics.
• Simple installation and scaling. It installs from a single binary and is designed to scale without a heavy setup process.

Who it suits

A practical next step

Take one repository with a test suite and write a minimal pipeline: a test step using your language's official Docker image, plus a database service container if your tests need one. Run it on a branch before touching your main pipeline. If the isolated-container model removes the "works on my machine" problems you currently fight, Drone is a good fit; if your builds depend on long-lived state on a specific server, expect to redesign that part first.

For teams comparing options, hosted Git platforms bundle their own CI — for example GitHub Actions and GitLab — while Jenkins remains the general-purpose self-hosted alternative. Drone's distinction is the tight coupling of pipeline-as-code with per-step containers and a lightweight install.

How do I install Drone CI?

Drone CI installs from a single binary, and the official route is its Docker image (you can also build from source). The page explicitly says there is no sales conversation or trial license needed to get started.

The typical install path

1. Check prerequisites. You need a host with Docker, plus a source-control account Drone can talk to (GitHub, GitHub Enterprise, Bitbucket, or GitLab per the page).
2. Create an OAuth application in that source-control system so Drone can authenticate users and receive webhooks.
3. Run the Drone server from the official Docker image, pointing it at your source-control provider and your chosen database.
4. Run a Drone runner as a second container. Runners are what actually execute each pipeline step inside its own isolated Docker container.
5. Register your first repository in the Drone UI, commit a .drone.yml to it, and push. The build triggers on the push.

What the config actually looks like

Drone is configuration-as-code: you commit a small YAML file to the repo, and each step runs in a Docker image pulled at runtime. The page's own example is essentially:

kind: pipeline
steps:
  - name: test
    image: node
    commands:
      - npm install
      - npm test
services:
  - name: database
    image: mysql
    ports:
      - 3306

That structure is the practical selling point: a service container (here MySQL) sits alongside your test step, so integration tests get a real database without a shared, hand-configured build box.

Choosing between self-hosting and the cloud option

The page also advertises a free cloud offering, which is the fastest way to evaluate the YAML workflow before committing to running your own server.

A practical next step

If you are migrating from Jenkins, install Drone on a single spare Linux host first and port one repository end to end — build, test, and one notification step. The page notes plugins for Slack notifications, GitHub Releases, GitHub Pages, S3, ECR, Netlify and NPM publishing, so a realistic pilot is: test step, then a Slack notification on failure. If that works, expand to ARM or Windows runners, which the page lists as natively supported alongside Linux x64.

For the exact commands and current environment variables, follow the official documentation rather than a blog post, since install flags change between releases.

How does Drone CI work with GitHub, GitLab, and Bitbucket?

Drone CI connects to GitHub, GitLab, and Bitbucket as source code managers so it can watch your repositories and run pipelines when code changes. The key idea is that Drone does not need a separate build script store: the pipeline lives in a YAML file committed to the repo, and Drone reads it when a change is pushed or a pull request is opened.

What this means in practice

• Repository integration. Drone authenticates with your Git host, then lists and activates repositories you choose. Once a repo is activated, Drone receives webhooks from that host for events like pushes, pull requests, and tags.
• Configuration as code. A .drone.yml file in the repository defines the pipeline. Each step runs in an isolated Docker container pulled at runtime, so the same pipeline definition works whether the repo is on GitHub, GitLab, or Bitbucket.
• Cross-host consistency. Because the pipeline format is the same, teams using more than one Git host can keep similar build, test, and deploy steps without rewriting them per host.

Host-specific things to expect

Drone's own page lists GitHub, GitHub Enterprise, Bitbucket, and GitLab as supported source code management systems, and it presents the platform as self-service for busy development teams. The page also notes Drone is part of the Harness family, which matters if you are evaluating long-term support and enterprise features.

A concrete scenario

Suppose a team keeps its main product on GitHub, a legacy service on GitLab, and a marketing site on Bitbucket. With Drone, each repository gets a .drone.yml file, and the same Docker-based steps—install dependencies, run tests, build an image—can be reused across all three. When someone opens a pull request on GitHub or a merge request on GitLab, Drone can run the pipeline and report status back to that host.

How to choose

If your team already lives inside one Git host's native CI, switching to Drone mainly makes sense when you want container-isolated steps, a single pipeline format across multiple hosts, or self-hosted control. If you only use GitHub and want the tightest native integration, compare Drone's setup effort against GitHub Actions before committing.

Next step

Pick one repository, add a minimal .drone.yml with a single test step, and activate that repo in Drone. Confirm the webhook fires on a push, then expand the pipeline to cover build and deploy. For official installation and configuration details, start with Drone CI.

What are the benefits of using Drone CI over Jenkins?

Drone CI's main advantage over Jenkins is architectural: pipelines run as isolated Docker containers, configured by a YAML file committed alongside your code. Jenkins, by contrast, is typically a long-lived server you maintain, with jobs configured through its UI or Jenkinsfiles and plugins you install and upgrade yourself. That difference shapes everything below.

Where Drone tends to win

• Reproducible, isolated builds. Each pipeline step executes in its own container, so a Node test step and a MySQL service don't collide with other builds on the same machine. Jenkins can do this with Docker agents, but it's an add-on you configure rather than the default model.
• Configuration as code, with less ceremony. A pipeline is a short file in your repo. Anyone reviewing a pull request sees exactly what will run. Jenkins Pipelines are also code, but the surrounding job/server configuration often isn't.
• Low operational overhead. Drone installs from a single binary and auto-provisions environments from public or private Docker images. There's no plugin-version treadmill to manage, which is the most common source of Jenkins maintenance pain.
• Broad source-control and platform coverage. It integrates with GitHub, GitHub Enterprise, Bitbucket and GitLab, and runs on Linux x64, ARM, ARM64 and Windows x64.
• Plugin reuse via containers. Pre-built steps (S3, ECR, Slack, GitHub Releases, Netlify, and so on) drop into a pipeline, and you can build your own in any language that runs in a container.

Where Jenkins still makes sense

Jenkins has a far larger plugin ecosystem, decades of community answers, and deep support for exotic or legacy toolchains that may never have been containerised. Teams with heavy on-premises Windows or mainframe build requirements, or with large existing Jenkins investment, often find migration costlier than the benefit.

A practical next step

Pick one representative repository — ideally one with a database service and a deploy step — and rewrite its pipeline as a Drone YAML file, then run both systems in parallel for a sprint. Compare total time spent on pipeline maintenance, not just build duration. If your team is small and already containerised, Drone usually removes more work than it adds; if your builds depend on a long tail of Jenkins plugins, check whether each has a container equivalent before committing. The project's documentation and plugin directory, plus GitHub for the source, are the places to verify that.

How do I create custom plugins for Drone CI?

Custom plugins for Drone CI are just Docker containers that follow a small convention: Drone runs your container as a pipeline step, passes it configuration through environment variables and settings, and reads the process exit code to decide success or failure. You do not install anything into Drone itself — you build and publish an image, then reference it in your pipeline YAML.

The basic contract

• Input: Drone injects pipeline step settings as environment variables. Conventionally, plugin settings are prefixed with PLUGIN_ (for example, a token setting becomes PLUGIN_TOKEN), and Drone also exposes built-in variables such as repository name, commit SHA, and branch.
• Output: Your container writes to stdout/stderr for logs and exits 0 for success or non-zero for failure.
• Distribution: Push the image to a registry (Docker Hub, AWS ECR, GitHub Container Registry, or a private registry) and reference it by tag in the step's image: field. The page evidence notes Drone supports choosing from public Docker images or providing your own, and that plugins can be shared and reused.

A minimal pipeline step

kind: pipeline
type: docker
name: default

steps:
  - name: my-plugin
    image: your-registry/your-plugin:1.0.0
    settings:
      token:
        from_secret: api_token
      message: "Build finished"

Your container receives PLUGIN_TOKEN and PLUGIN_MESSAGE. Secrets referenced with from_secret are injected at runtime rather than stored in the YAML.

Writing the plugin

Any language works as long as it runs in a container. A small script is often enough:

FROM alpine:3.19
COPY entrypoint.sh /entrypoint.sh
RUN chmod +x /entrypoint.sh
ENTRYPOINT ["/entrypoint.sh"]

#!/bin/sh
set -e
echo "Running for $DRONE_REPO on branch $DRONE_COMMIT_BRANCH"
# use "$PLUGIN_TOKEN" and "$PLUGIN_MESSAGE" here

Keep the image small, avoid requiring a shell if you can, and log enough context that failures are diagnosable from the Drone UI alone.

Practical decisions

Test the container locally with docker run -e PLUGIN_TOKEN=... your-image before wiring it into a pipeline. That isolates plugin bugs from Drone configuration bugs.

Next step

Start from the official plugin starter template and the plugin documentation listed on Drone CI, then publish a 0.1.0 tag and add it to a throwaway repository pipeline. Once it behaves, pin the version in production pipelines rather than using latest, so an upstream image change cannot silently alter your builds.

Is Drone CI free to use?

Drone CI is free to use in the sense that its core continuous integration and delivery platform is open source and can be self-hosted at no license cost. The website positions it as a self-service CI platform, with a single-binary install and an official Docker image, so you can run it on your own infrastructure without paying for the software itself.

There is also a hosted cloud option. The page includes a "Try free cloud offering" link, which suggests a free tier or trial for the cloud version, but the page does not specify what limits or paid tiers apply. Treat that as a starting point rather than a complete pricing picture.

Where cost can still appear

• Infrastructure: Self-hosting means you pay for the servers, VMs or Kubernetes cluster that run Drone and its build containers.
• Cloud usage: If you use the hosted offering beyond any free allowance, expect usage-based or subscription charges, though exact terms are not on this page.
• Commercial support: Drone is now part of Harness, and enterprise support or platform features may carry separate commercial terms.

Practical next step

If your main concern is avoiding license fees, self-hosting Drone is the clearest route: install from the official Docker image, point it at your Git provider, and run builds in Docker containers. If you would rather not manage servers, start with the free cloud offering and check its current plan limits before committing. For teams already using a source manager like GitHub, GitLab or Bitbucket, Drone integrates with those directly, so the decision usually comes down to whether you want to operate the infrastructure yourself. You can compare the self-hosted route with a managed alternative such as GitHub Actions if your code already lives on GitHub.