Drone CI: Getting Started

By Kokil Thapa | Last reviewed: September 2026

Drone CI: Getting Started is simpler than it looks once you split the problem in two. You run a small Drone server that talks to GitHub or GitLab. You attach one or more Drone runners that execute pipeline steps in containers. Most teams stall on OAuth, runner registration, or a vague .drone.yml file. This guide walks through a working path on Ubuntu with PHP 8.3, Laravel 13, and a deploy hook you can adapt. If you already run GitLab CI for Laravel, Drone feels familiar — YAML pipelines, Docker steps, and secrets — with a lighter control plane.

What Is Drone CI Getting Started Architecture in 2026?

Drone is a container-native CI engine. The server listens for webhooks from your SCM. It schedules work. Runners pull jobs and run each step as a Docker container. There is no heavy JVM stack and no bundled Git hosting. That separation keeps the server small and pushes compute to runners you control.

In practice, a three-node mental model is enough for your first week. One VM runs the Drone server plus a reverse proxy. One or more VMs (or the same box for trials) run Drone runners. Your Git provider remains the source of truth for code and pull requests.

Drone 2.x remains the stable line most teams run today. Runners use the Docker executor by default. Each step declares an image — for example php:8.3-cli or composer:2.10 — and a shell script block. Official reference material lives at docs.drone.io. The project source is maintained at github.com/harness/drone.

Why pick Drone over a bundled platform? You may already host GitLab but want CI agents on a cheap VPS. You may run Gitea on a single box and need lightweight automation. You may want pipeline YAML that travels with the repo without importing an entire DevOps suite. For Laravel shops, that maps cleanly to Composer installs, Pest or PHPUnit runs, Vite 8.x asset builds, and Deployer-style release steps.

How Do You Install Drone CI for Getting Started on Ubuntu?

Assume Ubuntu 24.04, Docker Engine installed, and a domain such as drone.example.com pointed at the server. Terminate TLS with Nginx or Caddy before you expose the Drone UI. The server container stores state in SQLite for trials or Postgres for production.

Create the OAuth application

GitHub: Settings → Developer settings → OAuth Apps. Set the callback URL to https://drone.example.com/login. Copy the client ID and secret. GitLab follows the same pattern under Admin → Applications. Without a correct callback URL, login loops fail silently and waste an hour.

Run the Drone server container

docker volume create drone-data

docker run \
  --volume=drone-data:/data \
  --env=DRONE_GITHUB_CLIENT_ID=your_client_id \
  --env=DRONE_GITHUB_CLIENT_SECRET=your_client_secret \
  --env=DRONE_RPC_SECRET=choose_a_long_random_string \
  --env=DRONE_SERVER_HOST=drone.example.com \
  --env=DRONE_SERVER_PROTO=https \
  --env=DRONE_USER_CREATE=username:your_github_user,admin:true \
  --publish=80:80 \
  --detach=true \
  --name=drone \
  drone/drone:2

Replace GitHub variables with GitLab equivalents if needed (DRONE_GITLAB_CLIENT_ID, etc.). Set DRONE_USER_CREATE so the first login is not a race for admin rights. Store secrets in a password manager, not in shell history.

Register a Docker runner

Install the runner on the same host or a separate build VM. The runner must reach the server RPC endpoint and have Docker socket access.

docker run -d \
  --volume=/var/run/docker.sock:/var/run/docker.sock \
  --env=DRONE_RPC_PROTO=https \
  --env=DRONE_RPC_HOST=drone.example.com \
  --env=DRONE_RPC_SECRET=choose_a_long_random_string \
  --env=DRONE_RUNNER_CAPACITY=2 \
  --env=DRONE_RUNNER_NAME=build-01 \
  --publish=3000:3000 \
  --name=runner \
  drone/drone-runner-docker:1

Match DRONE_RPC_SECRET exactly on server and runner. After registration, the Drone UI under Settings → Runners should show build-01 idle. If the runner stays offline, check firewall rules and TLS trust on the runner host. Deeper hardening patterns overlap with self-hosted CI runner security guidance.

