Forgejo monthly report - January 2026

The monthly report is intended to provide an overview of activities in the Forgejo space over the past month. Additionally, this report covers the previous month, December 2025, as well. If you would like to help, please get in touch via the chatroom or take part in the ongoing discussions.

Releases

Forgejo v14

As planned, Forgejo v14.0.0 was released on January 15. However, the days following the release were busy for contributors as regressions and upgrade problems escalated quickly.

The new stateless CSRF protection in Forgejo v14 caused incompatibility issues when Forgejo was accessed via non-HTTPS connections. This issue was discovered on the day of the release. The referrer policy in the HTML template was set to no-referrer, which prevented the browser from sending the Origin header when posting to Forgejo pages. A patch that changed the referrer policy to strict-origin was included in Forgejo v14.0.1, released on January 17.

Unfortunately, a few Forgejo administrators experienced issues with Forgejo v14 database upgrades. One database mysteriously contained no primary keys, and another had an unexpected SQLite table definition format. Such database quirks tend to be common with self-hosted systems, and Forgejo can learn from these situations to make administration easier in the future. Forgejo will soon issue warnings for primary key schema configuration mismatches and use more typical SQLite tools to decrease the risk of these issues.

Forgejo v14 introduced the ability for a Forgejo Runner to fetch multiple tasks with one API call. However, following its deployment on Codeberg, it was discovered that various Forgejo CI jobs were stuck in the “Set up job” phase and did not execute. The root cause was an intermittent bug in the new multiple task implementation that caused some jobs to be sent to the runner, which the runner then ignored. The Forgejo Runner was patched to support the unexpected output, and version 12.5.3 was released. In addition, Forgejo was patched to not provide the unexpected output from v14.0.2 onwards.

On January 29, Forgejo v14.0.2 was released with general bug fixes and dependency updates.

Security releases: Forgejo v11 and v13

Security releases were published: v11.0.9 and v13.0.4 on January 8.

The security team fixed multiple low-severity vulnerabilities. Among other things, there was a fix for instances where email notifications were disabled which could cause a panic when a new commit was made to a PR against a protected branch. Another fix addressed the privacy of user-configured pronouns. Previously, the /repos/{owner}/{repo} API on public repositories allowed unauthenticated users to access the repository owner’s configured pronouns, even when access was limited to authenticated users.

Forgejo runner v12

Over the past two months the Forgejo runner received five minor updates and nine patch releases. These releases include multiple new features and bug fixes.

LXC Logging Enhancements

Forgejo relies heavily on Forgejo Runner’s ability to run LXC containers for testing purposes. Efforts have been made to address an issue where CI logs occasionally lack critical information necessary for understanding a CI failure. This typically manifests as a test failure where the failure log content is missing at the end. A technical investigation revealed two issues.

The simpler issue was that Forgejo Runner had a race condition when shutting down logging in LXC and host-based executor modes. This could cause the end of the logs to be trimmed. A patch that addresses this issue was included in Runner v12.5.1.

The second issue was that, when executing a command in an LXC container via lxc-attach, the command is subject to rare “short writes” as lxc-attach forwards the log data through the involved pseudo-terminals. This causes brief periods where the logs disappear if the target command writes too quickly for the output buffers to remain available for writing. Forgejo Runner has an in-place workaround that improves but doesn’t completely eliminate the problem. Forgejo is not the first to identify this issue, and it has helped validate two proposed LXC patches. A patch has landed in LXC that will address the problem fully when it is available for Debian systems.

Forgejo Helm chart v16 and v15

The v15 version of the Forgejo Helm chart received one patch release, which corresponds to the Forgejo v13.0.4 release. Additionally, a minor release was made, adding the dnsPolicy configuration option to the Helm chart and setting the Recreate strategy as the default for restarts.

Following the release of Forgejo v14, the Forgejo Helm chart received a new major release to update the default Forgejo version. Two patch releases followed for the corresponding v14 patch releases: v16.0.1 and v16.0.2.

Discussions

Mentions of all users in the main chat room

In the main chat room on Matrix, users expressed their dislike of room mentions for announcements (new Forgejo releases, the monthly report, etc). A discussion has been opened to further investigate this issue and hopefully find a solution.

If you use Matrix and are part of the main chat room, please participate in the discussion to help find a solution. Your vote on how you feel about it and what you would like to happen is especially appreciated.

