CircleCI vs Woodpecker CI: which to choose

Which CI platform fits a CircleCI renewal or data control review

If your team wants to operate the CI engine and its build agents itself while keeping GitHub, GitLab or Bitbucket as the forge, Woodpecker CI is the self-hosted candidate to test against a CircleCI renewal. CircleCI suits teams that prefer managed compute, hosted credits and a large library of orbs, and nothing in this comparison makes that choice wrong. The decision turns on four conditions: who will operate the Woodpecker server, database and agents; how many concurrent builds the business needs at peak; how many orbs the current config depends on; and how much pipeline rewriting the team can absorb before the next renewal date.

Start with operations. Woodpecker runs as a server that handles the UI, API and forge webhooks, plus agents that execute workflows over gRPC, and an optional autoscaler for cloud VMs. Ask who owns patching, backups of the database (SQLite by default, with PostgreSQL or MariaDB recommended for larger instances) and agent capacity. Then count your concurrency. Replacing credit-based or concurrency-capped hosted plans means your own agents set the ceiling, so size them from measured queue times rather than from the current plan limit. Confirm the current CircleCI plan terms and credit usage with CircleCI before you use them as a baseline.

For a data control review, the question is where pipeline secrets live. Hosted CI stores environment variables for every connected project, and CircleCI's own January 4, 2023 incident report told customers to rotate secrets after exfiltration. Self-hosting moves that trust boundary to your network, but it also makes secret rotation and agent isolation your responsibility. Inventory the orbs in use, because each orb maps to a Woodpecker plugin, a script or a shared container step. If that inventory is short, Woodpecker is a realistic fit. If it is long, budget the rewrite time before committing to a date.

Which option fits which scenario

This table matches common reasons for leaving or staying with CircleCI to the option that fits each one better, and names the condition that decides it. Read each row against your own build volume, network rules, forge and staffing before you choose.

Scenario	Better fit	Condition that drives the choice
Credit overage on high build volume	Woodpecker CI on your own servers or agents	Your build minutes are predictable and you can staff the agent fleet. Compare credit consumption against the compute and storage you would run yourself, and confirm how CircleCI bills your plan.
Builds must run inside a private network	Woodpecker CI, with agents placed in that network	Agents need to reach the forge, registries and deployment targets from inside the network. Confirm that your forge is reachable from the agent subnet before you commit.
Heavy use of CircleCI orbs	Depends on how orbs are used	Orbs bundle tested steps. Woodpecker replaces them with container-image plugins, which may need adjustments. Count the orbs you use and check whether a plugin already covers each one.
Small team with no platform staff	CircleCI, unless you have someone to run Woodpecker	Self-hosting adds server patching, backups, database upkeep and agent scaling. Without an owner for these tasks, the hosted service usually carries less risk.
Forge other than GitHub	Woodpecker CI, if your forge is on its supported list	Woodpecker's forge documentation lists GitHub, GitLab, Gitea, Forgejo, Bitbucket and Bitbucket Datacenter. Multi-forge setups on one server are still experimental, so confirm your exact forge version.
Keeping deployment secrets out of a hosted vendor	Woodpecker CI, with secrets stored in your own infrastructure	CircleCI's January 4, 2023 incident report advised customers to rotate secrets after data was exfiltrated. Secret values cannot be exported from CircleCI, so plan to re-create them in the new system.

How a Woodpecker installation is built and where it runs

A Woodpecker installation is made of a server, one or more agents and, optionally, an autoscaler, and the team that adopts it owns all three. The server provides the web UI and API, receives webhooks from the connected forge (GitHub, GitLab, Gitea, Forgejo, Bitbucket or Bitbucket Datacenter), and parses the pipeline YAML. Agents run the workflows and connect back to the server over gRPC, so agents can sit in a different network segment as long as they can reach the server. The optional autoscaler creates cloud virtual machines for pending builds and removes them afterwards, which matters if your CircleCI usage is bursty. Before you choose a design, confirm which forges your repositories use, because the forge documentation notes that connecting multiple forges to one server is still experimental.

Choose the execution backend early, because it decides where the agents run and what they need. Agents can run workflows on Docker, on Kubernetes or on the local machine. The Docker backend suits a small set of build hosts you already manage. The Kubernetes backend runs each step in its own standalone pod and creates a temporary persistent volume claim for the pipeline, 10G and ReadWriteMany by default, so steps can share files. Your cluster therefore needs a storage class that supports ReadWriteMany, and the default volume size should be checked against your largest build output. Ask your platform team which backend fits your existing clusters before you size anything.

