Woodpecker vs Drone vs Concourse: Self-Hosted CI/CD on a VPS (2026)

If you run your own Git server on a VPS — Forgejo, Gitea, or plain GitLab CE — the next question always lands within a week: where do the builds run? Pushing to GitHub Actions defeats the point of self-hosting, and renting a managed CI runner per minute gets expensive fast once you have more than a couple of repos. So you start looking at self-hosted CI/CD engines, and three names keep surfacing: Woodpecker CI, Drone, and Concourse.

I have run all three in production at different points across our infrastructure. At Warung Digital Teknologi (wardigi.com) we ship Laravel, Vue, and Flutter projects for 30+ clients, and the seven aggregator sites I maintain personally all push through a self-hosted pipeline that sits next to a Forgejo instance on a Hostinger VPS. This is not a feature-table reprint from a vendor page — it is what actually held up under daily commits on small boxes. Let me walk through where each engine fits, what it costs you in RAM, and which one I would put on a 2 GB VPS today.

The short version

If you want the honest summary before the details: Woodpecker CI is the right default for almost everyone running a single VPS in 2026. It is fully open source, idles under 100 MB of RAM, and reads pipeline YAML that is close enough to the old Drone syntax that migration is mostly mechanical. Drone is technically more capable at scale but its licensing has drifted away from open source since the Harness acquisition, and the OSS build keeps losing features. Concourse is the most architecturally interesting of the three and the one I would not put on a small VPS — it wants a database, a web node, and a worker node, and the learning curve is real.

That is the conclusion. Here is how each one earns or loses that placement.

A quick history, because licensing decides this

You cannot evaluate these three without understanding how they are related, and the relationship is unusually tangled.

Drone started as an Apache 2.0 open-source project. Woodpecker is a community fork that took the last Apache 2.0 release — Drone 0.8 — and continued from there. The fork was originally created by laszlocph in 2019 (the first release, v0.8.91, shipped on 6 April 2019) and was renamed to "Woodpecker" on 27 August 2019. The fork gained real momentum in 2022 after Drone was acquired by Harness and the licensing direction shifted.

That shift matters. Drone moved from Apache 2.0 to the Business Source License, and is now published under a Polyform Small Business license under Harness. The practical effect: the Drone OSS build gets fewer features over time, and "production use" above a certain scale expects a paid arrangement. Their self-hosted build quota also tightened — it dropped from 15,000 builds in 2020 to 5,000 in 2022.

Woodpecker, by contrast, stayed open source and is governed by the community rather than a single vendor. For a small operator this is not an abstract ideology question. It is the difference between a tool that will still be free and feature-complete on your VPS in three years versus one where the open build is a loss-leader for an enterprise SKU. I have been burned by the second pattern before — it is exactly why I migrated off Drone.

Woodpecker CI: the lightweight default

Woodpecker hit 3.0.0 a while back and, as of May 2026, the current line is 3.14.x (3.14.1 at the time of writing). The architecture is dead simple: a server process that talks to your Git forge (GitHub, GitLab, Gitea, Forgejo, Bitbucket) and one or more agents that actually execute the pipeline steps inside containers.

What sold me was the resource floor. Woodpecker idles at under 100 MB of RAM. On our Forgejo VPS — a modest box also serving the Git UI — the Woodpecker server plus one agent sit comfortably in the headroom left over, and the only time memory climbs is when an actual build container spins up. Compare that to Jenkins, where the JVM alone will eat 300–500 MB before a single job runs, and you understand why Woodpecker keeps winning on small infrastructure.

Pipeline configuration lives in a .woodpecker.yml file in your repo. If you have ever written a Drone pipeline it will look familiar — steps, an image per step, commands, and when conditions for branch or event filtering. Here is the shape of a real one I use for a Laravel project:

