Migrate from Drone CI to Woodpecker CI

Migrate from Drone CI to Woodpecker CI: what the move involves

Teams leaving Drone usually do so because of its license change to a proprietary model and the Polyform Small Business terms that now govern it. The migration is mainly pipeline file conversion, plugin checks and secret re-entry, and it does not require moving repositories, because Woodpecker CI was forked from Drone 0.8 in 2019 and connects to the same forges Drone already uses. The work falls to platform or DevOps engineers, often with an implementation partner such as DeployOpen, who can plan the cut-over in a written, fixed scope before any pipeline is touched.

Start with an inventory. List every repository that uses Drone, every .drone.yml file, every plugin image referenced in a step, and every secret and forge OAuth application the server depends on. Pipeline files move to .woodpecker.yaml or a .woodpecker/ directory, and the Woodpecker workflow syntax documentation shows where steps, when filters and services map over. Plugins are the main source of surprises: the Woodpecker plugin documentation says Drone plugins generally work but could need some adjustments, so each plugin image needs a test run on a non-production repository. Confirm the exact pipeline behavior in your own environment rather than assuming it carries over.

Secrets cannot be exported from Drone, so plan for re-entry. Each secret must be recreated in Woodpecker from the source system that holds the original value, and the forge OAuth application must be registered again for the Woodpecker server with the same callback settings. Run both servers side by side during cut-over: keep Drone active on the repositories you have not yet moved, switch webhooks one project at a time, and retire Drone only after you have confirmed that builds, deployments and notifications behave correctly. The Woodpecker forges overview is the right reference for confirming forge support on your version before you start.

Which Drone features map cleanly to Woodpecker

This table maps the main Drone pipeline, execution and forge features to their Woodpecker equivalents and marks each as clean, needs rework or gap. Read the rows as a checklist of what your existing pipelines will and will not carry over unchanged. Most core pipeline concepts translate directly, but plugins, multi-forge setups and any custom Drone server configuration need checking before cut-over.

Drone feature	Woodpecker equivalent	Migration status
Pipeline YAML in .drone.yml	Single .woodpecker.yaml file or several files in a .woodpecker/ directory	Needs rework: rename files and review the syntax for each pipeline
Steps running in container images	Steps run commands inside a specified container image	Clean: the step model maps directly to Woodpecker workflows
when conditions on event, branch and path	when filters on event, branch, path and other conditions	Clean: confirm each condition against the workflow syntax reference
Services containers	Optional services containers in the workflow definition	Needs rework: check service definitions and networking in each pipeline
Plugins as container images	Plugins configured through a settings block; the docs say Drone plugins generally work but may need adjustments	Needs rework: test every plugin in a staging pipeline before cut-over
Docker execution on agents	Agents run workflows on Docker, Kubernetes or the local machine	Clean: confirm the agent backend matches your current Drone runner setup
Kubernetes execution	Kubernetes backend runs each step in a pod with a shared temporary volume claim (10G, ReadWriteMany by default)	Needs rework: review storage class and volume sizing for your cluster
Push, tag and pull request events on GitHub, Gitea, Forgejo, GitLab, Bitbucket and Bitbucket Datacenter	Same event types supported on each listed forge	Clean for one forge per server; connecting multiple forges to one server is experimental

Migration sequence from inventory to decommission

This sequence moves Drone pipelines to Woodpecker CI in controlled stages, so each repository is proven on the new engine before forge webhooks and OAuth are switched. Each step closes with a written output that the team can review before moving on.