Woodpecker uses SQLite by default, which is convenient for evaluation but is not the choice for a production team. The administration documentation recommends PostgreSQL or MariaDB for larger instances, so plan for a managed or self-operated database with backups, patching and restore tests. Whoever runs the platform must size and operate every part: server capacity, agent pools or autoscaler limits, the database, the shared volume storage, upgrades to new releases (the 3.19.0 release, for example, changed how agent labels are enforced on the server) and monitoring for queued builds. These running costs are the ones CircleCI's billing hides, so record them as recurring staff time and infrastructure when you compare options.

Where build secrets and artifacts live under each model

Moving CI from CircleCI to Woodpecker CI changes who holds deployment secrets, build artifacts and the keys that protect them. The four cards below set out where each piece lives today, what the January 2023 CircleCI incident showed, what a self-hosted Woodpecker server stores, and how identity and audit change. Compliance outcomes under either model are determined by your team and your auditors.

Hosted variables and artifacts on CircleCI

On CircleCI Cloud, environment variables and contexts are stored by the vendor, and CircleCI states that variable values cannot be read in its app after they are set. Build artifacts are kept for a limited window: CircleCI sets 30 days as both the default and the maximum retention. Before any migration, export artifacts and build records while the 30-day window is still open, because they will not be available later. Ask your team which projects depend on artifacts for audit or release evidence.

The January 2023 incident and rotation

In its January 4, 2023 incident report, CircleCI told all customers to rotate secrets after an attacker exfiltrated environment variables, tokens and keys, together with the encryption keys needed to read them. The lesson is that a hosted CI service concentrates deployment credentials for every connected project in one place. Whichever platform you choose, rotate every secret that lived in CircleCI during the move, and do not copy old values into the new system without first confirming they were rotated.

What a self-hosted Woodpecker server holds

A self-hosted Woodpecker installation keeps its server database, which uses SQLite by default and PostgreSQL or MariaDB for larger instances, and the secrets you enter into it. Agents run workflows on Docker, Kubernetes or the local machine and connect to the server over gRPC. Your team chooses where the database sits, how it is encrypted at rest, how backups are taken and who can read them. Confirm these settings with your own platform team and document them, since no vendor holds the keys for you.

Identity, audit and the self-managed option

On Woodpecker, access follows the forge login and the server settings you configure, so audit logs and session controls depend on your identity provider and log pipeline. CircleCI Server 4.10 is an installable self-managed option that runs in your Kubernetes cluster, so it shifts storage and key control to you as well, but it has its own footprint and licensing. Your auditors, not DeployOpen, decide whether either model meets your control requirements. DeployOpen can prepare the systems, configuration and evidence those reviews need.

What each license and edition means for your team

Woodpecker CI is licensed under Apache-2.0, so your team can run, modify and distribute the engine inside its own network without a per-seat or per-build license fee from the project. The documentation is licensed separately under CC BY-SA 4.0, which allows reuse and adaptation with attribution and share-alike terms. These two licenses matter when you write internal runbooks or adapt the project's guides for your own platform team. The license covers the software, not hosting, support or upgrades, which your team or an implementation partner provides.

Code under Apache-2.0: You can build internal forks and patch the server or agents, subject to the license's notice and attribution conditions.
Documentation under CC BY-SA 4.0: Internal guides based on the project docs must credit the source and carry the same license if you publish them.
No license fee for the engine: Costs are the servers, storage, staff time and any support contract you choose to buy.
Project support is community-run: Plan your own patch cadence and escalation path rather than relying on a vendor SLA.
Plugin licenses vary: Each container image plugin carries its own license, so review those separately.

Confirm the license files in the repository and the plugin images you intend to use, and record the version you deploy so audits can trace it.

What drives the cost of each option

CircleCI costs follow its plan, credits and concurrency, or a self-managed contract, while Woodpecker CI costs follow the servers, storage and people you run yourself. Each card marks whether a cost is one-time or recurring and names the driver that moves it, so you can build a like-for-like quote before you compare totals.

CircleCI plan and credit use

CircleCI bills a recurring plan and consumes credits as builds run, so the monthly figure moves with pipeline volume, job size and rerun frequency. Ask the vendor how credits convert to compute for each resource class you use, what the plan includes, and whether overage is billed automatically. Model a typical month and a peak release month separately, because credit use can change sharply between them.

CircleCI concurrency limits

Concurrency caps decide how many jobs run at once, so a team that hits the cap sees queue time rise even when its budget is fine. Ask whether a higher concurrency tier is a recurring line item, and whether it applies to self-hosted runners or only hosted compute. Count peak parallel jobs from your existing pipelines before you agree a plan.

