Introduction

Crow CI is a Continuous Integration & Continuous Delivery (CI/CD) application. It is designed to be lightweight, fast and extensible.

Features

Coming soon:

Multi-forge Login support
External secret store integration

Advantages of self-hosting CI/CD

There are many CI/CD services these days offered for free. As with all hosted options which are provided for free, there are limitations and (potential) downsides/restrictions. Self-hosting offers ways to get rid of these.

Specifically, the following limitations of public CI offerings can be tackled with a self-hosted Crow CI instance:

Limited build times
Slow runners
Non or limited availability of specific architectures/platforms
Storing (sensitive) secrets on remote platforms/services
Being platform/forge bound

Crow CI vs. other options

Crow CI gives you full control over the selection of servers which are processing your builds, being it the architecture, the size or their location (on-prem, cloud). There is no limit to the number of builds you can run. You are in full control!

In addition, Crow CI is compatible with all common forges (GitHub, GitLab, Gitea, Forgejo, Bitbucket), allowing you to transition between these or use a consistent CI syntax across all of them.

Combined with the Crow CI Autoscaler, which allows to dynamically add new servers with agents in case all existing ones are busy, you can make flexible use of powerful hardware from cloud providers only when you really need it. This keeps costs at a minimum while you retain full flexibility within the cloud provider space.

Containers at the core

Crow CI is designed with a container-first approach. This stands in contrast to other common CI/CD apps like GitHub Actions, GitLab Runner or Jenkins. While these can also execute pipelines in containers if desired, their default mode is “host-first”, i.e., pipelines typically run directly on a virtual machine image and are therefore limited to the operating system(s) provided by the provider.

In contrast, Crow CI is built to use containers by default, making it inherently operating-system agnostic. This means the underlying OS of the host machine running the pipelines is irrelevant. The only requirement is that the host must be running Linux¹.

Target audience

Due to Crow CI being Apache-2.0 licensed, lightweight and having a very small resource footprint (< 200 MB memory consumption), it is also very well suited for homelab environments.

Yet also in corporate environments, Crow CI is an ideal tool to save a lot of money on paying hosted CI/CD services and easily make use of internal CI servers to process builds. Crow CI can be hosted via common container deployment approaches and also provides a dedicated helm chart for Kubernetes environments.

Crow uses a SQLite by default (perfect for small instances) and has support for Postgres and MySQL to serve larger instances. The latter are recommended for instances with multiple (active) users and > 20 active repos².

History

Crow has been forked from Woodpecker CI (v3.0.0) in January 2025 from the former Woodpecker maintainer @pat-s. Motivation for the fork was built around the improvement of infrastructure-related processes (releases, docs, governance) and professionalizing the overall project ecosystem.

Woodpecker itself is a fork of Drone CI (v0.8.91, April 2019) with the first standalone version being released on September 9th 2019.

Crow vs. Woodpecker

As of 2025-12, the following unique features exist in Crow:

Completely rewritten UI (shadcn)
Instance-wide views for secrets, crons, registries and agents
Log retention: Each repository can define its own retention policy. A global default of 90 days is used
DAG support
Server can run in HA with leader election
Maintenance panel to perform period cleanup operations on the database and leftover Kubernetes resources
Descriptive error message: Errors are transparently parsed back to the user in the UI. Almost no “An unknown error occurred” messages are shown
Multi-org agents: Admins can deploy agents which are allowed to process builds from multiple organizations/users
Agent list: All instance agents are listed in the UI, also for non-admin users
Additional pull_request_edited and pull_request_merged event triggers
Early fail when “manual” event triggers are not allowed in the repo: Instead of silently returning nothing, Crow shows a descriptive error message to the user
The agent ID a specific workflow was processed by is shown in the top panel of the log view
Custom agent labels are shown in the agent list
Added CI_COMMIT_PULL_REQUEST_TITLE env var
Manual pipeline runs show possible extra variables that have been passed during the UI
Log view: Top/Down buttons to jump to the top or bottom of the log view
Agents display their remaining workflow capacity in the agent list
Added support for multiple match types when specifying CROW_PLUGINS_PRIVILEGED: semver, semver-range, match and regex
Ability to cancel single workflows in matrix workflows
Improved mobile layout view (spacing, alignment)
Ability to fold the workflow panel and have a full-width log view
Support for setting custom workflow names for single and matrix pipelines via the name: field
Priority support for agents
Local backend for macOS incl. “sandbox” support

Additionally, for the Crow Autoscaler:

Ability to account for static agents: only deploy new (autoscaled) agents if static agents cannot process the queued builds

License

Crow CI is licensed under the Apache 2.0 license (following inheritance from Woodpecker and Drone).

Logo

The logo was designed and kindly contributed by Bold Crow AI.

Crow CI can also process workflows on macOS directly, using the “local” backend. ↩
This is primarily because Crow (still) stores pipeline logs in the DB. A refactoring to storing these outside the DB by default is planned but not yet implemented. ↩