Inventory repositories, pipelines, plugins and secrets
The platform team exports the list of active repositories, their .drone.yml files, every plugin image and version each pipeline calls, and the secrets each build reads. It also lists the forge OAuth applications and webhook settings that Drone uses, and records which secrets can be exported. Secret values usually cannot be read back from a hosted CI service, so the inventory notes which values must be re-entered from the source system. The output is a single inventory sheet with one row per repository, and the owners of each row confirm it is complete.
Classify plugins and pipeline features
Each plugin on the inventory is checked against the Woodpecker plugin index and its settings block is compared with the Woodpecker workflow syntax. Pipelines using Drone-specific features, such as custom volumes, services or conditions, are marked for manual conversion. Plugins that need changes are assigned an owner and a test case. The output is a classified list with three groups: works unchanged, needs adjustment, and needs replacement.
Stand up a Woodpecker server and agents
The team installs the Woodpecker server and at least one agent in its own infrastructure, choosing the database that matches the expected size, with SQLite as the default and PostgreSQL or MariaDB recommended for larger instances. The forge connection points at the same Git server that Drone uses, and the agent backend (Docker, Kubernetes or local) is set for the workload. The output is a running server with a test agent that reports healthy and runs a trivial pipeline.
Convert and run a pilot repository
One low-risk repository is chosen and its pipeline is rewritten as .woodpecker.yaml or as a .woodpecker/ directory, with secrets re-entered in Woodpecker and adjusted plugin steps. The pilot is enabled on the Woodpecker server while Drone stays active for the same repository. The output is a converted pilot pipeline, a list of every change made to the original file, and a short record of the first successful builds on the new server.
Run Drone and Woodpecker in parallel
For each migrated repository, both servers build the same commits for a agreed observation window. Build status, duration, artifacts, test results and deployment outputs are compared commit by commit, and any mismatch is logged with its cause. Secrets and deploy credentials are scoped so that only the approved server can publish. The output is a signed-off parallel run log that names the reviewer and records every difference found and how it was resolved.
Cut over webhooks and OAuth
Once the parallel run log is approved, the forge webhooks for the repository are pointed at the Woodpecker server, and the Woodpecker OAuth application on the forge is registered and verified. Drone's webhook is disabled for that repository, and the team confirms that a push and a pull request trigger a Woodpecker build. The output is a cut-over record listing each repository, the time of the switch, and the verified events.
Decommission Drone
After every repository in the inventory has run on Woodpecker for a stable period, the Drone server, its agents and its database are stopped, and the Drone OAuth application is removed from the forge. Drone's database and any stored secrets are backed up according to the retention policy before deletion, and the backup location is recorded. The output is a decommissioning record that confirms no webhooks, tokens or agents still point at Drone.

What data and integrations need to move, and what does not export

Drone pipelines, secrets, forge registrations, build history and plugin settings do not all move the same way. Pipeline files travel with Git, while credentials, server records and history must be recreated or archived separately. Confirm Drone's own export options in your installed version before you plan the cut-over.

Pipeline files in the repository

Pipeline definitions live in the repository, so they move with Git. Woodpecker reads either a single .woodpecker.yaml or a .woodpecker/ directory, so you will rename or restructure the Drone .drone.yml file and split it into workflows where that helps. Check every when filter, depends_on relationship and matrix definition after the rename, because a file that parses is not the same as a file that behaves the same way.

Secrets must be re-entered

Secret values rarely export from CI systems, so plan to re-enter them on the Woodpecker server rather than expect a file export from Drone. Inventory every secret by name, scope and the projects that use it, then record which ones are deployment credentials that need rotation at the same time. Confirm with your Drone version whether secret values can be read back through its interface or API before you assume anything about the export.

Forge OAuth and application registrations

Woodpecker connects to your forge through its own OAuth or application registration, so the Drone registration on GitHub, GitLab, Gitea, Forgejo or Bitbucket does not transfer. Create a new registration that points at the Woodpecker server URL, then set its client ID and secret in the server configuration. Users may need to sign in again, and repository webhooks must point at the Woodpecker server before any build runs.

Build history and logs

Build history and logs are stored in Drone's database and are not converted into Woodpecker's database. Export what you need for audit or incident review while the Drone server is still running, and store it in a location your retention policy allows. Woodpecker starts with an empty history, so note the cut-over date and any run numbers your teams reference.

Webhooks and plugin settings

Webhooks are configured per repository on the forge, so each repository must point to the new server before its builds move. Plugin settings are part of the pipeline YAML and move with it, but many Drone plugins need small adjustments in Woodpecker, so test each plugin step in a non-production repository. Confirm the plugin images and tags you use are still published and supported.

How Woodpecker's server, agents and forge connection replace Drone's setup

The Woodpecker setup is split into a server and agents, and mapping your current Drone deployment onto those roles is the first planning step. The server provides the UI and API, receives forge webhooks and parses the pipeline YAML. Agents run the workflows and connect back to the server over gRPC, so each agent needs a network path to the server and a shared secret configured at install time. Before you copy any configuration, list every Drone server and runner you operate today and note which ones run on Docker, Kubernetes or the local machine, because Woodpecker agents support those same execution backends. The optional autoscaler, which creates cloud VMs for pending builds, only matters if your Drone runners already scale on demand; confirm its exact settings in the Woodpecker administration documentation before you design the target layout.