A discussion has been opened regarding improving the copyright attributions and license assertions in the Forgejo codebase.

Due to the variety of copyright attributions and licenses in Forgejo’s codebase, it could be difficult to determine the correct attributions and licenses in some cases. In the discussion, it was proposed that REUSE could be used to solve this issue. Implementing REUSE would require every file to have a license and copyright attribution. If this is not possible for a file, e.g., if it is binary or test data, then the license and copyright attribution must be defined in a separate file. This strategy could also be enforced via CI checks.

Making the entire Forgejo codebase REUSE compliant will be a significant undertaking. Therefore, the suggestion was made to start with a smaller codebase if the proposal is accepted.

If you are familiar with REUSE or similar tools and are motivated to support this effort, feel free to participate in the discussion.

Improving issue to implementation workflow

Over the past month, work has continued on improving the issue-to-implementation workflow. To implement a feature, it is crucial first to understand the problem and then to design a solution that addresses it. Only then can the implementation start.

The current issue creation workflow caused a lot of confusion for reporters and often lacked the necessary information to fully understand the problem. Therefore, new templates have been designed over the last few months in the hope of improving the workflow. To continue improving the workflow, a corresponding discussion exists.

If you have reported issues to Forgejo and would like to help improve the workflow, please participate in the feedback gathering process.

Notable Pull Requests

Actions: Reusable workflow expansion

Reusable workflows are a Forgejo Actions capability that is often used to replicate a common CI job across multiple repositories. This allows one workflow to include another. For example, one workflow can run a different workflow from another repository:

jobs:
  caller:
    uses: my-org/workflow-library/.forgejo/workflows/reusable.yml@main

However, since this capability was implemented, it has been limited. The runs-on field was required, which prevented the target workflow from having multiple jobs with different runners. Additionally, all of the logs from the target workflow were displayed in the UI as a single “Set up job” log entry. This made the capability functional for some cases, but difficult to use and unable to meet more complex needs.

In December, a significant rework was completed across Forgejo and Forgejo Runner to make these workflows more usable and function more in line with users’ expectations. This feature has been merged into the next major release, Forgejo 15, and will be enabled by removing the top-level runs-on field.

Forgejo Runner: Unsupported Platforms

Although Forgejo Runner officially supports execution on Linux, a wide range of projects use it in environments that Forgejo does not officially support. Contributors have attempted to incorporate patches to ensure the runner builds on these systems, but that support has frequently regressed unintentionally.

Currently, Forgejo Runner is built on a set of unsupported platforms during CI workflows. These platforms remain unsupported because no tests are executed on them during Forgejo Runner CI, and no release builds are provided. However, this allows contributors to determine whether a change will cause support to regress for other projects and make informed decisions. The goal of this change is to minimize disruption to users on unsupported platforms without burdening contributors’ resources.

The unsupported platforms on which Forgejo Runner is built are: DragonFly BSD, FreeBSD, Illumos, NetBSD, OpenBSD, macOS, and Windows.

Auto-linking container images to repositories

Packages in the package registry are uploaded to either an organization or a user. Previously, packages had to be manually linked to a repository in order to be visible in it.

To simplify this process, the handling of packages has been improved. Now, when a package is created, it is automatically linked to a repository based on either the package name or the org.opencontainers.image.source Docker label.

This feature will be available with the upcoming major release, Forgejo v15.

Generate merge commit message in non-mergeable PRs

Previously, merge commit messages generated from the defined template could not be displayed if the pull request was in a non-mergeable state. This meant that, for example, if the conflict was resolved locally and the pull request then underwent manual merging, the merge message also had to be created manually.

This issue has now been resolved with the integration of a new feature that allows the generation of the merge message in the pull request, making it easily accessible for copying.

This feature will also be available with Forgejo v15.

Federation

For a high-level overview, check out the federation roadmap.

Progress has been made on improving the handling of HTTP message signatures. The goal is to to improve scalability and reduce resource consumption by preventing the redundant saving of public keys.

Additionally, steady progress is being made on integrating support for RFC9421 signatures. RFC9421 is used for creating, encoding and verifying digital signatures or message authentication codes over components of an HTTP message. It is an Internet standard that supersedes the commonly used draft version of the same standard on the Fediverse.

Work has also begun on federated searching for remote actors. It uses the WebFinger protocol under the hood, which is a standard for discovering remote actors. This foundational work enables the search for remote repositories and other remote content in the Forgejo explore page.

