Forgejo Actions vs Woodpecker CI

Which CI fits which Forgejo scenario

This table maps six common Forgejo scenarios to the CI option that usually fits better and the condition that drives the choice. Read each row against your own constraints, since the conditions matter more than the default pick. The main takeaway is that Forgejo Actions suits teams that want one fewer server, while Woodpecker suits teams that need its Kubernetes backend, Drone-style pipelines or a separate agent layout.

How each CI system is built, and what that means for operations

Forgejo Actions and Woodpecker CI take different positions on where CI lives. One ships inside the forge, the other runs as a separate server with its own agents, database and optional autoscaler. The cards below set out those components and the backup, upgrade and monitoring work each layout adds to your team's calendar.

Feature comparison: workflow syntax, runners, plugins and identity

This table sets Forgejo Actions and Woodpecker CI side by side on license, workflow files, step execution, compatibility, plugins, forge support and database defaults. Read each row with your own forge and team in mind, and treat the cells marked for confirmation as questions to put to the vendor or to a test instance before you commit.

What drives the running cost of a separate CI server

Forgejo Actions runs inside the Forgejo server you already operate, while Woodpecker adds a second service with its own server, database, agents and upgrade cycle. The cards below separate the recurring costs of that second service from the one-time work of moving pipelines, so you can ask each vendor or partner for a quote that covers both.

Licensing and editions: what is free and what is paid

Where a Forgejo CI implementation usually runs long

Moving pipelines from Forgejo Actions to Woodpecker, or back

This sequence moves CI workloads between Forgejo Actions and Woodpecker CI in a controlled order, so each pipeline is inventoried, translated, proven in parallel and only then cut over.

1. Inventory every pipeline and its triggers

   The team lead or platform engineer lists every workflow file in each repository, including the event triggers, branch and path filters, scheduled runs, matrix builds, service containers, secrets used and any deployment steps that touch production. Forgejo Actions reads workflows from the repository's workflow directory, while Woodpecker reads a single .woodpecker.yaml or a .woodpecker/ directory. Mark each pipeline as critical, deployment-linked or low-risk. The output is a written inventory that someone other than the author has reviewed, with no pipeline left unclassified.

2. Map events, filters and matrix builds to target syntax

   The engineer translates each trigger and condition into the target system's vocabulary. Woodpecker expresses conditions through when filters on event, branch, path and other fields, and supports matrix builds in its workflow syntax. Forgejo Actions uses its own event and job model, which is familiar to GitHub Actions users but not compatible with it. Write down every construct that has no direct equivalent, such as a custom event or a reusable action, and decide whether to rebuild it or drop it. A switch away from a GitHub Actions-style workflow needs a rewrite of the YAML, not a copy. The check is a mapping table that a second engineer signs off.

3. Separate what transfers from what is rebuilt

   The migration owner records which assets move as they are and which must be recreated on the target. Repository code, container images and the build logic inside scripts generally transfer unchanged. Webhook configuration on the forge must be recreated for the new CI server. Runners or agents, secrets, the CI database, plugin settings and any Kubernetes backend setup are rebuilt on the destination, and secret values must be re-entered through the target's secret store rather than exported in plain text. Woodpecker plugins are container images configured through settings blocks, and the docs note that Drone plugins generally work but may need adjustments, so test each one. The output is a transfer checklist with an owner for each item.

4. Stand up the target CI and rebuild its runners

   The platform engineer installs the target system and registers its runners or agents, following the vendor documentation for the chosen deployment. For Woodpecker, this means the server, one or more agents connected to it, and, where used, the Kubernetes backend with its temporary persistent volume claim settings reviewed for the cluster. The team should confirm the database choice for the expected load, since Woodpecker defaults to SQLite and recommends PostgreSQL or MariaDB for larger instances. For Forgejo Actions, confirm runner registration and labels for each job. The check is a test pipeline that runs on a dummy repository and reports success to the forge.

5. Run both systems in parallel on a non-critical repository

   Choose one low-risk repository and configure the translated pipeline on the target while the original keeps running. Compare results for the same commits, including logs, artifacts, exit codes, timing and failure behavior. Pay attention to environment variables, clone steps and matrix expansion, which are common sources of divergence. Keep deployment steps disabled on the new side during this phase. The owner records each difference and its fix. The exit condition is a run of matching results across the event types the repository actually uses.

6. Expand the parallel run to the remaining pipelines

   After the pilot repository matches, the team applies the same process to the rest of the inventory in the order set during classification, starting with low-risk pipelines and leaving deployment-linked ones for last. Each repository gets its own translated file, its own webhook, and its own secret re-entry. Track which pipelines are still running on the old system so that no trigger fires twice. The output is an updated inventory showing each repository's status.

7. Cut over and retire the previous system

   Disable the old triggers and webhooks repository by repository, confirm that a new commit runs only on the target, and then deploy the change through the production path. Keep the previous CI server and its data available for a rollback window that the organization sets in writing, since the team should not rely on a duration that is not in its own policy. Once the window closes, remove runners, stored secrets on the old system and any retained credentials, and record the decommissioning in the change log. The closing check is that every repository runs only on the target and the old system has no active triggers.

Questions teams ask before choosing or hiring help for CI