Drone CI vs Woodpecker CI: when each option fits
If your Drone server's license, user limits or ownership change now affects your planning, the choice comes down to whether Drone's current terms still fit your organization. Drone is now managed by Harness under the Polyform Small Business license, with a separate Enterprise Edition, so a commercial license is the first thing to check. Drone can remain the right choice if your organization qualifies for the Small Business terms and the Enterprise Edition terms are acceptable for the rest of your estate. Confirm eligibility and the exact user terms directly with Harness in writing before you rely on them.
Woodpecker CI fits when you want a self-hosted engine with no per-user license limits. It is licensed under Apache-2.0 and is the community fork of Drone 0.8, created in 2019 after Drone's license changed from Apache 2.0 to a proprietary license. Its About page describes that history. Woodpecker is also the active open-source line for teams that want to keep the Drone pipeline model, so the migration effort is mostly about syntax, plugins and secrets rather than a new CI paradigm.
The decision turns on five checks: license eligibility and user count, the forge mix (Woodpecker supports GitHub, Gitea, Forgejo, GitLab, Bitbucket and Bitbucket Datacenter, but multi-forge use on one server is still experimental), the plugin inventory (Drone plugins generally work but may need adjustments), and who will operate the server, including upgrades, backups and the database. Write down your answer to each before you choose, because the operating burden of Woodpecker falls on your own team unless you contract support.
Which scenarios favor Drone and which favor Woodpecker CI
This table matches common situations to the platform that fits them better, with the condition that drives each choice. Read each row against your own license position, forge, cluster model and plugin inventory, and confirm current Drone license terms directly with Harness before deciding.
| Scenario | Better fit | Condition that drives the choice |
|---|---|---|
| Small team that may qualify for the Polyform Small Business license | Drone | Eligibility depends on the current license terms, which Harness sets. Confirm the thresholds and user limits in writing with Harness before relying on them. |
| Organization above the Polyform Small Business thresholds or user limits | Woodpecker CI | Woodpecker is Apache-2.0 licensed, so license eligibility does not limit how many users run it. Drone Enterprise would require a commercial agreement with Harness. |
| Team that needs Bitbucket Datacenter or GitLab forge support | Woodpecker CI | Woodpecker's forge documentation lists Bitbucket Datacenter and GitLab. Confirm the Drone forge list for your version with Harness before choosing Drone. |
| Team that needs several forges on one server | Woodpecker CI, with caution | Connecting multiple forges to one Woodpecker server is documented as experimental, so validate it in a staging environment first. |
| Kubernetes-first platform team | Woodpecker CI | Woodpecker's Kubernetes backend runs each step in a standalone pod and creates a temporary persistent volume claim per pipeline. Test storage class and access mode in your cluster. |
| Team with many custom Drone plugins | Depends on plugin inventory | Drone plugins generally work in Woodpecker but may need adjustments. Test each plugin's settings block and images before cut-over. |
| Team that wants an unchanged Drone 0.8 era pipeline | Drone | Woodpecker started from Drone 0.8, so existing pipelines are close, but pipeline files and secrets still need renaming and review during migration. |
How Drone pipelines map onto Woodpecker syntax and plugins
Woodpecker workflows are YAML files, and the migration starts with how you organize them. A team can keep a single .woodpecker.yaml file at the repository root or split its pipeline into several files inside a .woodpecker/ directory. Files in that directory run as parallel workflows, and depends_on sets the order where one workflow must wait for another. Map each existing Drone pipeline to one of these layouts before you touch any file, because a Drone pipeline that relied on sequential steps may need depends_on declarations to behave the same way. Inside each workflow, every step runs its commands in a container image you specify, optional services containers can run alongside it, and when filters on event, branch, path and other conditions control whether a step runs. Matrix builds cover the cases where one Drone pipeline fanned out across several values. Compare the output of a few representative builds in both systems to confirm that the same steps run under the same conditions.
Plugins carry most of the compatibility risk. Woodpecker plugins are container images configured through a settings block in a pipeline step, and they are listed in the plugin index on the Woodpecker site. The Woodpecker documentation says Drone plugins generally work but could need some adjustments, and it does not guarantee that every plugin behaves the same way. Build a full inventory before cut-over: every repository, every pipeline file, every plugin image with its tag, and every environment variable or secret each plugin reads. Then run each pipeline on a test instance and record the result, including build artifacts, notifications and deployment steps that depend on plugin side effects. Plugins that have no current Woodpecker listing, or that were last updated long ago, need a decision: adjust the settings, replace them with a shell step or a maintained image, or retire them. Ask the team that owns each deployment step to sign off on its test result before the production switch.
Capability comparison: Drone CI and Woodpecker CI
This table compares licensing, forge support, execution backends, database options, autoscaling, Helm chart availability and release activity for Drone CI and Woodpecker CI. Woodpecker cells are drawn from its documentation and release notes, while Drone cells mark what must be confirmed with Harness, because the supplied facts do not describe Drone's current feature set.
| Capability | Drone CI | Woodpecker CI |
|---|---|---|
| License | Polyform Small Business license with an Enterprise Edition, managed by Harness | Apache-2.0, with documentation under CC BY-SA 4.0 |
| Owner and origin | Managed by Harness after the license change from Apache 2.0 | Forked from Drone 0.8 in 2019 and renamed Woodpecker on August 27, 2019 |
| Licensing eligibility and user limits | Confirm current eligibility and user limits with Harness before use | No user limits under the Apache-2.0 license |
| Forges supported | Confirm the current forge list with Harness | GitHub, Gitea, Forgejo, GitLab, Bitbucket and Bitbucket Datacenter with push, tag and pull request events; multiple forges on one server is experimental |
| Execution backends | Confirm the current backend list with Harness | Docker, Kubernetes and local machine |
| Database options | Confirm supported databases with Harness | SQLite by default; PostgreSQL or MariaDB recommended for larger instances |
| Autoscaling | Confirm autoscaling options with Harness | Optional autoscaler that creates cloud VMs for pending builds |
| Helm chart | Confirm chart availability with Harness | Official Helm chart documented |
| Release activity | Confirm the latest release history with Harness | 3.18.0 on August 24, 2026; 3.18.1 in September 2026; 3.19.0 on October 7, 2026 |
Where pipeline data, secrets and build history live under each option
Drone CI and Woodpecker CI both run as a server with agents, so the first question is where each component, its database and its stored secrets sit. The cards below cover the decisions that follow from that answer: infrastructure placement, secret handling, log and artifact retention, forge application ownership and the evidence an assessor will ask for.
Server, agents and database placement
Woodpecker runs a server that serves the UI and API and receives forge webhooks, plus agents that run workflows and connect over gRPC. The database defaults to SQLite, with PostgreSQL or MariaDB recommended for larger instances. Every one of these components runs in the infrastructure you choose, so the database and the agent hosts define your data boundary. Confirm which network zone each agent can reach and where backups of the database are stored.
Secret storage and access
Pipeline secrets are stored on your Woodpecker server, so their protection depends on your database encryption, server access controls and who holds administrator rights. Hosted CI services hold secrets for every connected project, and CircleCI's January 2023 incident forced customers to rotate everything. Plan to rotate all deployment credentials during cut-over instead of copying them, because vendor APIs do not return secret values for export.
Build logs and artifact retention
Woodpecker keeps build logs and artifacts in your own database and storage, so retention is set by your policy rather than a vendor default. Hosted services set limits, such as 90 days for GitHub Actions artifacts and 14 days at most for Bitbucket Pipelines. Decide how long logs and artifacts must be kept, who may read them and how they are exported before you retire the old system. Confirm how your storage backend handles deletion and legal holds.
Forge OAuth application ownership
Woodpecker connects to your forge through an OAuth application that you register and host. Whoever creates that application controls its client secret, its callback URL and the scopes it grants to builds. Record the owning team and the account used to register it, and plan a rotation schedule. During migration, create the new application under a controlled service account instead of a personal account, so that the forge connection survives staff changes.
Identity and audit evidence
An assessment will ask who can change pipelines, approve deployments, read secrets and administer the server, and how those actions are recorded. Prepare an access roster for server administrators and agent operators, the authentication method for the UI, and exported logs of configuration changes. DeployOpen prepares controls and evidence for compliance assessments but does not issue audit reports or certifications. Independent auditors and certification bodies make that determination, so confirm their evidence requirements early.
Which Woodpecker agent backend fits your infrastructure
Woodpecker agents can run workflows on Docker, and this is the simplest topology to start with. Each agent runs on a host with a container runtime, connects to the Woodpecker server over gRPC, and executes each step inside the container image named in the pipeline. Scaling means adding agents, and the server schedules work across them.
- Fewer moving parts: There is no cluster to operate, so the platform team only maintains hosts, the runtime and the agent process.
- Agent connection: Agents need a network route to the server and a shared secret, so plan firewall rules and certificate handling first.
- Build isolation: Steps run in containers, but a Docker host is still a shared machine, so confirm how privileged builds and image caches are handled.
- Capacity: Adding hosts is manual unless you add the optional autoscaler.
- Migration fit: Teams already running Drone agents on Docker often map their existing host layout directly.
Confirm with the Woodpecker documentation which Docker options your pipelines need, especially any that require privileged mode.
The Kubernetes backend runs each step in a standalone pod. Woodpecker also creates a temporary persistent volume claim for the pipeline, with 10G and ReadWriteMany as the defaults, so steps can share files. Storage class and access mode therefore need planning before the first pipeline runs, because not every storage backend offers ReadWriteMany.
- Pod per step: Each step gets its own pod, which gives clean isolation but adds scheduling overhead.
- Shared volume: The 10G ReadWriteMany claim is created per pipeline and must be provisioned by a storage class that supports the mode.
- Storage planning: Check the storage class, its quota and how volumes are cleaned up after pipelines finish.
- Cluster access: Agents need permissions to create pods and claims in the namespace you choose.
- Helm deployment: The Woodpecker Helm chart is the documented installation path for clusters.
Before deciding, confirm how Drone's Kubernetes and agent model compares with this pod and volume design, and test the storage class with a sample pipeline.
Woodpecker agents can also run workflows directly on the local machine. This suits small teams, isolated build hardware or specialized targets that a container or cluster cannot reach easily. The trade-off is that builds share the host's tools, state and security boundary.
- Simple setup: A single machine can run the server and an agent for a pilot.
- Shared state: Builds on the same host can affect each other through files, caches and installed tools.
- Host hardening: The machine must be patched, access-controlled and monitored as part of the CI trust boundary.
- Limited scale: Capacity depends on one machine unless you add more agents by hand.
- Specialist hardware: Useful for builds that need devices or licenses bound to a specific host.
Confirm which workflow features are supported on the local backend for your pipelines before relying on it for production deployments.
The optional autoscaler is a Woodpecker component that creates cloud VMs for pending builds. It watches the queue, starts agent machines when work arrives and lets capacity drop when the queue is empty. This model fits bursty workloads, but it adds cloud accounts, images and networking to the platform.
- Demand-driven capacity: VMs are created for pending builds rather than kept running all the time.
- Cloud dependency: Account quotas, image management and network access to the server all become operational items.
- Cost drivers: Idle time, VM size, image build frequency and data transfer determine the recurring cost.
- Security scope: Each VM needs credentials and hardening, and the autoscaler itself needs tightly limited cloud permissions.
- Data residency: Confirm which regions and accounts the VMs use against your residency rules.
Confirm the autoscaler's supported providers and configuration options in the Woodpecker documentation before estimating cost with your cloud team.
What the switch costs: components, one-time and recurring
The cost of moving from Drone to Woodpecker is less about a license line and more about who pays for infrastructure, operations and migration work. Each component below is one-time or recurring in a different way, and each responds to different drivers. Ask for every component separately in any quote so the comparison stays like for like.
Drone subscription or Enterprise terms
Drone is now managed by Harness under the Polyform Small Business license, with an Enterprise Edition. Whether you pay anything depends on your organization's size and user count, so the cost is recurring if a commercial license applies. Ask Harness for the current written terms, including the user limits per instance, what counts as a user, support levels and how renewals are priced. Confirm these against your own headcount before comparing any other line.
Woodpecker software licensing
Woodpecker is licensed under Apache-2.0, so the software itself carries no license fee and no user cap. Your costs shift to the infrastructure and staff that run it. Because the license is permissive, you can run it for as many users and agents as your environment supports. Confirm with your legal team that the Apache-2.0 terms fit how you plan to package or modify it.
Infrastructure for server, database and agents
Woodpecker runs a server, a database and one or more agents, and can add an optional autoscaler that creates cloud VMs for pending builds. Infrastructure is recurring and grows with concurrent builds, agent count and pipeline run volume. SQLite works by default, but PostgreSQL or MariaDB is recommended for larger instances, which adds database hosting and backup cost. Ask for sizing based on your peak concurrent builds and the Docker or Kubernetes backend you choose.
Platform team operating time
Upgrades, backups, forge OAuth maintenance and monitoring are recurring staff effort. The effort rises with uptime requirements, the number of forges connected, and how often new Woodpecker releases must be tested against your pipelines. Recent releases include 3.18.0, 3.18.1 and 3.19.0, so plan a regular upgrade cadence. Ask any implementation partner to state the upgrade, backup and restore testing included in a fixed scope.
Pipeline, plugin and secrets migration
Moving pipelines is mostly one-time work: renaming files to .woodpecker.yaml or a .woodpecker directory, reviewing Drone plugins that the project says may need adjustments, and re-entering secrets and forge OAuth applications. Effort rises with pipeline count, custom plugins and the number of teams whose secrets must be recreated. Drone secrets cannot be assumed to export cleanly, so budget for re-creation and verification.
External support and testing
Vendor support for Drone Enterprise is recurring and only applies if you buy it. Woodpecker is community-supported, so paid support, upgrade services and security testing of your pipelines are optional and recurring if you choose them. Their cost depends on scope, response expectations and how many pipelines and forges they cover. Ask for these as separate line items with a defined fixed scope, deliverables and renewal terms.
How a move from Drone to Woodpecker CI runs in phases
The sequence turns an inventory of Drone pipelines, plugins, secrets and forge applications into a Woodpecker install that runs beside Drone until each project is verified, then retires Drone. Each phase ends with a check that the next one can rely on.
Inventory pipelines, plugins, secrets and forge applications
The platform or CI owner lists every repository wired to Drone, the pipeline files it uses, the Drone plugins each step calls, the secrets stored in Drone, and the OAuth application that connects Drone to each forge. Drone and Woodpecker databases and secrets are not interchangeable, so this list is the baseline for every later check. Done when each repository has one row with its forge, pipeline path, plugins and secret names, and the owner has signed off on the list.
Rename pipeline files to Woodpecker layout
Engineers move each Drone pipeline to either a single .woodpecker.yaml file or a .woodpecker/ directory, then review the YAML against the Woodpecker workflow syntax, since workflows in a directory run as parallel workflows with depends_on ordering. Conditions, services and matrix settings are checked line by line rather than assumed to carry over. Done when every renamed file parses on a branch in a test repository and the owner has compared it with the original.
Adjust and test each plugin
The team checks each Drone plugin against the Woodpecker plugin index, because the Woodpecker documentation says Drone plugins generally work but may need adjustments. Settings blocks, environment variable names and container images are tested on a non-production pipeline, and any plugin without a working equivalent is flagged for a replacement step. Done when every plugin in the inventory has a recorded result: works unchanged, works with changes, or needs a replacement.
Deploy Woodpecker server and agents
The platform team installs the Woodpecker server and agents with the database chosen for the instance, SQLite by default or PostgreSQL or MariaDB for larger installations, and selects the backend the agents will use: Docker, Kubernetes or the local machine. On Kubernetes, the Woodpecker Helm chart is the documented installation route, and the team confirms that the Kubernetes backend's shared persistent volume claim fits the storage class and access modes available in the cluster. Done when the server shows healthy agents and a test pipeline completes end to end.
Recreate secrets and forge applications
Drone secret values usually cannot be exported in readable form, so the team confirms each secret value from its owner and enters it again in Woodpecker. Woodpecker also needs its own forge OAuth application, created on the forge with the callback address for the new server. Done when every secret from the inventory is set on the new server, a test pipeline reads each one without printing it, and the forge shows the new application as connected.
Run both servers side by side during cut-over
Projects move in batches. For each batch, the team points the forge webhook at Woodpecker, keeps the Drone job available for rollback, and compares build results, artifacts and deployment outcomes for the same commits on both systems. Forges can connect to only one server for a given repository at a time, so the team confirms which server receives each webhook before switching. Done when every batch shows matching outcomes and a named owner has accepted the cut-over for that batch.
Retire Drone after verification
Once every repository in the inventory has passed its cut-over check, the team disables Drone webhooks, exports any build history and logs that the organization must keep under its retention policy, and shuts down the Drone server and its database. Drone's license terms and any stored secrets are removed according to the decommissioning record. Done when no repository sends events to Drone, the exports are stored and checked, and the decommissioning record is filed with the owners.
Questions buyers ask before moving from Drone CI
How much does moving from Drone CI to Woodpecker CI cost?
The software itself carries no license fee, because Woodpecker CI is licensed under Apache-2.0. The cost is the work and the infrastructure: the Woodpecker server and agents, a database, forge OAuth applications, compute for agents, and the people who migrate pipelines and run the system afterward. Recurring costs come from compute, storage for build history, and support or upgrade effort. One-time costs cover pipeline conversion, secret re-entry, testing and cut-over. Costs rise with the number of repositories, the number of plugins that need adjustment, and how many forges are connected. Ask for a quote built from a written scope that lists each of these components separately.
How long does a Drone to Woodpecker migration take?
The timeline depends on the number of pipelines, how many use Drone-specific plugins or settings, how many secrets and forge OAuth applications must be moved, and whether the two servers will run side by side during cut-over. Teams with a small, well-documented set of pipelines usually move faster than teams with many shared pipeline templates. Woodpecker's own documentation describes running both servers in parallel as part of the migration approach, which adds time for verification. Ask for a timeline in the written scope that breaks the work into inventory, conversion, testing and cut-over phases, with the repositories covered by each phase named.
What does our internal team need to provide during the migration?
The internal team provides access and decisions that an outside engineer cannot make alone. That includes administrator access to the current Drone server, the forges and the target hosting environment, approval for new OAuth applications on each forge, and a named owner for each pipeline who can confirm expected behavior. Security or compliance staff should approve how secrets are re-entered and where the new server stores them. Plan for these people to be available at the review points in the schedule. Confirm the exact list of roles and approvals in the written scope before work starts.
Can our own team migrate from Drone to Woodpecker without outside help?
Yes, a team with experience running CI servers and container runtimes can attempt the migration in-house, and the Woodpecker documentation covers workflow syntax, plugins and the Docker and Kubernetes backends. The main risks for an internal team are the number of pipelines to convert, the secrets that cannot be exported from Drone and must be re-entered, and the cut-over itself, where a mistake can break deployments. Decide based on your team's available capacity and how many pipelines you run. A fixed-scope engagement with DeployOpen covers planning, implementation, hardening, backup and documentation, so you can compare the in-house effort with a written scope.
Can Woodpecker run beside our existing Drone pipelines during the move?
Yes, running both servers side by side is the usual approach for a staged move. Woodpecker can be deployed alongside Drone, so pipelines can be converted and verified one repository at a time while Drone keeps serving the rest. The overlap must be managed carefully, because both systems can react to the same forge events and each needs its own forge integration during the transition. Agree on which repositories switch on which date, and make sure webhooks are pointed to the correct server at each step. The cut-over plan belongs in the written scope.
Will our Drone plugins and forge integrations work in Woodpecker?
Most Drone plugins are expected to work, but the Woodpecker documentation states that some may need adjustments, so each plugin in use should be checked against its settings block and image. Woodpecker lists GitHub, Gitea, Forgejo, GitLab, Bitbucket and Bitbucket Datacenter as supported forges, with push, tag and pull request events on all of them. The documentation also states that connecting multiple forges to one server is still experimental, so a setup spanning several forges needs extra testing. Ask for a plugin inventory in the scope and confirm each forge you use is on the supported list for your version.
How do we confirm the current Drone license terms before deciding?
Check the license terms directly with Harness, which manages Drone under the Polyform Small Business license, and read the license text that applies to your version and organization. Woodpecker's about page records that Drone changed from Apache 2.0 to a proprietary license and that Woodpecker forked Drone 0.8 in 2019. Confirm user limits, revenue thresholds and any Enterprise Edition conditions in writing with Harness, and record the answers in your decision file. Your legal or procurement team should review them, since license terms can change and this page does not interpret them for your organization.
How DeployOpen helps evaluate and migrate to Woodpecker CI
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure, so a Drone to Woodpecker decision is handled as a written, fixed-scope engagement. We start from your forges, pipelines and plugins, then build and test the Woodpecker setup in your environment before any cut-over.
How we scope
- Inventory repositories, pipelines, Drone plugins, secrets and forge OAuth applications in scope for the move
- Confirm which forge, backend (Docker, Kubernetes or local) and database the Woodpecker server will use
- Agree the written scope, deliverables and timeline before any work starts, since most engagements are fixed-scope
How we build
- Stand up the Woodpecker server and agents in your cloud accounts, data centers or air-gapped network
- Convert Drone pipelines to .woodpecker.yaml or .woodpecker directory workflows and test plugin steps that need adjustments
- Run both servers side by side during cut-over and test pipelines against real repository events before switching
How we hand over
- Document the installation, pipeline conventions, secret handling and backup procedures for your engineering and operations teams
- Hand over configuration and runbooks, with a record of each migrated repository and its verified pipeline status
- Provide evidence and controls for your compliance team to review, while independent auditors remain responsible for any assessment
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover
- Track Woodpecker releases and plan upgrades in your change process, starting with the latest project release notes
- Confirm with your team which support scope, response expectations and upgrade cadence the retainer should cover
