Where Drone Enterprise license limits meet the cost of self-hosted Woodpecker CI
A team whose Drone user count is nearing 15, or whose company revenue is climbing toward US$1 million, needs to know what the license does at that point. The license line is only one cost. Self-hosting Woodpecker CI moves recurring spend into infrastructure, operations and people, so the comparison should cover total run cost, not the license fee alone. The Drone Enterprise terms supplied for this page are free use below US$1 million in revenue and up to 15 users per instance. Drone is now managed by Harness under the Polyform Small Business license, so confirm the current terms with Harness, including how users and revenue are counted, before you decide. This section gives no Drone Enterprise price and no Woodpecker support fee.
Woodpecker CI is licensed under Apache-2.0, so its software carries no per-user charge. Its costs are the infrastructure and labor to run it. A server provides the UI and API and receives forge webhooks, agents run workflows and connect to the server over gRPC, and an optional autoscaler creates cloud VMs for pending builds. Each of these is a recurring line item that grows with concurrent builds and pipeline volume. The administration documentation notes that Woodpecker uses SQLite by default and recommends PostgreSQL or MariaDB for larger instances, so a larger install adds a database you must back up, patch and monitor. The Woodpecker about page explains the project's history. Staff time for upgrades, plugin checks and incident response is often the largest recurring item, and no license fee covers it.
Turn the comparison into a written cost model with one line per component: compute for the server and agents, the database, storage for logs and artifacts, network egress, backup and restore tests, and engineering hours for upgrades and on-call. Mark which items are one-time, such as migration, pipeline conversion and re-entering secrets, and which recur. Ask Harness to confirm current Drone Enterprise terms in writing. If you buy implementation or support, ask for the exact scope, response expectations and exclusions in the quote. DeployOpen plans, implements and supports self-hosted platforms inside your own infrastructure under fixed scope agreed in writing, with ongoing support available as a retainer. It does not publish prices, so a quote follows from that written scope.
Cost components on each side and which ones recur
This table compares each cost component on the Drone Enterprise and self-hosted Woodpecker CI sides, including who pays and whether the cost is one-time or recurring. Read the last column first to separate setup work from ongoing spend. The main takeaway is that Woodpecker removes the license line and the per-user limit, but its operating costs move onto your team or a support retainer.
| Cost component | Drone Enterprise | Woodpecker CI | One-time or recurring |
|---|---|---|---|
| License or subscription | Polyform Small Business terms apply: free only below US$1 million revenue and up to 15 users per instance | No license fee. Woodpecker is licensed under Apache-2.0 | Recurring for Drone Enterprise above the free terms. None for Woodpecker |
| Server and database | Your team hosts the Drone server and its database, sized by users and build volume | You run the server for UI, API and webhooks. SQLite by default, PostgreSQL or MariaDB for larger instances | Recurring for hosting. One-time for initial setup |
| Agent capacity | Build agents you run. Check the Enterprise terms for any agent or concurrency limits | Agents run on Docker, Kubernetes or a local machine. An optional autoscaler creates cloud VMs for pending builds | Recurring, because compute is used on every build |
| Implementation | Installation, forge connection and pipeline conversion, done once per instance | Installation, forge OAuth setup, pipeline files and agent configuration, done once per instance | One-time |
| Migration of secrets, pipelines and history | Export pipeline files and record secrets, since stored values may not be readable from the Drone database. Confirm with Harness | Re-enter secrets and forge OAuth applications. Check Drone plugins that may need adjustments before cut-over | One-time, but it runs in parallel with the old server during cut-over |
| Vendor or partner support | Harness supports Enterprise subscribers. Confirm what the subscription includes and its response terms | Woodpecker is a community project with no vendor contract. Support comes from your team or a partner retainer | Recurring if you keep a retainer. One-time if support is a fixed-scope project |
| Upgrades and patching | Harness publishes releases under the subscription, and your team applies them | Your team tracks releases such as 3.19.0 (October 7, 2026), reviews changes and applies them | Recurring, at each release cycle |
| Internal skills | Admins learn Drone configuration, Harness processes and the license terms | Admins need Docker or Kubernetes, Woodpecker YAML and forge administration | Recurring as staff change roles or leave |
What moves the comparison up or down
Drone Enterprise and self-hosted Woodpecker CI put cost in different places, so the answer depends on your headcount, your revenue, your build load and the skills you already have. Each driver below moves the comparison in a direction you can measure in your own environment before you ask for a quote.
Named user count
Drone Enterprise licenses cover up to 15 users per instance, so a team of 15 or fewer people stays within that limit. Woodpecker CI has no user limit, so headcount growth adds no license line. Count who logs in to the server, who edits pipelines and who needs read access only. Then ask Harness how it counts users in your contract, because the definition decides whether a small team is actually inside the limit.
Annual revenue threshold
Drone's free use depends on staying below US$1 million in revenue, so growth can change your licensing position without any change in how you run the software. Read the Polyform Small Business terms to see how revenue is measured and whether affiliates or subsidiaries count. Ask Harness to confirm the threshold and the upgrade path in writing before you plan hiring or acquisitions around it.
Build volume and agent count
Infrastructure cost follows how many builds run in parallel and how long they take, which sets how many agents you need. Woodpecker agents run workflows on Docker, Kubernetes or the local machine, and an optional autoscaler can create cloud VMs for pending builds. Measure peak concurrent pipelines, queue wait time and average job duration over a month. Size agent capacity from those peaks, and use total daily build count only as context.
Database choice for larger instances
Woodpecker uses SQLite by default, and the project recommends PostgreSQL or MariaDB for larger instances. SQLite is simple to run on a single server, but it becomes harder to live with as build history and user activity grow, and changing databases later requires a migration window. Measure how many pipelines you keep, your expected growth and whether your team already operates a database with backups and monitoring. Confirm the sizing with a load test in your own environment.
Availability for server and agents
The server receives forge webhooks and serves the UI and API, so an outage stops new builds from starting even when agents are healthy. Agents connect to the server over gRPC, so a server restart pauses dispatch for every pipeline. Decide how long a stalled pipeline is tolerable for each team. Then cost the redundancy for the database, the server and at least two agents in your own infrastructure, including the on-call effort that comes with it.
In-house Kubernetes and Docker skills
Woodpecker's Kubernetes backend runs each step in a standalone pod and creates a temporary persistent volume claim for the pipeline, ReadWriteMany by default, to share files between steps. Teams without cluster experience either build that skill or pay an implementation partner, while a Docker-only host lowers the skill bar. Inventory who can operate the cluster, storage classes and upgrades, and confirm that your cluster supports ReadWriteMany volumes.
What the Drone license change means for your license decision
Your license decision starts with a change in terms, before any feature comparison. Drone CI was first released under the Apache 2.0 license and later moved to a proprietary license. In 2019 developers forked Drone 0.8 as Woodpecker, renamed on August 27, 2019. Drone is now managed by Harness under the *Polyform Small Business* license. The Woodpecker about page records this history. Woodpecker's code is licensed under Apache-2.0 and its documentation under CC BY-SA 4.0, so the engine you run carries terms that your legal team can read directly in the project repository.
The Polyform Small Business terms are the document to put in front of counsel. Ask counsel to compare the license text with your annual revenue, your legal entity structure, the number of people who will use the server, and how the software is used, including internal builds and any customer-facing services. Do not rely on summaries from third parties. Confirm the current Enterprise thresholds and the metric that counts users with Harness in writing, and ask whether the terms change at renewal or when your usage grows. Record the answers with the date you received them.
Plan the decision around the renewal date. A written answer from Harness and a written legal opinion on your own usage should exist before you sign or expand, and they should name the product version and the scope they cover. Also review the licenses of the parts that Woodpecker pulls in: plugin container images, base images and any Helm chart or agent images you adopt each carry their own terms, and those terms are not covered by the Apache-2.0 license of the Woodpecker code. Build this review into the migration plan so the self-hosted option is judged on the full license stack, not only on the engine.
How to build the cost comparison with your own numbers
This sequence turns the Drone Enterprise license terms and your current usage into a like-for-like annual comparison with self-hosted Woodpecker CI, using quotes you can defend to finance and procurement.
Inventory the current Drone license position
Start with the license document your organization holds for Drone, not a summary. Record which edition and license terms apply, your annual revenue figure as the license defines it, and the number of named users who access the Drone server. Ask Harness in writing to confirm how the Polyform Small Business license and the Enterprise Edition apply to your revenue and user count, and keep that written answer on file. The output is a one-page license position that states the terms, the user count and any date your current agreement ends.
Count repositories, pipelines and build capacity
Export the list of active repositories from your forge and the Drone pipeline history for a period you choose. Record repositories, pipelines per day, builds per day, peak concurrent builds and the agent or machine capacity that serves them today. Note which builds run on Docker, Kubernetes or the local machine, because that decides how many Woodpecker agents you will need. The output is a usage sheet that other steps can reference, so every later cost line traces back to a measured number.
Price the Woodpecker infrastructure
Price each component at your own cloud or data center rates: the Woodpecker server, the database (SQLite is the default, while PostgreSQL or MariaDB are recommended for larger instances), the agents sized from your peak concurrency, and the optional autoscaler that creates cloud VMs for pending builds. Include storage for the temporary volumes that Kubernetes backends create per pipeline, and the network egress for image pulls. Ask your platform team to confirm each unit rate in writing. The output is a monthly infrastructure line with one row per component and the rate source named next to it.
Add one-time migration and implementation effort
Migration covers converting pipeline files to Woodpecker syntax, reviewing Drone plugins that may need adjustments, moving secrets and forge OAuth applications, and running both servers side by side during cut-over. Your internal staff time is one cost, and any external implementation work is another. Request a fixed-scope written proposal from implementation partners, including DeployOpen, that lists scope, deliverables and timelines before work begins. The output is a one-time cost table with internal hours and each written quote as separate rows.
Estimate recurring operations, upgrades and support
List the recurring work your team will carry: patching the server and agents, applying Woodpecker releases, monitoring, backups of the database and configuration, and on-call coverage for failed builds. Decide whether support comes from your own staff, from a community channel, or from a paid retainer, and request written quotes for any retainer. Keep the Harness renewal quote on its own line rather than merging it with the open-source figures, so the comparison shows exactly what each option costs. The output is a recurring cost table with an owner named for each row.
Compare annual totals over a fixed period
Add one-time costs to recurring costs for each option across the same fixed period, usually three years, so that one-time migration costs are spread fairly. Show the Drone and Harness line, the Woodpecker infrastructure line and the operations line side by side, and run a sensitivity check on peak concurrency and user count. Ask finance to review the assumptions before the numbers go to a decision meeting. The output is one comparison table with the source of every input, which you can rerun when the license or your usage changes.
How the infrastructure cost changes by agent backend
This is the simplest model. You run a Woodpecker server and one or more agents on virtual machines or physical hosts that you already operate, and each agent runs workflow steps in containers on the Docker engine. Because the hosts are fixed, your infrastructure cost is mostly the machines themselves, plus the time your team spends patching them and keeping the server database healthy. Woodpecker uses SQLite by default, and the administration documentation recommends PostgreSQL or MariaDB for larger instances, so a database service is a recurring component to plan for.
- Node count: Cost scales with the number of agent hosts you keep running, whether or not they are busy.
- Idle capacity: Fixed hosts sit idle outside peak hours, so utilization is the main lever on cost.
- Storage: Local disks hold container images and workspace data, so image cache size grows with your build history.
- Skills needed: Linux administration, Docker host hardening and basic database operations.
- Scaling limit: Adding capacity means provisioning another host and registering another agent by hand.
Before committing, confirm with your security team how agent hosts are isolated from production networks and where build caches are stored and purged.
With the Kubernetes backend, each workflow step runs in a standalone pod, so your cost follows your cluster rather than a set of dedicated CI machines. Woodpecker creates a temporary persistent volume claim for each pipeline to share files between steps, and that claim is 10G with ReadWriteMany access by default. Cluster nodes are often shared with other workloads, which can lower the marginal cost, but build bursts then compete with production services for CPU, memory and storage.
- Node count: Cluster size depends on peak concurrent steps, not on the number of repositories.
- Storage class: ReadWriteMany volumes depend on your storage backend, and that backend often drives the cost more than compute does.
- Idle capacity: Resource requests that are set high but rarely used reserve nodes that other teams pay for.
- Skills needed: Kubernetes operations, storage provisioning, RBAC and namespace design.
- Recurring work: Clean-up of temporary claims and upgrades of the cluster add ongoing effort.
Confirm with your platform team which storage class provides ReadWriteMany, how network policies restrict pod-to-pod and egress traffic from build pods, and whether build pods can reach internal registries and secrets stores.
The optional Woodpecker autoscaler creates cloud virtual machines for pending builds and removes them when work finishes. This shifts cost from standing hardware to per-use compute in your cloud account, which can suit uneven build demand. The cost is still yours to control, because the cloud provider bills for every VM the autoscaler launches, and a misconfigured limit or a stuck build can keep machines running longer than expected.
- Node count: The autoscaler sets the number of VMs at any moment, so the ceiling you configure is the key cost control.
- Idle capacity: Warm pools or minimum sizes keep machines running even when no builds are queued.
- Storage: Each new VM starts with a fresh disk, so image pull time and cache strategy affect both speed and egress costs.
- Skills needed: Cloud account administration, image building for agent VMs, and monitoring of scaling events.
- Cost visibility: Tag agent VMs by project or team so the bill can be traced back to the builds that caused it.
Confirm with your cloud team which network paths the autoscaled VMs can reach, how their images are patched, and who is allowed to change the scaling limits.
Questions buyers ask before they cost out a move from Drone Enterprise
What drives the cost of running Woodpecker CI in our own environment?
The license fee is zero, so the cost is the infrastructure and the people who run it. Infrastructure includes the server, the agents, the database and, if you use the Kubernetes backend, the cluster capacity and storage for each pipeline. People cost covers upgrades, monitoring, backups and access management. Setup and migration work is one-time. Infrastructure, operations and any support contract recur. Build volume, concurrency, the number of agents, database size and whether the optional autoscaler creates cloud VMs for pending builds all push costs up or down. Ask any vendor or partner to split their quote into one-time and recurring lines and to show the sizing assumptions behind each.
How long does a migration from Drone Enterprise take?
No fixed duration applies to every team, so the answer depends on what you run. The main drivers are the number of repositories and pipelines, how many Drone plugins need adjustment (the Woodpecker docs say Drone plugins generally work but could need some changes), how many secrets must be re-entered because CI secrets usually cannot be exported, how many forge OAuth applications need to be set up again, and whether you run both servers side by side during cut-over. Ask for a timeline in the written scope that lists these items with an acceptance check for each.
What Kubernetes and forge skills does a Woodpecker team need?
You need Kubernetes skills only if you run agents on that backend. Each step runs in its own pod, and the pipeline uses a temporary persistent volume claim that defaults to 10G with ReadWriteMany access, so your cluster's storage class must support that access mode. Your team also needs to keep the server and agents connected over gRPC and manage webhooks and OAuth applications on your forge. Woodpecker supports GitHub, Gitea, Forgejo, GitLab, Bitbucket and Bitbucket Datacenter, and connecting several forges to one server is still experimental, so confirm your forge combination in the forge documentation before you commit.
Can our own team migrate from Drone to Woodpecker without outside help?
A team with container, forge and CI administration experience can often do the work itself, especially for a small instance with Docker-based agents and a short list of pipelines. The harder cases involve many pipelines, Kubernetes-backed agents, multiple forges, strict change control or an audit trail that must show each step. Check whether your team has the time and the skills for pipeline conversion, secrets handling, testing and cut-over at the same time as its normal work. If you want outside help, DeployOpen plans, implements and documents self-hosted platforms in your own infrastructure under a written, fixed scope.
How are Woodpecker upgrades handled across releases like 3.18.0 and 3.19.0?
Plan each upgrade as a tested change. The project's GitHub releases list 3.18.0 on August 24, 2026, 3.18.1 in September 2026 and 3.19.0 on October 7, 2026. Release 3.19.0 fixed an injection of matrix environment variables into the default clone step and enforces agent labels on the server. Before you upgrade, review pipelines that use matrix variables and confirm every agent carries the labels your workflows expect, because the server now enforces them. Test on a staging copy, back up the database, and record the rollback steps. Read the release notes for each version you skip.
What support options exist for a self-hosted Woodpecker server?
Woodpecker is an open-source project under the Apache-2.0 license, so you can rely on the project's own community channels and documentation without a license fee. For a contracted option, DeployOpen offers fixed-scope implementation, hardening, backup, upgrade and documentation work, and ongoing support, upgrades and continuous testing are available as retainers. DeployOpen does not publish a price list. Pricing follows from the written scope, so ask for the support tier, response expectations and exclusions in writing. Confirm with any provider which versions and forge combinations they cover.
What should a quote for moving off Drone Enterprise include?
A useful quote lists what is in scope and what is not. Ask for the repositories, pipelines and forges covered, the agent and backend design, and the sizing assumptions for compute, storage and the database. The quote should also cover secrets re-entry, plugin review, forge OAuth setup, backup and restore testing, cut-over and rollback, handover documentation and training. Ask for a split between one-time and recurring costs, the support tier and its exclusions, the acceptance criteria and who signs off each deliverable. Fixed-scope agreements are agreed in writing before work starts, so a written scope is the basis for comparing quotes.
How DeployOpen scopes a fixed-price Woodpecker CI implementation
DeployOpen plans, implements, hardens and supports self-hosted open-source platforms inside your own infrastructure, so a Drone Enterprise license question becomes a written scope for Woodpecker CI in your cloud account, data center or air-gapped network. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
How we scope
- We inventory existing Drone pipelines, plugins, secrets and forge connections before any installation decision is made.
- The written scope names the forges, runner backends, database choice and number of pipelines covered by the engagement.
- We confirm which Drone features your teams rely on so the scope lists any plugin or syntax adjustments explicitly.
- Ask for the scope to state who owns secret re-entry, OAuth application setup and artifact export.
How we build
- We deploy the Woodpecker server and agents in your infrastructure, with the database option agreed in scope.
- Pipeline files are converted to .woodpecker.yaml or a .woodpecker directory and tested on non-production repositories first.
- Drone plugins flagged as needing adjustment are reviewed and tested against your real pipeline steps before cut-over.
- Hardening, access controls and runner isolation are configured to the agreed scope and documented as they are built.
How we hand over
- Handover includes configuration records, runbooks for the server and agents, and a list of every migrated pipeline.
- We document the side-by-side cut-over plan so both servers can run during the transition period defined in scope.
- Secret rotation steps, backup procedures and artifact retention settings are written for your operators to follow.
- Evidence for your own compliance assessments is collected in the form your assessor requests, without us issuing any attestation.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Upgrades to new Woodpecker releases are tested against your pipelines before they reach production runners.
- Security testing of the CI environment can be scoped separately, covering the server, agents and exposed webhook endpoints.
- Ask for a quote built from the written scope, since DeployOpen does not publish a price list.
