Jenkins vs Woodpecker CI: when each one is the right choice
Choose Jenkins when your pipelines depend on a broad set of plugins, when you already maintain a large estate of Jenkinsfiles, or when your delivery process reaches into tools that only Jenkins integrates with well. Jenkins is distributed under the MIT License, and its community has contributed more than 2,300 plugins, so the chance that a niche tool already has an integration is high. The cost is operating a Java controller, its plugin set and its update rhythm. Jenkins picks a new LTS baseline every 12 weeks and ships three LTS releases per baseline, and the LTS 2.580.1 release stopped bundling several plugins, including the SSH server and JUnit plugins. If you adopt Jenkins, plan a regular plugin review and confirm which bundled plugins your jobs need before each upgrade.
Choose Woodpecker CI when your code lives on a supported forge, when every build step can run in a container image you control, and when you want pipelines expressed as YAML in the repository rather than as a plugin-driven controller. Woodpecker is Apache-2.0 licensed, supports GitHub, Gitea, Forgejo, GitLab, Bitbucket and Bitbucket Datacenter, and runs workflows on Docker, Kubernetes or the local machine. Its Kubernetes backend runs each step in a standalone pod and creates a temporary persistent volume claim for files shared between steps. The trade-off is a smaller plugin ecosystem: Drone plugins generally work but may need adjustments, and connecting several forges to one server is still experimental. Before committing, confirm that your forge and every required step have a container-based equivalent, and test a representative pipeline on the version you plan to run, such as the 3.19.0 release.
Which platform fits which scenario
This table maps common team situations to the platform that usually fits better, with the specific reason and the condition that would reverse the choice. Read each row against your own pipeline inventory, forge and cluster setup, because the better fit depends on what you already run.
| Scenario | Better fit | Why and what would reverse it |
|---|---|---|
| Large existing Jenkinsfile estate | Jenkins | Jenkinsfiles already encode stages, shared libraries and credentials flows, so moving them costs rewriting work. Woodpecker YAML does not read Jenkinsfiles. Reverse it if most of the estate is simple build-and-test scripts that a container step per job can replace cheaply. |
| Git forge already on Forgejo or Gitea | Woodpecker CI | Woodpecker lists Forgejo and Gitea among its supported forges, with push, tag and pull request events. Forgejo Actions is also available, but it is a separate system from Woodpecker. Reverse it if you need Jenkins-only features such as a broad set of established plugins that Woodpecker does not offer. |
| Kubernetes-first team building with container images | Woodpecker CI | Each workflow step runs in a specified container image, and the Kubernetes backend runs each step in its own pod. This matches a container-first habit. Reverse it if your builds depend on long-lived agent state or on tooling that only runs on Jenkins agents. |
| Team with many niche plugins | Jenkins | Jenkins documents more than 2,300 community plugins for integrating with tools across the toolchain. Woodpecker plugins are container images, and its docs say Drone plugins generally work but may need adjustment. Reverse it if the plugins you need already exist as container images in the Woodpecker plugin index. |
| Small team wanting a light server | Woodpecker CI | Woodpecker uses SQLite by default and runs agents that connect over gRPC, so a pilot can start small. Jenkins needs a controller plus agent planning and a plugin lifecycle. Reverse it if you expect to grow quickly, since the docs recommend PostgreSQL or MariaDB for larger instances. |
| Strict plugin version governance and vendor-backed release cadence | Jenkins | Jenkins ships LTS baselines on a 12-week cycle with three LTS releases per baseline, and publishes a Java support policy. Reverse it if your organization can run Woodpecker's current release line and track its patch releases, such as 3.19.0 released on October 7, 2026. |
| Multi-forge or mixed forge estate | Jenkins | Jenkins integrates with many source control systems through plugins under one controller. Woodpecker's documentation says connecting multiple forges to one server is still experimental. Reverse it if you can standardize on one forge per Woodpecker server. |
| Need for built-in Configuration as Code | Jenkins | The Configuration as Code plugin reads YAML from CASC_JENKINS_CONFIG, but it does not install plugins, so plugin setup needs images or the Helm chart. Reverse it if your main goal is declarative pipeline files in the repository, where Woodpecker's YAML workflows fit without a separate controller configuration step. |
How Jenkins and Woodpecker are built and what that means for operations
Jenkins and Woodpecker both split work between a central server and separate workers, but the state they keep, the way workers connect and the runtime they bring differ in ways that change what you back up, patch and watch. The cards below follow those differences from the Jenkins controller and its agents through to the JVM footprint of the container-native model.
Jenkins controller and build agents
The Jenkins scaling guide recommends dedicated build agents so the controller only handles HTTP requests and manages the build environment. Keeping compilers, test runs and Docker builds off the controller protects its responsiveness as job volume grows. Growth beyond one controller is handled by adding controllers per team or project, not by enlarging a single one. Check whether your agents are long-lived machines or ephemeral workers, because that decision sets your patching and capacity routine.
Primary and backup controller pattern
The scaling guide describes a primary and backup controller arrangement in which a proxy such as HAProxy or F5 routes traffic to the backup if the primary fails. This is a failover pattern you build and test yourself, so confirm who owns the proxy, how the backup receives current configuration, and how long your teams can tolerate a pipeline outage. Plan a failover test as part of the initial rollout, not after the first incident.
Woodpecker server, agents and autoscaler
A Woodpecker installation has a server that provides the UI and API, receives forge webhooks and parses pipeline YAML. Agents run workflows and connect to the server over gRPC, and an optional autoscaler creates cloud VMs for pending builds. Because agents initiate the gRPC connection to the server, confirm that your network rules permit that path from every build location. Verify the agent label enforcement behavior in the release you deploy, since version 3.19.0 enforces agent labels on the server.
JENKINS_HOME versus Woodpecker database state
Jenkins keeps all configuration, plugins and secrets in $JENKINS_HOME on the controller, so that directory is your primary backup target. Woodpecker uses SQLite by default, and the documentation recommends PostgreSQL or MariaDB for larger instances. Moving Woodpecker off SQLite is a planning item, not a later tuning step, and it changes your backup, restore and database patching duties. Ask your team to name the owner of each state store before go-live.
JVM footprint versus container-native model
Jenkins runs on the Java Virtual Machine, and its Java support policy lists Java 21 and Java 25 as supported, with Java 17 ending with LTS 2.541.3. Your Java runtime and Jenkins core therefore move on separate clocks that you must track. Woodpecker runs each workflow step inside a container image, so the runtime moves into images you version and scan. Both models shift patching work: Jenkins to the JVM and plugin set, Woodpecker to base images and the Docker or Kubernetes backend.
Side-by-side capability comparison
This table compares Jenkins and Woodpecker CI on license, extension model, forge support, pipeline definition, Kubernetes execution, configuration as code, release cadence and Java requirements. Read each row against your own forge, pipeline inventory and plugin list, because the right answer usually depends on which of those you already run.
| Capability | Jenkins | Woodpecker CI |
|---|---|---|
| License | MIT License, per the LICENSE.txt file in the jenkinsci/jenkins repository | Apache-2.0 for code, with documentation under CC BY-SA 4.0 |
| Extension model | More than 2,300 community-contributed plugins, per the Jenkins homepage; confirm each required plugin is maintained for your controller version | Container images used as pipeline steps, configured through a settings block; Drone plugins generally work but may need adjustments |
| Forge support | Integrates with many source control and tooling systems through plugins; confirm the exact forge plugins you need | GitHub, Gitea, Forgejo, GitLab, Bitbucket and Bitbucket Datacenter with push, tag and pull request events; connecting multiple forges to one server is experimental |
| Workflow definition | Jenkinsfile in Declarative or Scripted syntax made of stages and steps, committed to source control | YAML in a single .woodpecker.yaml or several files in a .woodpecker/ directory, with depends_on ordering |
| Execution model | Controller with build agents; agents can be static machines or created per build with the Kubernetes plugin | Server with agents running workflows on Docker, Kubernetes or the local machine; each workflow step runs in a specified container image |
| Kubernetes execution | Supported through the Kubernetes plugin; confirm pod template and storage design with your platform team | Each step runs in a standalone pod with a temporary persistent volume claim (10G and ReadWriteMany by default) shared between steps |
| Configuration as code | Configuration as Code plugin reads YAML from CASC_JENKINS_CONFIG (default $JENKINS_HOME/jenkins.yaml) but does not install plugins | Server and agent settings are files and environment variables; confirm the settings your version supports |
| Release cadence | New LTS baseline every 12 weeks with three LTS releases per baseline in four-week cycles; LTS 2.580.1 released September 30, 2026 | Versioned releases; 3.19.0 released October 7, 2026, after 3.18.0 on August 24, 2026 |
| Runtime requirements | Java 21 (planned end of support September 2027) and Java 25 (planned end of support September 2029) are supported; 2.541.3 is the final LTS for Java 17 | Go-based server and agents with SQLite by default; PostgreSQL or MariaDB recommended for larger instances |
Licensing and what is paid for each platform
Jenkins is distributed under the MIT License, a permissive license that allows you to run, modify and redistribute the controller without a license fee. The license file credits Kohsuke Kawaguchi, Sun Microsystems and other contributors, and it is the controller license only in the sense that each plugin carries its own terms. Release planning is where most operational work sits. Jenkins picks a new LTS baseline every 12 weeks from a recent weekly release, then ships three LTS releases for that baseline in four-week cycles that contain only backported fixes. The latest LTS releases in this comparison are 2.568.3 on September 2, 2026 and 2.580.1 on September 30, 2026.
- License scope: MIT covers the controller. Check the license of every plugin you depend on, because plugin terms are set by their authors.
- LTS cadence: A new baseline every 12 weeks, three LTS releases per baseline, and backported fixes only inside each baseline.
- Java support: Java 21 has a planned end of support in September 2027, and Java 25 (first LTS 2.541.1 in January 2026) has a planned end of support in September 2029. The final LTS release for Java 17 was 2.541.3 in March 2026.
- Plugin bundling change in 2.580.1: Several plugins are no longer bundled, including the bouncycastle API, SSH server and JUnit plugins. Install them through the plugin manager before you upgrade, or pipelines that depend on them will break.
- Plugin catalog: The Jenkins homepage describes more than 2,300 community-contributed plugins. Each one adds upkeep, so the catalog is an advantage only if you have a plan for patching them.
Before you move to 2.580.1 or later, list the bundled plugins that your Jenkinsfiles and agents use and confirm they are installed explicitly.
Woodpecker CI is licensed under Apache-2.0, and its documentation is published under CC BY-SA 4.0. The project was forked from Drone 0.8 in 2019 after the Drone license moved from Apache 2.0 to a proprietary license, and it was renamed Woodpecker on August 27, 2019. The project's README notes that Woodpecker is the main CI/CD engine at Codeberg. The current release history in this comparison runs from 3.18.0 on August 24, 2026, through 3.18.1 in September 2026, to 3.19.0 on October 7, 2026.
- License inventory: Apache-2.0 covers the server and agent code, and CC BY-SA 4.0 covers the documentation. Record both in your compliance inventory.
- Release line: 3.18.0 (August 24, 2026), 3.18.1 (September 2026) and 3.19.0 (October 7, 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, so plan it as a security-relevant upgrade.
- Release track: This comparison does not show an LTS track for Woodpecker. Confirm with the project which releases receive fixes and for how long before you pin a version.
- Paid edition: No paid edition of Woodpecker appears in this comparison. Ask the project and any commercial provider directly and get the answer in writing.
- Plugin licensing: Plugins are container images listed in the plugin index, so each one has its own license and maintainer. Drone plugins generally work but may need adjustments.
Before you standardize on a Woodpecker release, confirm the support window for the version you choose and test each new release against your pipelines.
Neither license includes a support contract, so paid help comes from a named vendor, a consultant or your own staff. DeployOpen is not an official partner or reseller of Jenkins or Woodpecker CI. It plans, implements, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Ongoing support, upgrades and continuous testing are available as retainers. DeployOpen does not publish a price list, and a quote follows from the written scope.
- Named provider: Ask whether the provider is a named vendor, an independent consultant or an internal team, and what the contract covers, including response times in writing.
- Implementation scope: A fixed-scope agreement can cover installation, pipeline migration, plugin pinning, backup of
$JENKINS_HOMEor Woodpecker storage, and documentation. Each item should appear in the signed scope. - Upgrade ownership: Decide who tests each Jenkins LTS baseline or Woodpecker release, who handles plugin changes and who owns rollback.
- Quote inputs: Controllers, agents, pipelines, plugins, forges and any compliance evidence you need will drive the quote. Give the provider the full list before comparing offers.
- Retainer terms: Ask what a retainer includes, how urgent issues are handled and how upgrade windows are scheduled.
Before you buy from any provider, ask for the support window, the named people who will respond and the process for a plugin or release that breaks a pipeline.
What drives the running cost of Jenkins and Woodpecker
The running cost of Jenkins sits mostly in the controller, the plugins and the people who keep them working. Both platforms are free to download under permissive licenses, so the recurring spend is compute, storage, staff time and upgrade work. For Jenkins, the controller holds all configuration, plugins and secrets in $JENKINS_HOME, and the scaling guide recommends dedicated build agents so the controller only handles HTTP requests and manages the build environment. Compute for the controller and agents is therefore a separate line item from the database and backups. Plugin maintenance is the largest hidden cost. With more than 2,300 community plugins available, each one you install needs version tracking, testing against each LTS baseline and a replacement plan when it lags. The Jenkins LTS 2.580.1 release stopped bundling several plugins, so that testing work now lands on your team even for a routine upgrade.
For Woodpecker, the recurring cost shifts toward the Kubernetes backend and workflow images. Each step runs in its own container image, and the Kubernetes backend creates a temporary persistent volume claim for each pipeline, 10G and ReadWriteMany by default, so storage class choice and claim cleanup affect the bill directly. Plugins are container images, so every image you pin needs rebuilding and scanning when its base image changes. Woodpecker 3.19.0 is the current release from the project's GitHub releases, and the team should confirm its own patch cadence against that release line. Ask the platform owner which database will hold the server state (SQLite by default, with PostgreSQL or MariaDB recommended for larger instances) and who backs it up.
One-time costs for either platform include migration of Jenkinsfiles into .woodpecker.yaml or .woodpecker/ workflows, rewriting pipelines that depend on Jenkins-only steps, and replacing plugins with container steps. Recurring costs include patching, LTS or stable upgrades, agent capacity and the skills needed to debug either system. When requesting a written quote from DeployOpen, ask for the scope split between one-time and recurring work, the plugin or image inventory included, the upgrade cadence assumed for each platform, the Kubernetes storage and database assumptions, the staff skills the scope relies on, and which items are fixed-scope and which are retainer-based. Ask to see how each assumption changes the total.
Moving from Jenkinsfiles to Woodpecker workflows
This sequence turns a Jenkins estate into Woodpecker workflows without a single cutover day, so each pipeline is proven in parallel before its webhook moves. Your team ends with an inventory, a plugin-to-image map, running agents and a repository-by-repository cutover record.
Inventory jobs, libraries and plugins
List every Jenkins job, Jenkinsfile, shared library and installed plugin, and note which repository each one builds. Record the controller's plugin list and the contents of $JENKINS_HOME that define configuration, credentials and job history, since the scaling guide places all of that on the controller. Your team owns this inventory, and a DeployOpen engineer can review it against the scope you agree in writing. The step is done when every pipeline has an owner, a repository and a list of external dependencies.
Map plugin dependencies to container steps
For each plugin a pipeline depends on, decide whether Woodpecker can cover the need with a container image that runs the command directly, an existing plugin from the Woodpecker plugin index, or a replacement tool your team builds. Plugins that change how Jenkins itself behaves, such as credential bindings or UI-driven approvals, need a separate design rather than a one-to-one swap. Confirm each Drone-derived plugin in a test run, since the Woodpecker documentation says those plugins generally work but may need adjustments. The output is a mapping sheet with one row per dependency and a named image or design for each.
Convert stages into Woodpecker workflows
Rewrite each Declarative pipeline as a
.woodpecker.yamlfile or a set of files in a.woodpecker/directory, where each workflow runs in parallel unless you order it with depends_on. Turn each Jenkins stage into a workflow or step, specify the container image for every step, and add when filters for event, branch and path so triggers match the old job rules. Scripted pipelines usually need more manual translation because their logic is code rather than declared stages. Check the result by running the converted pipeline against a test branch and comparing its stage outcomes and artifacts with the last successful Jenkins build.Set up agents and the Kubernetes backend
Install the Woodpecker server with a database chosen for your scale, since the administration documentation sets SQLite as the default and recommends PostgreSQL or MariaDB for larger instances. Deploy agents on Docker, Kubernetes or the local machine, and connect them to the server over gRPC. If you use the Kubernetes backend, confirm the namespace, service account and the temporary persistent volume claim that holds files shared between steps, which defaults to 10G and ReadWriteMany. Your platform team owns this work, and it is complete when a test pipeline runs on each agent type and the server shows the agents as connected.
Run both systems in parallel
Keep Jenkins running and point the converted Woodpecker pipelines at the same commits without letting them publish, deploy or write status to the forge. Compare build results, test counts, artifact checksums and run times for each repository over a period your team sets, and log every mismatch with its root cause. Credentials are re-entered in Woodpecker rather than copied, so limit the parallel run to pipelines that need only non-sensitive inputs until those secrets are in place. The step is done when each converted pipeline has matched Jenkins on agreed checks, or its gaps have an accepted fix.
Cut over webhooks one repository at a time
Switch each repository's forge webhook from Jenkins to Woodpecker, starting with low-risk repositories and keeping the Jenkins job disabled but present for rollback. Woodpecker supports GitHub, Gitea, Forgejo, GitLab, Bitbucket and Bitbucket Datacenter with push, tag and pull request events, but connecting several forges to one server is still experimental, so confirm your forge setup first. Verify that a test push and a pull request trigger the expected workflows, then record the cutover date and owner. The step is done when every repository reports its builds from Woodpecker and the Jenkins job for it has been archived or removed.
Where implementation projects usually run long
The longest part of a Jenkins engagement is usually the plugin inventory, not the controller build. Before scoping, list every plugin the existing Jenkinsfiles and jobs call, then map each one to a maintained replacement or an in-house step. Confirm which plugins your Jenkins LTS line still bundles: the 2.580.1 changelog says several, including the bouncycastle API, SSH server and JUnit plugins, must now be installed through the plugin manager, so any job that assumed them will fail until someone adds them. Plan controller hardening (access control, credential scope, agent-to-controller security) as a separate workstream, and plan $JENKINS_HOME backup before cutover, since all configuration, plugins and secrets live there. If you adopt Configuration as Code, remember that the plugin itself does not install plugins, so the plugin list must be managed in your image or Helm values as well as in jenkins.yaml.
On the Woodpecker side, the work concentrates in four places. First, forge webhook setup: confirm the forge type (GitHub, Gitea, Forgejo, GitLab, Bitbucket or Bitbucket Datacenter) and that push, tag and pull request events reach the server, because a missed webhook looks like a silent pipeline failure. Second, agent registration and labels: agents connect to the server over gRPC, and the 3.19.0 release enforces agent labels on the server, so label schemes must match what workflows request before cutover. Third, on Kubernetes, each step runs in its own pod and a temporary persistent volume claim (10G and ReadWriteMany by default) shares files between steps. Confirm your storage class supports ReadWriteMany and size the claim for your largest workspace. Fourth, plugin adjustments: Drone plugins generally work but may need changes, so test every container step rather than assuming parity.
Secrets handling and unmapped tooling cause the most schedule slips on both sides. Inventory where credentials are stored, which jobs read them and how they are scoped, then decide how each maps to the target system's secret store. Ask whoever scopes the work to confirm the number of Jenkinsfiles, shared libraries, plugins and forge integrations in use, the expected build concurrency, and which environments (cloud, data center or air-gapped) the runners must reach. Those answers, not the tool choice alone, determine how much of the effort is migration and how much is new platform build-out.
Common questions before choosing or migrating
How much effort does migrating a Jenkinsfile to Woodpecker take?
The effort depends on how much of the Jenkinsfile is plain build logic and how much depends on Jenkins plugins. A pipeline that runs shell commands inside a container image maps fairly directly, because Woodpecker workflows are YAML files where each step runs its commands in a specified container image. Declarative stages translate into workflows and steps, and depends_on handles ordering between them. Effort rises with shared libraries, Scripted Pipeline logic, credentials bindings, and plugin-driven steps that have no direct equivalent. Ask for an inventory of every Jenkinsfile, shared library and plugin the pipelines call before agreeing on scope, since that inventory is what a fixed-scope quote is built from.
Can Woodpecker replace specific Jenkins plugins?
Sometimes, but not one for one. Woodpecker plugins are container images configured through a settings block as pipeline steps, and they are listed in the plugin index. The Woodpecker documentation says Drone plugins generally work but could need some adjustments. A Jenkins plugin that wraps a tool in a container can often be replaced by a step that runs that tool's image directly. A plugin that changes Jenkins itself, such as UI features, authentication or controller-side behavior, has no step equivalent and needs a different answer. Build a table that maps each plugin your pipelines use to a Woodpecker step, a plugin image, or a decision to drop it, and confirm each mapping with a test run.
What does the Jenkins LTS cadence mean for upgrades?
Jenkins picks a new LTS baseline every 12 weeks from a recent weekly release, then ships three LTS releases for that baseline in four-week cycles that contain only backported fixes. The practical effect is a predictable upgrade rhythm, but the controller still needs planned work on each cycle, including plugin updates. The LTS changelog for 2.580.1, released on September 30, 2026, shows a concrete example: several plugins, including the bouncycastle API, SSH server and JUnit plugins, stopped being bundled and must now be installed through the plugin manager. Also check the Java support policy, since Java 21 has a planned end of support in September 2027. Budget the recurring upgrade effort, not only the initial build.
Does Woodpecker need PostgreSQL in production?
Woodpecker uses SQLite by default, and the administration documentation recommends PostgreSQL or MariaDB for larger instances. So PostgreSQL is not strictly required for a small team, but it is the expected choice once usage grows or when you need a database your backup and high availability tooling already covers. Choosing it adds a database to run, back up and patch. Confirm the expected pipeline volume, the number of repositories and whether your organization already operates PostgreSQL before deciding. If you plan to deploy on Kubernetes, the Helm chart documentation describes the installation options to review first.
What work must our team provide during a migration?
Your team supplies the knowledge that the code cannot show. That includes who owns each pipeline, which credentials and secrets the jobs use, which forge events trigger them, which agents or machines they need, and which compliance evidence the build records must keep. Your team also needs to approve test runs and cutover windows. DeployOpen plans, implements, integrates and documents self-hosted platforms inside your infrastructure, and most engagements are fixed-scope with deliverables agreed in writing before work starts. Ask any provider to list these client responsibilities in the written scope so that delays caused by missing access or decisions are visible to both sides.
Can our own engineers do the migration without outside help?
Yes, a capable platform team can migrate a small set of pipelines without outside help, and a simple, well-tested Jenkinsfile set is a reasonable place to start. The risk grows with the number of shared libraries, plugin dependencies and compliance-sensitive pipelines. Before deciding, count the pipelines, check how many depend on plugins, and confirm who will own Woodpecker after cutover, including upgrades and backups of its server and agent setup. If the team lacks container and YAML pipeline experience, a fixed-scope engagement can cover the mapping and testing while your staff keep ownership. Either way, run both systems in parallel until each pipeline has passed its test runs.
Which Git forges does Woodpecker support today?
The forge documentation for version 3.19.x lists GitHub, Gitea, Forgejo, GitLab, Bitbucket and Bitbucket Datacenter, with push, tag and pull request events on all of them. Connecting multiple forges to one Woodpecker server is still experimental, so a single server should be planned around one forge where possible. If your repositories sit on a forge outside that list, or you need several forges on one server, treat that as a scope item to confirm with the Woodpecker project before committing. Check the forge documentation for the exact version you plan to run, because forge support changes between releases.
How DeployOpen helps choose, implement or migrate CI
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure. For Jenkins vs Woodpecker CI, we start from your existing pipelines, forge and build estate, then agree a written scope before any work begins.
How we scope
- Inventory existing Jenkinsfiles, shared libraries, plugins and build agents before comparing against Woodpecker workflows
- Map forge integrations, such as GitHub, GitLab, Forgejo or Gitea, to the events your pipelines depend on
- Agree scope, deliverables and timelines in writing; most engagements are fixed-scope
- Define which pipelines move, which stay on Jenkins and what must be validated for each
How we build
- Deploy the chosen CI engine in your cloud accounts, data centers or air-gapped networks
- Configure agents on Docker, Kubernetes or local machines to match your isolation and tooling needs
- Replace plugin-dependent steps with container steps or plugin images, and test each replacement
- Set up secrets handling, database backends and backup of server configuration as part of the build
How we hand over
- Document the pipeline layout, agent setup, upgrade path and rollback steps for your own team
- Provide a side-by-side record of Jenkinsfile logic and the equivalent Woodpecker YAML for review
- Walk your engineers through running, debugging and extending pipelines before handover closes
- Deliver evidence of configuration and access controls that your auditors or assessors can review
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after handover
- Track upstream Jenkins LTS and Woodpecker release changes and plan upgrades against them in writing
- Re-test pipelines and agent images after upgrades, plugin changes or forge migrations
- Confirm retainer scope, response expectations and exclusions with your team before signing
