As CodeFloe has a strong focus on automation of any sort itself, providing sophisticated CI/CD solutions to its users is a must.
In accordance with its federated philosophy, CodeFloe does not offer just a single CI/CD solution (which for other services is usually bound to their platform exclusively), but two services, of which one is even forge-agnostic, i.e. it can be connected to other code platforms without the need to change workflows.
It is up to you which one to choose. Crow CI is an independent, centrally administrated CI/CD solution. Forgejo Actions is integrated into the platform and configured on a per-repo basis, following and reusing the same approach of GitHub Actions.
Crow CI
Crow CI is a FOSS CI/CD app written in Go. It is a fork of Woodpecker CI and developed/maintained by the CodeFloe team. If you have a CodeFloe account, you can login to ci.codefloe.com and activate the repos you have access to.
If you encounter usage issues and/or have feature requests, issue them directly in the Crow CI repository.1
Forgejo Actions
Forgejo Actions is developed by the Forgejo team. It allows GitHub-actions based workflows and is directly integrated into Forgejo, the software powering CodeFloe. At the time of writing (early 2025), Forgejo Actions is still in its early stages of development and lacks some features compared to Crow CI.
If you encounter usage issues and/or have feature requests, issue them directly in the respective Forgejo repository.
Limitations
As the hosted runners are open to everyone and run in a semi-public context, the security settings must be "relatively strict". This means that certain features, such as running containers as privileged or mounting external volumes, are not available.2
Note
While this sounds a bit like a downside of these apps, it is not. The same applies to all hosted runner services, including GitHub Actions and GitLab CI.
Hardware
CodeFloe provides the following servers to process CI/CD jobs:
| Name | CPU | Memory | Architecture | Job Capacity |
|---|---|---|---|---|
| ci-amd1 | 16 | 64 | amd64 | 10 |
| ci-arm1 | 8 | 16 | arm64 | 3 |
| gaia | 10 | 32 | arm64 | 5 |
Each workflow/job has the following limits:
- CPU: 4 cores
- Memory: 3GB
Note
There is currently no limit in place for the overall amount of (parallel) builds per user or the build duration per user/org. Such limits will be added in the future.
In the meantime, we appeal to users to be mindful of their usage and avoid excessive resource consumption. Excessive usage or abuse will be detected and addressed.
Info
If enough funds are available (through donations), the CI server fleet will be expanded in the future.
The current resource capacity is already able to process a large number of jobs for many users and provided for free by CodeFloe as a platform.
Examples
The following non-exhaustive list holds exemplary workflows for the respective service.
Tip
You might also spot neat workflow definitions by inspecting the workflows of the CodeFloe or other organizations on the platform.
- gitea/awesome-gitea: "Actions" section from the "awesome-gitea" repository.
- Codeberg-CI/examples: Collection of language-specific workflows for Crow CI (= Woodpecker)
- Delightful Forgejo: Delightful Forgejo Actions list
Connecting your own agent/runner
Note
This is only supported for Crow CI
Crow CI
Follow the documented process to add a new "public" runner from the Crow CI docs.
Use the following settings in the agent config:
Important
You can set additional CROW_AGENT_LABELS. By default, the agent will be restricted to the Crow org_id for which you created the agent token in the Crow UI.
Note
There is no way to configure an agent to process builds of multiple users/organizations. You need to add multiple agents to achieve this.
Actions
There's an existing guide in the Codeberg Documentation which can be followed to add a self-hosted runner for Actions. Just make sure to use https://codefloe.com as the argument for the --instance flag.
Tip
Besides the deployment methods listed in Codeberg's documentation, there is also an Ansible role forgejo_runner in the devxy.cicd collection, which is used to deploy the hosted runner on CodeFloe.
-
If you wonder why Crow CI is hosted on Codeberg and not on CodeFloe: when starting out, the Crow CI org was set up on Codeberg. CodeFloe did not exist at the time. Crow CI might be migrated to CodeFloe in the future. ↩
-
Theoretically, it is possible to do so when you attached your own runners. However, the flexibility of detecting this must first be added to the respective services. Right now, there is no way to allow it only for certain agents. ↩