CircleCI self-managed contract

If you choose CircleCI Server, the cost is a recurring contract plus the Kubernetes, database, object storage and Vault footprint that you run. The contract price is not published, so request a written quote that lists license scope, support level, upgrade assistance and any charge per build agent or runner. Confirm whether the vendor treats runner or agent use as a separate metered fee.

Woodpecker servers and agents

Woodpecker has no license fee, so its recurring costs are the server, the agents and the cloud VMs or Kubernetes capacity that run builds. The autoscaler can create VMs for pending builds, which means your bill follows queue depth and idle time. Estimate peak agent count and whether agents stay warm or scale to zero, because that choice drives most of the compute line.

Database and artifact storage

Woodpecker uses SQLite by default and recommends PostgreSQL or MariaDB for larger instances, so a production setup adds a managed or self-run database with its own backups. Build logs, artifacts and caches also grow with history, and you set their retention yourself. Ask your platform team which storage class and backup schedule fit your compliance retention rules, and cost them as recurring.

Upgrades, support and staff time

Upgrades, plugin maintenance and on-call response are the largest recurring costs for most self-run CI, and they fall on your engineers rather than a vendor invoice. The Kubernetes Helm chart and plugin images need regular version checks, and Woodpecker releases such as 3.19.0 can change behavior. Decide who owns the upgrade calendar, and check whether DeployOpen support or an internal rota covers it, using a written scope.

Runner and agent fees

Commercial CI vendors have started charging for self-hosted runners. Atlassian charges $15 per month per concurrent build slot for premium Bitbucket Pipelines runners from runner version 5, and GitHub announced a $0.002 per minute charge for self-hosted GitHub Actions runners before postponing it. Ask CircleCI in writing whether any fee applies to self-managed runners or agents, and confirm the same for any Woodpecker hosting provider, so no runner charge surprises you after the move.

What a move from CircleCI to Woodpecker CI involves

The sequence moves pipelines, plugins, variables, artifacts and secrets from CircleCI to a Woodpecker server and agents beside your existing forge, so builds run in your infrastructure before CircleCI is retired. Each step closes with a check you can verify.

Inventory pipelines, orbs and dependencies
The platform or DevOps team lists every repository that has a .circleci/config.yml, every workflow and job in it, every orb it calls, and every context and project-level environment variable it reads. Record which jobs use custom executors, resource classes, caches and artifacts, and which deploy to production or hold credentials. The output is a spreadsheet or table with one row per pipeline and a column for each dependency, which becomes the migration backlog and the baseline for parallel-run comparisons.
Stand up the Woodpecker server and agents
Deploy the Woodpecker server, which provides the UI and API and receives forge webhooks, plus one or more agents that connect to it over gRPC, inside your own network. Connect the server to the forge that already hosts your repositories, such as GitHub, GitLab, Gitea, Forgejo, Bitbucket or Bitbucket Datacenter, so repositories stay where they are. Confirm the agent backend you need (Docker, Kubernetes or local), and choose a database beyond the default SQLite if the instance will be large. Done means a test repository triggers a pipeline from a push and reports status back to the forge.
Convert config.yml into Woodpecker workflows
Translate each CircleCI workflow into a Woodpecker workflow file, either a single .woodpecker.yaml or several files in a .woodpecker/ directory. Woodpecker runs each file as a parallel workflow, and depends_on controls ordering, so CircleCI workflow sequencing and approval gates need explicit mapping. Each job becomes steps that run inside a specified container image, and when filters replace branch and tag filters. Done means every converted pipeline passes a lint or dry run on the Woodpecker server and each job's commands are traceable to a CircleCI job.
Replace orbs with container-image plugins
Orbs have no direct equivalent, so map each orb call to a Woodpecker plugin, a container image configured through a settings block, or to plain commands in a step image. Look up each candidate in the plugin index and review whether it fits your requirements. Woodpecker's documentation notes that Drone plugins generally work but may need adjustments, so test each plugin with its settings and secrets in a non-production repository. Done means each orb has a documented replacement, and any plugin that needed changes has those changes recorded and reviewed.
Re-create environment variables and secrets
Security and platform leads re-enter every environment variable and secret that CircleCI stored, because CircleCI does not display stored values after they are set. Obtain the values from the systems that issue them, such as cloud accounts, registries and deployment targets, not from CircleCI. Store them in Woodpecker's secret mechanism with scoping that matches the old context and project boundaries. Done means a sample of each secret is validated by a test run, and a register of which pipelines use which secret is kept for the rotation step.
Export artifacts and build history before retention ends
Download any artifacts, test reports and build records that you need to keep through the CircleCI API or interface before the retention window closes. CircleCI sets 30 days as both the default and maximum artifact retention, so anything you need later must be copied out in time. Store exports in your own object storage with an owner and a retention rule set by compliance. Done means each exported item has a checksum, a location and a named owner, and the compliance lead has confirmed which records must be kept.
Run both systems in parallel
Keep CircleCI active while the Woodpecker pipelines run on the same commits, comparing build status, test results, produced artifacts and deployment outputs. Discrepancies usually come from environment differences, cache behaviour, unpinned plugin versions or missing secrets, so record each one with its root cause. Confirm that deployment steps do not run twice, for example by limiting Woodpecker deployment jobs to a dry run until cutover. Done means the pipeline owners sign off that results match for an agreed set of repositories and events.
Rotate secrets and retire CircleCI
Rotate every credential that CircleCI held for connected projects, not only the ones you plan to move, since hosted CI services hold deployment secrets for each connected project. CircleCI's January 4, 2023 incident report told customers to rotate secrets after an attacker exfiltrated environment variables, tokens and keys, so treat rotation as a required part of the exit. Then disable CircleCI project triggers, remove forge webhooks and deploy keys that point to it, and close the account or organization once the export and sign-off are complete. Done means a rotation log exists, no CircleCI webhook or token remains on the forge, and the decommission is recorded in your change system.