1. Point DNS and enable HTTPS on the Drone host.
2. Create OAuth credentials on your Git host.
3. Start the Drone server with RPC secret and admin bootstrap user.
4. Start at least one runner with the same RPC secret.
5. Log in, activate your first repository, and commit .drone.yml.

For ongoing server care — updates, backups, log rotation — treat the Drone host like any other production box. Many Nepal teams bundle that work with Linux system administration retainers rather than learning Docker ops from scratch under deadline pressure.

What Does a Drone CI Pipeline Look Like When Getting Started?

Every activated repo reads pipeline config from .drone.yml at the root. Drone maps Git events to pipelines: push, pull request, tag, promote, and cron. Steps run sequentially unless you declare parallel stages with the graph syntax.

Below is a practical Laravel 13 pipeline. It installs Composer 2.10 dependencies, runs Pest tests, builds front-end assets with Node.js 26 LTS, and optionally deploys from main only.

kind: pipeline
type: docker
name: default

trigger:
  branch:
    - main
    - develop
  event:
    - push
    - pull_request

steps:
  - name: backend
    image: php:8.3-cli
    commands:
      - apt-get update && apt-get install -y git unzip libzip-dev
      - docker-php-ext-install zip
      - curl -sS https://getcomposer.org/installer | php -- --2
      - php composer.phar install --no-interaction --prefer-dist
      - cp .env.example .env
      - php artisan key:generate
      - vendor/bin/pest

  - name: frontend
    image: node:26-bookworm
    commands:
      - npm ci
      - npm run build
    when:
      branch:
        - main
        - develop

  - name: deploy
    image: plugins/webhook
    settings:
      urls:
        - https://deploy.example.com/hooks/drone
      content_type: application/json
    when:
      branch:
        - main
      event:
        - push
    environment:
      DEPLOY_TOKEN:
        from_secret: deploy_token

Add secrets in the Drone UI under Repository Settings → Secrets. Never commit tokens. Patterns mirror CI/CD secrets management best practices: short-lived deploy keys, scoped API tokens, and separate secrets per environment.

Speed up repeat builds

Drone supports volumes and cache plugins. Mount Composer cache between runs to cut minutes off PHP installs. The same ideas apply across engines; see build caching in CI for host-level strategies. For database-backed tests, wire a MySQL 8.4 service container in a separate pipeline or use SQLite in memory for unit suites only.

Gate merges on tests

Protect your default branch on the Git host. Require Drone status checks before merge. Add Pest coverage thresholds if your team tracks quality metrics — code coverage gates in CI explains the policy side. Run migrations in a dedicated step when integration tests need a fresh schema; database migrations in CI pipelines covers ordering and rollback thinking.

On projects I maintain with GitLab CI and Deployer, the deploy step is often a thin webhook that triggers a zero-downtime release script on the app server. Drone fits that model without forcing you off your existing Git host. A booking platform like Adventure Third Pole Trek benefits from the same pattern: test on push, deploy only from protected branches.

How Does Drone CI Compare to GitLab CI for Getting Started?

Teams ask this during every CI bake-off. Drone is not a full DevOps suite. GitLab CI ships inside GitLab with registry, issues, and permissions already wired. GitHub Actions lives inside GitHub with a massive marketplace. Drone wins when you want minimal ops overhead and already have a Git host you like.

Read GitHub Actions vs GitLab CI for a wider lens. Drone sits beside tools like Buildkite, TeamCity, and Bitbucket Pipelines — all YAML-ish, all runner-centric, differing mostly in pricing and ecosystem.

Cost matters for Nepal agencies billing in NPR. A Drone server on a Rs 2,500/month VPS (~USD 19) plus a build runner can serve many repos. GitLab SaaS per-seat fees climb faster than hardware for small shops. SaaS GitHub Actions free tiers cap minutes; self-hosted Drone trades labour for control.

What Are Common Drone CI Getting Started Mistakes in Production?