Overall, federation-related work is steadily progressing, but will still take a lot of time. If you plan to try the existing federation features, please carefully read the warning section in the FAQ first.

Localization

Some maintenance work has been done on the translations.

Indentation in the JSON files has been changed from spaces to tabs.

Additionally, some strings have been migrated from the legacy INI components. This means that the associated history, comments, screenshots, and approval status of these strings are now lost. However, this also marks the beginning of slowly phasing out the legacy components. Notably, the new translation component provides improved plural support for relevant strings. To avoid overwhelming contributing translators with several thousand migrated strings at once, the plan is to distribute the migration in smaller steps over the year.

Infrastructure

Website moved to own infrastructure

Until now, the Forgejo website was hosted on Uberspace.

Since the Forgejo infrastructure has proven to be reliable and is already in place, the website has been moved to the Kubernetes cluster within the Forgejo infrastructure. This allows saving money by using existing resources and gives Forgejo complete control.

If you’re interested in how the deployment process works, you can find some documentation in the README file of the Forgejo website repository.

Renovate for website and docs

Renovate is used to track dependency updates. It automatically opens pull requests and depending on the configuration, auto-merges dependency updates. Renovate is already used in many parts of the Forgeio Space and it has now also been added to the website and documentation repo to help maintain dependencies.

Database of code.forgejo.org grew unexpectedly fast

In November, it was discovered that the code.forgejo.org database was growing much faster than expected. Investigations revealed that this was due to bugs in Forgejo. On the one hand, logs from the Forgejo Runner remained in the database even though they should have been moved to the file system. Secondly, it was found that excessive commit_status entries were being created in the database.

Both problems were fixed in Forgejo v14. A new doctor command was also integrated to delete the excess entries from the database. Due to these two bug fixes, the database size dropped from 33GB to 5.8GB.

Full disk on CI server

On January 16, the Forgejo Runner Server ran out of disk space because the Runner Cache fully occupied all available storage. More specifically, the artifacts cache caused the issue. This is probably due to the large Go cache resulting from the many open PRs, which cannot share the cache for security reasons.

The disk layout was restructured, and the cache was moved to a separate 1TB XFS volume.

In the future, it is also planned to add monitoring for the runner to detect issues faster.

Release automation improved

The Release Manager team is responsible for creating Forgejo releases. To simplify the process, the team has implemented extensive automation. Over the last two months, improvements have been made to release automation, and bugs have been fixed.

If activated, the automatic check for new releases uses a DNS-based approach for privacy reasons. The release automation includes a step for updating the domain record automatically, but a crucial step was missing, causing the need for manual interaction.

As part of the release process, the next instance and code.forgejo.org are updated as an additional safeguard to prevent the release of faulty binaries. This update must be done manually by a DevOps member. A script has been written to create a full backup of the instance before updating it to simplify this manual process.

HTML and JSON compression

Compression of HTML and JSON content has been enabled for hosted Forgejo instances and websites. This is done to save bandwidth and improve performance by reducing response sizes.

Moderation

The Forgejo Moderation Team would like to thank everyone who participated in the Forgejo space. It’s refreshing to see that most participants strive to be nice and helpful. This not only means that the moderation team has less to do, but also that the Forgejo space is a welcoming environment for all.

We have also updated the Code of Conduct page in the documentation. If you’re interested in learning more about the community values or the Code of Conduct, please visit the documentation page.

Other

FOSDEM

Codeberg and Forgejo are collaborating again this year and have a joint booth at FOSDEM. Some contributors from the Forgejo community are present at FOSDEM. If you’re attending FOSDEM, come by and say hi! Of course, there are stickers available at the stand. NLnet has probably some different Forgejo stickers, too (hex variant).

Matrix security disclosure

On 16 July 2025, Matrix announced in a predisclosure that a security vulnerability had been found in the current room versions, which had been fixed. This means for us that all rooms on Matrix must be updated.

All rooms except the main chat room were updated.

The main chat room will be updated in the next few days. An announcement will be made before the room is updated.

We forge

Forgejo is a community of people who contribute in an inclusive environment. We forge on an equal footing, by reporting a bug, voicing an idea in the chatroom or implementing a new feature.

The following list of contributors is intended to reflect this diversity and to acknowledge all the contributions made over the past two months. If you are missing, please ask for an update.