Questions buyers ask before switching from CircleCI

How much effort does a migration from CircleCI to Woodpecker CI take?

The effort depends mostly on how many pipelines you have, how many orbs they call, and how many environment variables and contexts hold deployment secrets. Each pipeline needs its config.yml rewritten as one or more Woodpecker workflow files, with each step running in a container image. Orbs have to be replaced with Woodpecker plugins, or with plain commands in a container step, and each secret has to be re-entered because CircleCI does not display stored values. Ask any implementation partner for a written scope that lists pipelines by complexity, orb inventory and secret count before agreeing a timeline.

Can our team migrate from CircleCI without outside help?

Yes, a team with container and YAML experience can do it in-house, provided someone owns the inventory and the cutover. Woodpecker workflows are YAML files that run in container images, so engineers who already know their pipelines can port them. The harder parts are the orb replacements, secret re-creation and the operational setup of the server and agents. Many organizations split the work: internal engineers port low-risk pipelines, while an outside team handles the hardening, backups and the more complex deploy stages. Confirm the internal skills you have before deciding.

What does the migration ask from our internal staff?

Your staff need to supply knowledge that no tool can export. Application owners must explain what each pipeline builds, tests and deploys, and which environment variables and tokens it uses. Platform engineers must provide the infrastructure for the Woodpecker server, a database (SQLite by default, with PostgreSQL or MariaDB recommended for larger instances), and agents on Docker, Kubernetes or a local machine. Security staff should own the secret rotation plan, since hosted CI keeps deployment credentials for every connected project. Plan time for these reviewers, not only for the engineers who write the YAML.

How long should we run CircleCI and Woodpecker CI in parallel?

Run both systems side by side until each migrated pipeline has produced the same results over enough real builds to trust, including at least one release cycle for deploy pipelines. The exact length is set by your release cadence and risk appetite, not by a fixed number, so agree it in writing before cutover. During the overlap, keep CircleCI active for rollback and export its artifacts before the 30-day retention window closes, since CircleCI sets 30 days as both the default and maximum. Ask any partner to state the parallel-run exit criteria in the scope document.

Can Woodpecker CI connect to our current Git forge?

Yes, if your repositories live on one of the supported forges. Woodpecker's forge documentation lists GitHub, Gitea, Forgejo, GitLab, Bitbucket and Bitbucket Datacenter, with push, tag and pull request events on all of them. This means you can move builds in-house without moving your repositories. Connecting multiple forges to one server is still experimental, so if you run more than one, confirm how that affects your design. Check the current forge documentation for your exact version before committing.

What recurring operations does a self-hosted Woodpecker CI deployment need?

Recurring work falls into four areas: upgrades, backups, agent capacity and access control. Woodpecker releases new versions, such as 3.19.0 released on October 7, 2026, and each upgrade should be tested against your pipelines before rollout. You will back up the server database and keep agent hosts patched. Capacity depends on how many builds run at once, and the optional autoscaler can create cloud VMs for pending builds. Access to the server, secrets and agents must be reviewed on a schedule. A support retainer can cover some or all of this work, and its scope should be written down before it starts.

What happens to our Orbs and secrets during the switch?