The database choice is a decision you make early. Woodpecker uses SQLite by default, which is suitable for a small trial, while PostgreSQL or MariaDB is recommended for larger instances. Moving from SQLite later means a data migration, so if you expect a multi-team deployment, plan for PostgreSQL or MariaDB from the start, along with backups of that database. Also confirm the forge connection for your platform in the Woodpecker forges overview. The documentation lists GitHub, Gitea, Forgejo, GitLab, Bitbucket and Bitbucket Datacenter with push, tag and pull request events, but it says that connecting multiple forges to one server is still experimental, so run one forge per server unless you have tested otherwise.

Running both servers side by side is the safest cut-over pattern, because both Drone and Woodpecker can point at the same forge while you move webhooks one repository at a time. Enable the Woodpecker repository, add the .woodpecker.yaml or .woodpecker/ workflow files, and confirm a test build on a non-production branch. Then switch the webhook for that repository to Woodpecker and disable the Drone build for it. Keep Drone running until every repository has passed a full release cycle, and do not let both systems deploy the same environment at once. Note that the forge can only send each webhook to one destination, so a repository should never be active in both servers at the same time. Keep a written rollback step for each repository that returns its webhook to Drone.

How the migration differs by starting point

A small team running Drone agents on Docker hosts with a handful of plugins usually has the shortest path. The server, a few agents and a single pipeline per repository can often be reproduced on Woodpecker with a new server and agent pair, and the main effort is reviewing each pipeline file. Woodpecker workflows are YAML files that run as steps inside container images, so most Drone pipelines translate with light edits.

Pipeline files: Rename the existing .drone.yml to .woodpecker.yaml, or split it into a .woodpecker/ directory when you want several workflows that run in parallel with depends_on ordering.
Plugins: Check each Drone plugin against the Woodpecker plugin index. The docs say Drone plugins generally work but could need adjustments, so test each one in a non-production repository.
Agents: Confirm that the agent backend (Docker or the local machine) matches what the old agents did, since Woodpecker agents connect to the server over gRPC.
Database: SQLite is the default, which is usually enough for a small instance.
Secrets: Drone secrets are not exported as values, so plan to re-enter them in Woodpecker.

Confirm that every plugin used in production has a tested replacement before you retire the Drone server.

What usually goes wrong and how to prevent it

Most failed Drone to Woodpecker cut-overs trace back to a short list of causes: missing configuration, plugins and pipelines that depended on Drone behavior, and two servers acting on the same repositories at once. Each card below names one of these risks and the check that prevents it.

Secrets left unset

Drone secrets do not carry over to Woodpecker automatically, so a pipeline that reads an unset secret can fail or, worse, skip a deploy step without an obvious error. Build an inventory of every secret each pipeline references, create it in Woodpecker at the right scope (repository or organization), and run a dry build on a non-production branch before switching traffic. Values usually have to be re-entered, since Drone secret values are typically not exportable.

Plugin settings that behave differently

Drone plugins generally work in Woodpecker, but the docs warn that some may need adjustments. A plugin that reads a setting by a different name, or assumes a Drone-specific environment variable, can run without error and still publish the wrong artifact or target. Compare each plugin step against the plugin index entry, and test any step that pushes images, deploys or sends notifications in a sandbox first.

Webhooks firing on both servers

While Drone and Woodpecker run side by side, a single push can trigger a build on each server if both are registered with the same forge. Duplicate builds waste agent capacity and can race to set the same commit status or deploy the same tag. Keep forge webhooks pointed at one server per repository, move repositories in batches, and confirm in the forge's webhook log that only the new server receives events after each batch.

Pipelines relying on Drone behavior

Pipelines written for Drone can depend on details that differ in Woodpecker, such as how the file is discovered, how steps and services are named, or which conditions and event filters apply. Parse every existing pipeline with the Woodpecker workflow syntax reference, converting to a single .woodpecker.yaml or a .woodpecker directory, then compare the step graph with a Drone run on the same commit. Treat any unexplained difference as a blocker until it is understood.

Experimental multi-forge setups