Most first-week failures repeat the same themes. I have seen them on client migrations from manual FTP deploys to any CI engine. Drone's simplicity exposes misconfiguration quickly because there are fewer moving parts to hide behind.

• RPC secret mismatch — runner never picks up jobs; verify identical strings on both sides.
• OAuth callback typo — login succeeds on HTTP but fails on HTTPS, or trailing slash breaks match.
• Docker socket on shared runners — any pipeline can mount host paths; isolate build VMs per client or use Kubernetes runners for untrusted code.
• Missing branch filters — deploy steps firing on every feature branch; use when blocks aggressively.
• Secrets in logs — echo debugging prints tokens; enable Drone's mask behavior and audit with secrets scanning in Git and CI.
• No resource limits — parallel npm and Composer jobs OOM the runner; set DRONE_RUNNER_CAPACITY conservatively.

Validate YAML before push. A malformed step name blocks the entire pipeline parse. Keep a staging repo that mirrors production permissions but deploys to a sandbox vhost. Run integration tests in CI only after unit tests pass — Drone's sequential default makes that ordering natural.

Advanced teams combine Drone with portable pipeline tools. Dagger pipelines as code can wrap the same build logic if you later swap runners. Blue-green deploys still happen on the app server — Drone only triggers them; read blue-green deployment in CI/CD for the release-side pattern.

When you outgrow a single runner, add labels (platform: linux, env: production) and target steps with node selectors. That mirrors GitLab runner tags without re-architecting your repos. For Laravel-specific test tuning, Pest in CI/CD and parallel test runs with Paratest remain valid inside Drone containers.

Debugging pipeline YAML is easier with small utilities — paste malformed config into the JSON formatter when converting plugin settings, or validate regex conditions in the regex tester before you commit trigger rules.

Key Takeaways

• Drone CI getting started splits into server install, OAuth login, runner registration, and a root .drone.yml — skip none of the four.
• Use Docker executor runners on isolated VMs; never treat a shared Docker socket as multi-tenant safe without hardening.
• Model Laravel pipelines as Composer install, Pest tests, Vite build, and a gated deploy webhook from main only.
• Pick Drone when you already have a Git host and want lightweight self-hosted CI instead of an omnibus platform.
• Protect branches, store secrets in Drone — not Git — and add cache volumes early to save runner RAM and wall-clock time.
• Plan server backups and upgrades before you activate twenty client repos; ops debt arrives quietly after the first success.

People Also Ask

Is Drone CI free for getting started?

Drone Community Edition is open source under Apache 2.0. You pay for VPS hosting, engineer time, and optional enterprise support from Harness. There is no per-minute SaaS meter like cloud-hosted Actions. For a two-person agency, that predictable cost often beats seat-based pricing.

Can Drone CI run without Docker?

The default and best-documented path is the Docker runner. Exec and SSH runners exist for bare-metal scripts, but container isolation is the main reason teams adopt Drone. Stick with Docker until you hit a concrete limitation.

Does Drone CI support monorepos?

Yes. Use trigger paths, glob filters, or separate pipeline files included via YAML anchors. Each changed app can run its own test suite. The same monorepo strategies described for PHP apps in multi-app CI guides apply with Drone trigger syntax.

How do you migrate from Jenkins to Drone CI?

Rewrite Jenkinsfile stages as Drone steps with equivalent container images. Move credentials into Drone secrets. Run both systems in parallel on a non-production repo until parity is proven. Retire Jenkins job by job rather than big-bang cutover.

Ship Your First Drone Pipeline This Week

Drone CI: Getting Started boils down to a small server, honest runner hygiene, and a pipeline file you version beside your app. Stand up a trial on one repo, protect the default branch, and prove deploy from green builds only. Once that loop works, activating the rest of your portfolio is mostly copy-paste with per-repo secrets.

If you want help designing CI for Laravel, WordPress, or a mixed client fleet — including runner hardening on Ubuntu — review the custom software development and support and maintenance services, browse the project portfolio, or contact us to walk through your Git host and deploy target.