Orbs do not carry over, so each one needs a replacement, usually a Woodpecker plugin from the plugin index or a container step with the same commands. Secrets do not carry over either, because CircleCI states that environment variable values are not readable in its app once set. Export a list of variable names, then have owners re-enter the values in Woodpecker and rotate each credential as part of the cutover, since CircleCI told customers to rotate secrets after its January 4, 2023 incident. Ask for a secret inventory in the written scope.

What changes for your developers after the switch

Most of the daily change is in how pipelines are written and read. In CircleCI, a job runs on a machine, Docker or macOS executor, and steps are configured in .circleci/config.yml. In Woodpecker CI, every step runs its commands inside a container image you name, so a developer picks the image that holds the tools and writes plain YAML under .woodpecker.yaml or a .woodpecker/ directory. Filters on event, branch and path decide when a step runs, and matrix builds replace the parameterized job patterns many CircleCI teams use. Developers should expect to rewrite these blocks by hand, not translate them automatically, and the review should check that each when filter still matches the branch and tag rules the release process depends on.

Logs and failed builds are reviewed differently. Developers used to CircleCI's web app will find Woodpecker's UI and API covering the same pipeline view, but the failing step now points to a container, so the first question is often whether the image, the environment or the command is at fault. Teams should agree on a short failure triage routine, document which image tags are pinned, and decide who maintains the shared base images. Habits such as branch-based pipeline triggers, pull request checks and reading test output carry over. Retraining is needed for container-image thinking, workflow dependencies and for reproducing a failure locally with the same image.

The team needs someone who can debug agents and images, not only write YAML. When a build stalls, the cause may sit in the Woodpecker server, a gRPC connection to an agent, the Docker or Kubernetes backend, or a plugin image that behaves differently from its CircleCI orb. Assign at least one platform owner with access to agent logs, image registries and the server database, and confirm before cutover that this person can restart agents, rotate tokens and roll back a bad image. Ask your implementation partner to include a debugging walkthrough in the handover, and confirm with the Woodpecker documentation which backend and version your environment will run.

How DeployOpen helps evaluate and move off CircleCI

DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure. For CircleCI vs Woodpecker CI, we start with a written scope that tests whether Woodpecker CI fits your forge, your pipelines and your network before any migration work begins.

How we scope

Inventory which repositories, forges and pipelines currently run on CircleCI and which depend on orbs or contexts
Confirm the forge connection each Woodpecker CI server would use, such as GitHub, GitLab, Gitea, Forgejo or Bitbucket
Agree in writing which pipelines move, which stay, and how the parallel-run period is defined
Record the secret inventory, artifact retention needs and the environments where builds must run

How we build

Stand up a Woodpecker CI server with agents on Docker or Kubernetes inside your cloud account or data center
Rewrite representative pipelines as container-step workflows and map orbs to Woodpecker plugins or scripted steps
Configure database, backups, access control and agent labels to match your internal security baseline
Run security testing against the pipeline and runner setup before cutover, as agreed in the scope

How we hand over

Deliver documented pipeline files, runner configuration, and a list of plugin gaps with agreed workarounds
Provide a rotation plan for every secret re-entered into Woodpecker, since CircleCI will not reveal stored values
Document the artifact export steps and the evidence your team needs to keep for internal or external reviews
Train your engineers on operating agents, upgrades and troubleshooting before the engagement closes

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover
Track Woodpecker CI releases and schedule upgrades against your agreed change process
Ask any prospective partner to confirm which items are included in the fixed scope and which fall under a retainer
Request a written quote that follows from the agreed scope, since DeployOpen does not publish a price list

CircleCI vs Woodpecker CI

Which CI platform fits a CircleCI renewal or data control review

Which option fits which scenario

How a Woodpecker installation is built and where it runs

Where build secrets and artifacts live under each model

Hosted variables and artifacts on CircleCI

The January 2023 incident and rotation

What a self-hosted Woodpecker server holds

Identity, audit and the self-managed option

What each license and edition means for your team

What drives the cost of each option

CircleCI plan and credit use

CircleCI concurrency limits

CircleCI self-managed contract

Woodpecker servers and agents

Database and artifact storage

Upgrades, support and staff time

Runner and agent fees

What a move from CircleCI to Woodpecker CI involves

Inventory pipelines, orbs and dependencies

Stand up the Woodpecker server and agents

Convert config.yml into Woodpecker workflows

Replace orbs with container-image plugins

Re-create environment variables and secrets

Export artifacts and build history before retention ends

Run both systems in parallel

Rotate secrets and retire CircleCI