Woodpecker's forge documentation states that connecting multiple forges to one server is still experimental. Teams that consolidate several Git hosts onto one Woodpecker server, for example during a forge change, should not assume that behavior is production-ready. Confirm the exact forge combination you need against the current forge documentation, and where it is not supported, run one Woodpecker server per forge during the transition.

Skipped review of matrix and clone behavior

Woodpecker 3.19.0 fixed an injection of matrix environment variables into the default clone step and enforces agent labels on the server. Pipelines that rely on matrix variables reaching the clone step, or on agents running without labels, may change behavior after an upgrade. Before choosing a version, review the release notes for 3.19.0 and re-run matrix and clone-dependent pipelines to confirm the output still matches what Drone produced.

What drives effort and cost, and how to keep each down

This table lists the factors that set the size of a Drone to Woodpecker move, from repository and plugin counts to forge and backend choices. Read each row as a question to answer in your own environment before asking for a written quote.

Driver	Why it changes effort or cost	How to keep it down
Repositories and pipelines	Each repository needs its pipeline file converted, tested on a branch and reviewed. Pipelines using several parallel workflows take more checking than single-file ones.	Inventory active repositories first, archive unused ones, and convert pipelines in batches grouped by shared templates.
Plugins and custom images	Drone plugins generally work in Woodpecker but may need settings or image adjustments. Plugins with no index entry or private images need their own testing.	List every plugin and image used, check each against the Woodpecker plugin index, and retire plugins that duplicate a built-in step.
Secrets count and owners	Drone secret values cannot be exported, so each one must be re-entered by someone who holds the original value. Ownership gaps slow the work.	Record each secret's owner, scope and consuming repositories before migration, and rotate credentials during cut-over.
Forge type	GitHub, Gitea, Forgejo, GitLab and Bitbucket each need an OAuth or application registration, webhook setup and event testing. Connecting more than one forge to a server is still experimental.	Keep one forge per Woodpecker server where possible and confirm event coverage for push, tag and pull request on your forge version.
Kubernetes or Docker backend	A Kubernetes backend runs each step in its own pod and creates a temporary persistent volume claim per pipeline, which needs storage and cluster policy work. A Docker backend needs agent hosts and image pull planning.	Pick the backend that matches existing operations skills, size the shared volume policy early, and pilot on a small agent pool.
Build log and artifact retention	Logs and artifacts that must be kept for audit need an export or archive process, since the new server does not inherit old history. Retention rules also affect storage sizing.	Agree retention periods with compliance, export required history from Drone before shutdown, and write the archive location into the runbook.
Approval teams	Each team that owns pipelines, deployments or secrets must review its conversions and sign off on cut-over, which adds scheduling time.	Name one approver per team, use a shared checklist, and agree in writing who signs off before cut-over starts.
One-time work	Conversion, a pilot on non-production repositories, and the cut-over itself are paid once. Scope these in the written quote with clear deliverables.	Ask for a fixed scope covering pipeline conversion, secret transfer, the pilot and the cut-over plan, with named acceptance steps.
Recurring work	Woodpecker upgrades, agent maintenance, backups of the server database, and support continue after cut-over. The database default is SQLite, with PostgreSQL or MariaDB recommended for larger instances.	Ask the quote to separate recurring items, choose a production database early, and confirm who patches agents and performs restore tests.

Questions buyers ask before moving from Drone to Woodpecker

How much effort does moving from Drone to Woodpecker take?

The effort depends mostly on how many pipelines you have, how many Drone plugins they call, and how many secrets and forge OAuth applications must be recreated. Pipeline files usually need renaming and some syntax review, since Woodpecker workflows are YAML files either as a single .woodpecker.yaml or as several files in a .woodpecker/ directory. Plugins are the main unknown: the Woodpecker docs say Drone plugins generally work but could need some adjustments, so each one in use must be checked against the plugin index. Secrets are the other large item, because CI secret values generally cannot be exported from the old platform and must be re-entered. Ask your team to inventory pipelines, plugins, secrets and forge integrations before estimating anything.

How long does the cut-over take, and what decides it?

Duration depends on scope rather than on a fixed rule, so no general figure applies. The main drivers are the number of repositories, whether the two servers run side by side during cut-over, how many build agents and runtimes (Docker, Kubernetes or local machine) must be configured, and how much testing each critical pipeline needs before its Drone equivalent is switched off. Running both servers in parallel usually lengthens the calendar but lowers risk, because teams can compare build results before retiring Drone. Ask any provider for a written timeline tied to a defined list of pipelines and repositories.