steps:
  test:
    image: php:8.3-cli
    commands:
      - composer install --no-interaction
      - cp .env.testing .env
      - php artisan test
  deploy:
    image: appleboy/drone-scp
    settings:
      host: { from_secret: deploy_host }
      username: { from_secret: deploy_user }
      key: { from_secret: deploy_key }
      target: /var/www/app
      source: ./*
    when:
      branch: main
      event: push

Two things worth flagging from experience. First, Woodpecker reuses much of the Drone plugin ecosystem — that appleboy/drone-scp image is a Drone plugin and it runs unchanged, which makes migration far less painful than the version numbers suggest. Second, secrets are first-class: you register them per-repo or per-organization in the UI and reference them with from_secret, so deploy keys never touch the YAML. Recent releases also let you register your own agents and replay a pipeline directly from the server using CLI exec, which is genuinely useful when you are debugging a flaky deploy at 1 a.m. and do not want to push an empty commit to trigger a re-run.

Where Woodpecker bites you: it is opinionated toward container-based steps. If your build needs to run directly on the host (some Flutter/Android signing flows, for instance), you fight the model a little. The matrix build feature is also less ergonomic than I would like for large fan-out test grids. But for the standard "test, build image, deploy over SSH" loop that covers maybe 90% of what a small shop needs, it is the smoothest of the three.

Drone: capable, but check the license before you commit

Drone is, on a pure-features basis, still a strong engine. Its Docker-native execution model means there is very little infrastructure beyond the controller — workloads scale out by adding runners, and it handles Docker and Kubernetes workflows cleanly. On a single mid-size cloud instance (the commonly cited example is an AWS t3.medium at roughly $30/month) it handles small-team workloads with minimal overhead. If you are already deep in a Kubernetes-heavy environment, Drone's autoscaling runners are more mature than Woodpecker's.

The problem is not technical. It is the trajectory. Since the Harness acquisition the OSS build has steadily lost ground, and the licensing — Business Source / Polyform Small Business — means you need to read the terms carefully before you put it into commercial production at any meaningful scale. For a hobby project on your own VPS you are almost certainly fine. For a 30-client agency like ours, "almost certainly fine" is not a phrase I want attached to my CI infrastructure, because the cost of being wrong is a license bill or an emergency migration.

My blunt take: if you are starting fresh in 2026, there is little reason to pick Drone over Woodpecker. You get a near-identical syntax, the same plugin ecosystem, and a clearer license with Woodpecker. The only scenarios where I would still reach for Drone are (a) you have an existing Drone deployment that works and a migration is not worth the disruption, or (b) you specifically need a Drone-only enterprise feature and you are prepared to pay Harness for it. Otherwise the fork is the better bet for the same reason it exists.

Concourse: the powerful, demanding outlier

Concourse is a different animal, and I want to be fair to it because it is genuinely well-designed for what it targets. Where Woodpecker and Drone treat a pipeline as a config file attached to a repo, Concourse treats pipelines as first-class, declarative objects. Everything is a resource — your Git repo is a resource, your output artifact is a resource, a time trigger is a resource — and pipelines are explicit graphs of jobs that consume and produce them. When you grok it, the model is beautiful and the visualization of pipeline state is the best of the three.

The cost of that power is twofold. First, infrastructure. Concourse is not a single binary you drop next to your Git server. A real deployment is a PostgreSQL database, a web node (the ATC — scheduler and API), and one or more worker nodes that run the containers. That is three moving parts minimum, and the workers in particular are memory-hungry. On a 2 GB VPS you will not have a good time; I would not deploy Concourse on anything under 4 GB dedicated to CI, and realistically you want it on its own box or a small cluster.

Second, the learning curve. Concourse is opinionated and gives you very little scaffolding. Building a pipeline is time-consuming because you configure every single step yourself — there are no templates, and the resource abstraction that makes it powerful also means there is more to learn before your first green build. I spent the better part of a weekend getting a non-trivial Concourse pipeline working the first time, versus maybe an hour for the equivalent in Woodpecker.

So who is it for? Teams with dedicated platform engineers, complex multi-stage release pipelines, and the infrastructure budget to give CI its own nodes. If that is you, Concourse rewards the investment. If you are one person maintaining a VPS, it is overkill — you will spend more time tending the CI than the CI saves you.

Head-to-head comparison

What this actually costs to run

The whole argument for self-hosting CI is cost predictability, so let me put real numbers against it. Across the seven aggregator sites I run, the build frequency is modest — a handful of pushes per day, plus scheduled jobs. That workload does not justify a dedicated CI box. Woodpecker shares the Forgejo VPS (a 2 GB plan) and the marginal cost of CI is effectively zero because the idle footprint is so low; the only resource spike is during the few seconds a build container is alive.

Contrast that with the managed alternatives. A cloud CI service billing by the build-minute looks cheap until you have a dozen repos with test suites that run on every push. The crossover point — where self-hosting on a VPS you already pay for becomes cheaper than per-minute billing — arrives fast, usually within the first two or three active repos. The catch is that self-hosting trades a money cost for a time cost: you own patching, you own the runner security, and you own the 1 a.m. debugging. Woodpecker minimizes that time cost more than the other two, which is the real reason it is my default and not just its license.

A note on security that people skip: a CI runner executes arbitrary code from your repo, which means a compromised pipeline is a compromised host. On a shared VPS I keep build agents in containers with no host-network access and scoped deploy keys, never root SSH. This is the same discipline I apply to the import scripts on the aggregator sites — least privilege on anything that touches production. Whichever engine you pick, do not run the agent as root and do not give it broader deploy credentials than the single target it needs.

Migrating from Drone to Woodpecker

Because so many people land here already on Drone and wondering whether to jump, here is the realistic migration picture. The pipeline syntax is close but not identical — the top-level pipeline: key in old Drone becomes steps: in current Woodpecker, and a few setting names differ. Plugins largely carry over unchanged since they are just container images. In my experience the migration of a small project is a half-day job: stand up the Woodpecker server pointed at the same forge, port the YAML (mostly find-and-replace), re-enter secrets, and run both in parallel for a few days until you trust the new one. The two engines can coexist against the same Git server during the transition, which removes most of the risk.

FAQ

Can I run Woodpecker on a 1 GB VPS?

Yes, for light workloads. The server and a single agent idle under 100 MB combined, so the constraint is not Woodpecker itself but the build containers — if your test suite needs 800 MB of RAM, that is what dictates your VPS size, not the CI engine. For most PHP, Node, or Go projects a 1–2 GB box is fine.

Is Drone still free for self-hosting?

The OSS build exists and is free, but it is under a Business Source / Polyform Small Business license and the open build has lost features over time since the Harness acquisition. For personal or very small use you are fine; for commercial production at scale, read the license terms carefully before committing.

Why not just use GitHub Actions or GitLab CI?

If you are already on GitHub.com or GitLab.com and the free minutes cover you, there is no strong reason to self-host. The case for these three engines is specifically for people running their own Git forge on a VPS — at that point routing builds back out to a third-party cloud reintroduces the dependency you were trying to remove.

Does Woodpecker support Forgejo and Gitea?

Yes — both are first-class supported forges, which is exactly why it pairs so well with a self-hosted Forgejo or Gitea instance. This is the combination I run.

Is Concourse ever the right choice for a small team?

Rarely. Its strengths — declarative resource graphs, strong pipeline visualization, reproducible builds — pay off for platform teams with complex multi-stage releases and dedicated infrastructure. For a solo operator or a small shop on a single VPS, the three-component architecture and steep learning curve outweigh the benefits. Start with Woodpecker; reach for Concourse only when you have outgrown it.

The verdict

For the audience this site serves — people running real workloads on a VPS rather than a managed cloud — Woodpecker CI is the one to install first. It is open source and likely to stay that way, it runs in the memory budget of a small box, it speaks a syntax you can learn in an afternoon, and it pairs natively with the Forgejo and Gitea servers most self-hosters already run. I have it in production next to my own Git server and it has been the lowest-maintenance piece of that stack.

Pick Drone only if you are already on it and migration is not worth the churn, or if you need a specific enterprise feature and will pay for it. Pick Concourse only if you have a platform team and pipelines complex enough to justify its architecture — and give it its own hardware when you do. For everyone else, the fork won for a reason. Install Woodpecker, point it at your forge, and get back to shipping.