What does our team need to provide for the migration?

Your team needs to supply access and decisions that only your organization holds. These include administrator access to the Drone server and its forge (GitHub, GitLab, Gitea, Forgejo, Bitbucket or Bitbucket Datacenter), a list of repositories and their pipeline files, the secrets each pipeline uses, and ownership of the new OAuth or application registrations on your forge. You also need a host or cluster for the Woodpecker server and agents, a database choice (SQLite by default, with PostgreSQL or MariaDB recommended for larger instances), and named reviewers who can approve pipeline behavior changes. Confirm these inputs with your own platform team before work starts.

Can our own engineers do the move without an outside partner?

Yes, a team with CI, container and forge administration experience can often do the move internally, particularly for a small number of straightforward pipelines. The Woodpecker documentation covers the server, agents, forge setup and workflow syntax, so the work is achievable in-house. The harder parts are validating plugin behavior, rebuilding secrets securely, testing outputs against Drone results and designing a cut-over that does not interrupt releases. If those tasks compete with your current delivery work, an outside implementation partner can take on a fixed scope agreed in writing. DeployOpen plans, implements and documents self-hosted platforms inside your own infrastructure, and a quote follows from that written scope.

Do pipelines and secrets transfer automatically from Drone to Woodpecker?

No, pipeline definitions can be carried over with edits, but secrets generally cannot be exported and must be recreated. Pipeline YAML is a text file in your repository, so it moves with the code once renamed and checked. Secrets are different: CI platforms typically store values that cannot be read back, so the new server needs the values supplied again from your secure source. Forge OAuth applications also need to be created or reconfigured for Woodpecker. Plan a rotation step for any credential that was ever visible to a CI platform, and check whether build history must be exported, since retention in hosted services is limited and history does not move with the code.

Is Woodpecker CI still actively released?

Yes, Woodpecker CI has recent releases. According to the project's GitHub releases, version 3.19.0 was released on October 7, 2026, after 3.18.0 on August 24, 2026 and 3.18.1 in September 2026. The 3.19.0 release fixed an injection of matrix environment variables into the default clone step and enforces agent labels on the server, which is relevant for security review. Before adopting a version, read its release notes, test the upgrade path in a staging environment and set a schedule for applying future releases, because an active project still requires your team to keep the installation current.

How does the license difference affect the decision?

Drone is now managed by Harness under the Polyform Small Business license, while Woodpecker CI is licensed under Apache-2.0, according to the Woodpecker about page and its repository. The Polyform terms limit use by organization size and user count, so an organization must check whether it qualifies before relying on Drone long term. Woodpecker's Apache-2.0 terms do not impose those limits, and its documentation is under CC BY-SA 4.0. Have your legal or procurement team read both license texts against your organization's size, usage and any planned commercial distribution, because license interpretation is a decision for your counsel, not for a migration vendor.

How DeployOpen scopes and runs the Drone to Woodpecker move

DeployOpen plans, implements, integrates, documents and supports self-hosted open-source platforms inside your own infrastructure, so the Drone to Woodpecker move runs in your accounts and networks. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.

How we scope

Inventory every Drone pipeline, its trigger events, secrets and plugin steps before any written scope is agreed
Define which forges, repositories and build agents move to Woodpecker and which stay on Drone during cut-over
Agree in writing how secrets, forge OAuth applications and build history are migrated, exported or retired

How we build

Convert pipeline definitions to .woodpecker.yaml or a .woodpecker directory and test each workflow on a non-production repository
Review every Drone plugin step against the Woodpecker plugin index and adjust settings where behavior differs
Deploy the Woodpecker server and agents on Docker or Kubernetes, with the database choice agreed for your scale

How we hand over

Run Drone and Woodpecker side by side for a cut-over period agreed in the written scope, comparing build results
Document server configuration, agent labels, secret handling, backup steps and the runbook for each repository moved
Hand over the working system with test evidence and a decommissioning checklist for the Drone server

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover
Review Woodpecker releases with your team and plan upgrades in your change process
Confirm with your team which support scope, response expectations and upgrade cadence the retainer should cover

Migrate from Drone CI to Woodpecker CI