Forgejo Release Notes

Forgejo version 17.0 was released on 15 October 2026. Forgejo is a lightweight, community-developed, self-hosted platform for code collaboration.

This article contains a selection of the changes that were introduced. A complete list of changes is available in the release notes.

A dedicated test instance is available to try it out. Before upgrading, it is strongly recommended to make a full backup as explained in the upgrade guide and carefully read all breaking changes from the release notes. If in doubt, do not hesitate to ask for help in the chat room.

Breaking changes

Absolute links in rendered documents

In rendered documents, absolute links to resources inside a repository are now resolved with respect to the root of the repository. This is a breaking change from the previous behaviour when these links were rendered using the root of the instance. Absolute links in issue and pull request descriptions and comments remain rendered with respect to the instance’s root.

This change increases the compatibility with other Git forges and thus, makes migrations to Forgejo even easier.

Action required

Deprecation of action run webhook events

Action run webhook events are replaced by the more capable and less problematic workflow run events. The action run events have been deprecated for removal in a future Forgejo version. Unfortunately, it is not possible to migrate existing webhooks to the new events automatically because some headers (X--Event, X--Event-Type) and the action key have changed, which might break existing receivers. Furthermore, completion notifications are only emitted after all jobs of a run have terminated.

Please inspect existing webhooks and manually migrate them to the workflow run events after verifying that the webhook receivers can process them without issues.

New features

Support for FUNDING.yml

For repositories that contain a FUNDING.yml file, Forgejo shows a new “Donate” button which presents a list of donation options when clicked.

Additionally, for users and organizations that have such file in their .profile repository, a similar button appears on their profile pages.

This feature currently exists only in the web interface, but we are considering to implement an API surface for it. If you have a use cases for such API feature, please help shape it by sharing your feedback in the dedicated issue.

Auto-completion for issues and pull requests

When authoring an issue, pull request, or comment, Forgejo will offer auto-completion for issues and pull requests. To activate the auto-completion, type # for issues or pull requests, or ! for pull requests only. To refine the suggestions, either continue with a search term or an issue or pull request number.

LFS support improvements

Forgejo’s Git LFS support is being overhauled. While most changes are under the hood, a string of smaller improvements are visible to users. Those include navigation and overview improvements in the LFS settings, new views to discover the commits that refer to a given LFS file, and better handling of pointers.

Invitations to organizations

Forgejo can be configured so that when adding a user to an organization, they are not added to the organization instantly but instead receive an invitation that can be accepted or declined. This behavior can be enabled by setting [service].ADD_MEMBERS_BY_INVITATIONS = true in Forgejo’s app.ini.

Authentication providers are still able to add users to organizations with no action on their part.

The invitations are visible on the organization profile and are sent out by email. By default they expire after 14 days.

Work is ongoing to make those invitations visible in the in-app notifications.

Add/invite to multiple teams at once

A user can now be added or invited to multiple teams in one go, without going through each needed team individually.

Copy comment Markdown

Markdown contents of comments can now be easily copied via the ellipsis menu.

Forgejo Actions API improvements

The Forgejo HTTP API received multiple enhancements related to Forgejo Actions:

• Entire workflow runs and individual jobs can now be rerun by sending requests to /repos/{owner}/{repo}/actions/runs/{run_id}/rerun and /repos/{owner}/{repo}/actions/jobs/{job_id}/rerun respectively. The workflow runs or jobs must have completed. Otherwise, they cannot be rerun. However, individual completed jobs can be rerun while the workflow run is still being executed.
• The HTTP endpoints for obtaining job logs gained substring filters and the ability to only return the logs of a particular step with /jobs/{job_id}/logs?step=N. In addition to plain text, the logs can be requested as NDJSON with ?format=ndjson.
• /repos/{owner}/{repo}/actions/jobs/{job_id} enables users to get the details of a particular job.

Forgejo Actions job summaries

Forgejo now displays job summaries generated by Forgejo Runner 13.2 or newer.

Job summaries are Markdown documents that belong to a particular Forgejo Actions job. They are displayed above the logs. All Markdown features supported by Forgejo can be used — including tables, Mermaid diagrams, and formulas written in KaTeX.

Job summaries are assembled from one or more Markdown fragments that are written by a step to the file $FORGEJO_STEP_SUMMARY. $GITHUB_STEP_SUMMARY is supported, too, for compatibility with existing actions and easing the transition from GitHub.

Allow pushing to AGit refs

Maintainers and pull-requests creators can now directly push to the AGit refs:

# Pull Request Creator
git checkout -b local-branch
git push origin HEAD:refs/for/main/agit-topic

# Maintainer/Reviewer can pull the code to a local branch
git fetch origin refs/pull/3/head:local-branch
git switch local-branch

# Maintainers and Pull Request creator need some further git config
git config push.default upstream
git config branch.local-branch.merge refs/pull/3/head
git config branch.local-branch.remote origin

# NEW: Maintainer and Pull Request creator can now (force) push and pull to this ref
git push
git pull

Webhook notifications for workflow jobs

More events have been added to Forgejo’s webhooks. Webhooks can now be triggered when the status of a Forgejo Actions workflow job changes. As usual, it is possible to receive notifications in various chat applications like Discord or Matrix. Alternatively, Forgejo is able to notify a remote server using an HTTP request. Users have the possibility to select which statuses, like “waiting” or “cancelled,” they want to receive notifications for.

While prior versions of Forgejo could already trigger notifications for “action runs,” that capability was limited to completion events. It has been enhanced to match the capabilities of workflow job events. Users can now select which statuses they want to receive notifications for. The old “action runs” events have been deprecated and will be removed in a future Forgejo version.

Repository migration from Bitbucket Data Center

Forgejo can now migrate repositories from Bitbucket Data center (formerly Bitbucket Server). Pull requests, reviews, comments (including multi-line comments), threads and replies can also be imported during the process. Authentication uses an HTTP access token, and “HTTPS SCM Hosting” must be enabled on Bitbucket as Forgejo migrations clone over HTTPS.

Migration of repository avatars

When migrating repositories from Gogs, Gitlab, Gitea, or Forgejo, the repository avatar images are now migrated, too.

Backup documentation

A new guide on how to backup and restore a Forgejo instance has been added to Forgejo’s documentation. In particular, it points out the most important secrets that need to be backed up for proper instance restoration.

Release schedule and Long Term Support

Based on the release schedule, major releases are published every three months. Patch releases are published more frequently, depending on the severity of the bug or security fixes they contain. Forgejo v17.0 is a non-LTS release. It will be supported until 28 January 2027.

17.0-test daily releases

Releases are built daily from the latest changes found in the v17.0/forgejo development branch. They are deployed to the https://v17.next.forgejo.org instance for manual verification in case a bug fix is of particular interest ahead of the next patch release. It can also be installed locally with:

• OCI images: root and rootless
• Binaries

Their names are staying the same, but they are replaced by new builds every day.

Get Forgejo v17.0

See the download page for instructions on how to install Forgejo.

Upgrading

Carefully read the breaking changes section of the release notes.

The actual upgrade process is as simple as replacing the binary or container image with the corresponding Forgejo binary or container image. If you’re using the container images, you can use the 17.0 tag to stay up to date with the latest 17.0.Y patch release automatically.

Make sure to check the Forgejo upgrade documentation for recommendations on how to properly back up your instance before the upgrade.

Contribute to Forgejo

If you have any feedback or suggestions for Forgejo, do not hold back; it is also your project. Open an issue in the issue tracker for feature requests or bug reports, reach out on the Fediverse, or drop into the Matrix space (main chat room) and say hi!

Donate

Forgejo is proud to be funded transparently. Additionally, it accepts donations through Liberapay. It is also possible to donate to Codeberg e.V. in case the Liberapay option does not work out for you, and part of the funding is used to compensate for work on Forgejo.

However, the Liberapay team allows for money to go directly to developers without a round-trip to Codeberg. Additionally, Liberapay allows for a steady and reliable funding stream next to other options, a crucial aspect for the project. The distribution of funds through Liberapay is transparently controlled using the decision-making process, and Forgejo contributors are encouraged to consider applying to benefit from this funding opportunity.

Thank you for using Forgejo and considering a donation, if your financial situation allows.

Original source

Forgejo Runner v13.1.0 was released on August 31st, 2026. This minor feature release includes a new experimental plugin capability, changes to commands running in a terminal, preparations for a Forgejo bug-fix, and a variety of routine dependency upgrades.

The complete release notes are at v13.1.0’s release page.

Plugin Capability

Forgejo Runner currently supports running jobs in three different execution engines: within Docker/Podman containers, within LXC containers, and without any containers running directly on the host. Many community members have expressed interest in adding new execution engine capabilities to Forgejo Runner, such as running jobs in Firecracker microVMs, Kubernetes pods, QEMU/libvirt VMs, systemd-nspawn containers, and directly on cloud hyperscalers. However, the Forgejo development team doesn’t have the capacity to build all of these execution engines and provide long-term support for them.

Forgejo Runner now supports a plugin execution engine that allows these execution engines to be created as external applications and to be used by jobs running on a Forgejo Runner.

Forgejo Runner v13.1.0 is the first release with this plugin engine. The plugin engine operates by connecting to a running daemon via the gRPC protocol, and executing a series of RPC interactions to create environments, run commands, capture output, and cleanup. This capability is currently considered experimental; the protocol is considered an alpha release.

As an experimental feature, the Forgejo team is not fully committed to this feature as a permanent addition. We believe it is a good direction, and we believe we can continue to iterate it to a fully supportable and capable feature based upon feedback from ourselves and other users. But as that feedback is collected and incorporated, we leave open the possibility that we may gain new knowledge and be required to change direction.

As an alpha protocol, we consider the protocol is subject to change with no stability guarantees at the moment. As we collect feedback from the community on the protocol, we may find that design decisions need to be revised in order to meet the broad and flexible needs of all the possible execution engines that could use the plugin. But we feel that it’s in a good place to start development with, and that it isn’t likely to encounter major protocol changes.

Related development work:

• https://code.forgejo.org/forgejo/runner/pulls/1500
• https://code.forgejo.org/forgejo/runner/pulls/1713
• https://code.forgejo.org/forgejo/runner/pulls/1719
• https://code.forgejo.org/forgejo/runner/pulls/1710
• https://code.forgejo.org/forgejo/runner/pulls/1705
• https://code.forgejo.org/forgejo/runner/pulls/1686

How a Plugin Works

A plugin is an application that exposes the plugin.v1alpha gRPC service, typically on a local network port or UNIX socket. This service is defined in Forgejo Runner’s plugin.proto. The plugin must also implement the standard grpc.health.v1 gRPC service.

Once a plugin application is running, it needs to be added to Forgejo Runner’s configuration file in the plugins section. For example:

log:
# ...
runner:
# ...
server:
# ...

# Add a plugins section:
plugins:
  my-plugin:
    # the plugin name here is used in labels, coming up next
    address:
      127.0.0.1:50051
    # can also be a unix socket - unix:///run/my-plugin.sock
    options:
      # `options` is an arbitrary map of string -> string. Values configured
      # here are provided to the plugin in the `CreateRequest` message. Their
      # purpose are defined by the plugin.
      option_a:
        value_b

Once a plugin is defined, it can be used by defining labels. A label matches the value of a runs-on: ... definition in a Forgejo Action job, and defines what execution engine to run the job within, and optionally additional information for the execution engine. Plugin labels work the same way.

runner:
  labels:
    - 'docker:docker://node:current-bookworm'
    # typical docker label
    - 'bare-metal:host'
    # typical "host" executor label
    # When a job is defined as `runs-on: my-plugin-a`, then this label will be
    # matched. The plugin `my-plugin` will be used to execute the job. The
    # value `some-parameter` will be passed to the plugin in the
    # `CreateRequest` message, as the field `image`. The `image` value can be
    # overridden by the `jobs.<job_id>.container.image` value in the workflow.
    - 'my-plugin-a:my-plugin://some-parameter'

Having defined a plugin, and a label to use that plugin, jobs can now be configured to runs-on: my-plugin-a. For example:

on:
  pull_request:
jobs:
  test-job:
    runs-on:
      my-plugin-a
    steps:
      - id:
          stepwithoutput
        run: |
          echo "myvalue=outputvalue1" >> $FORGEJO_OUTPUT
      - run:
          echo "previous myvalue was ${{ steps.stepwithoutput.outputs.myvalue }}"

When this job is executed, the plugin protocol will follow these steps; the details provided and returned from the RPC calls is documented in the protocol definition file:

• Capabilities RPC will be invoked in order to see the capabilities of the plugin.
• Create RPC will be invoked in order to create an execution environment.
• Start RPC will be invoked to start the environment. This RPC can stream data back to Forgejo Runner, which will appear in the Set up job section in the Forgejo Actions log UI.
• CopyIn RPC will be invoked in order to store a script into the execution environment, representing the first step, echo "myvalue...".
• Exec RPC will be invoked once to execute the script uploaded to the environment by CopyIn.
• CopyOut RPC will be invoked multiple times to read per-step files, such as the one written to by $FORGEJO_OUTPUT.
• CopyIn, Exec, and CopyOut will be repeated for each step in the workflow.
  • When an action like uses: actions/checkout@v4 is executed, a CopyIn operation is performed that provides the entire action codebase.
• Remove RPC will be invoked at the end of the job to tear down the execution environment and free all related resources.

Example Implementations

Two example implementations were developed during the plugin creation in order to validate and test capabilities, and may be useful to other developers as reference implementations.

Forgejo Runner contains a testplugin, which is written in Go. It operates similarly to the host-based executor, as it runs commands on the current host in a temporary directory.

runner-systemd-nspawn is a Rust application which permits running jobs in systemd-nspawn containers.

Neither of these example implementations are suitable for production usage.

Commands with Attached Terminal (Breaking)

Forgejo Runner does not operate as a terminal when it runs a job. When it collects logs and they are displayed in Forgejo, a small subset of ANSI text formatting sequences are supported; but, terminal control commands such as moving the cursor, clearing the line, clearing the screen, and so on are not supported. Despite these limitations, Forgejo Runner has often been signaling to commands that they are running within a terminal by attaching a pseudo-tty (pty) to the process’s stdout and stderr outputs. Depending on the command being run, this can result in a large amount of garbage data being generated to the logs of a Forgejo Action.

In Forgejo Runner v13.1.0, these terminal attachments are removed.

For most commands executed by a job, this will have no impact. Some commands detect whether stdout is a console and will only use ANSI colour sequences when it is, and those commands will no longer have colourful output. Some commands support a quasi-standardized FORCE_COLOR=1 environment variable to restore colour output even when not using a terminal.

For a small subset of commands, the removal of the terminal attachment will break their execution. For example, running a workflow which executes docker run -it ... would attach a terminal to a Docker container, and would fail if you’re not currently in a terminal. This specific command can be fixed by removing the -t option. This was not an anticipated side-effect of this change, but has been reported to the Forgejo team since the release.

Related changes:

• Removal from docker execution
• Removal from host & LXC execution

Original source

Breaking changes

Workflow Predictability

Forgejo Runner previously recognized a couple scenarios of invalid workflow syntax, logged a warning about the situation, and proceeded to run the workflow. These cases have been changed to errors.

Expression evaluation may trigger errors which now fail workflows. For example, if using

${{ format('Param: {0}, {1}', 'abc')}}

, a message such as

"The following format string references more arguments than were supplied

will be output and the job will terminate with an error.

Using

strategy.matrix

to exclude a value from a job matrix, where that matrix value does not exist, is also now an error that will prevent a workflow from executing.

• fix: fail jobs, steps if expression interpolation fails
• fix: turn invalid matrices into a hard error

Security: Workflow Commands

Workflow commands are a capability to log text while running a workflow and have a side-effect by printing to the console. This capability introduces security risks to an action, as many workflows print user controlled text to the console and can be used to impersonate workflow commands.

The following workflow commands have been removed from Forgejo Runner.

add-path

If workflows still use

add-path

, a warning will be printed, and the command will have no impact. Workflows that need to amend

PATH

of successive steps should write to

$FORGEJO_PATH

:

Instead of:

• run
  : |
  echo "::add-path:: /add-to-path"

Use:

• run
  : |
  echo "/add-to-path" >> "$FORGEJO_PATH"

Contrary to GitHub Actions, it is not possible to restore it again by setting the environment variable

ACTIONS_ALLOW_UNSECURE_COMMANDS=true

.

• chore: remove workflow command add-path

set-output

Workflows that want to set output variables must no longer use

set-output

. If workflows still use

set-output

, a warning will be printed. Workflows that want to set output variables can do so by writing to

$FORGEJO_OUTPUT

.

Instead of:

• run
  : |
  echo "::set-output name=MY_VARIABLE::value"

Use:

• run
  : |
  echo "MY_VARIABLE=value" >> "$FORGEJO_OUTPUT"

• chore: remove workflow command set-output

set-env

If workflows still use

set-env

, a warning will be printed. Workflows that need to amend the environment can write to

$FORGEJO_ENV

.

Instead of:

• run
  : |
  echo "::set-env name=MY_VARIABLE::value"

Use:

• run
  : |
  echo "MY_VARIABLE=value" >> "$FORGEJO_ENV"

Contrary to GitHub Actions, it is not possible to restore it by setting the environment variable

ACTIONS_ALLOW_UNSECURE_COMMANDS=true

.

• chore: remove workflow command set-env

Security: Docker Authentication

When Forgejo is configured with the secrets

DOCKER_USERNAME

and

DOCKER_PASSWORD

, Forgejo Runner would attempt to use them to authenticate to any container registry that required authentication when pulling images. This posed an security risk as the credentials may be sent to an unexpected container registry.

The functionality can be replaced by specifying credentials explicitly using

jobs.<job_id>.container.credentials

.

• chore: remove ability to use secrets for registry authentication

Docker Minimum Dependency

The minimum requirement for Docker has been raised to Docker 25.0.

Forgejo Runner’s library for interacting with Docker was upgraded in this release. This upgrade triggered a bug in some versions of Docker when using IPv6 networks on their containers (moby 49520, 52991), resulting in an error like

2026/07/01 14:58:59 Could not get list of networks: ParseAddr("fd05:d0ca:2::1/112"): unexpected character, want colon (at "/112")

. This issue is fixed in Docker v28.0.1. If you are affected by this issue, you can upgrade Docker, or remain on Forgejo Runner v12 until such an upgrade is available to you.

• chore: upgrade github.com/docker/cli to v29

Runner Configuration

When administrating a Forgejo Runner, the environment variables

GITEA_DEBUG

,

GITEA_TRACE

,

GITEA_RUNNER_CAPACITY

,

GITEA_RUNNER_FILE

,

GITEA_RUNNER_ENVIRON

, and

GITEA_RUNNER_ENV_FILE

are now ignored and have no effect.

The Runner configuration option

container.network_mode

has been removed.

container.network

can be used instead.

Support for the

${{ gitea.[...] }}

context was removed from Forgejo Runner. This capability only worked with

forgejo-runner exec

.

• chore: remove support for deprecated GITEA_ environment variables
• chore: remove deprecated config variable NetworkMode
• chore: remove Gitea compatibility

Original source

Forgejo version 16.0 was released on 16 July 2026. Forgejo is a lightweight, community-developed, self-hosted platform for code collaboration.

This article contains a selection of the changes that were introduced. A complete list of changes is available in the release notes.

A dedicated test instance is available to try it out. Before upgrading, it is strongly recommended to make a full backup as explained in the upgrade guide and carefully read all breaking changes from the release notes. If in doubt, do not hesitate to ask for help in the chat room.

Breaking changes

• Hardening mirrors against SSRF: Administrators can determine which hosts can be accessed by Forgejo for Git mirroring via config settings [migrations].ALLOWED_DOMAINS/LOCKED_DOMAINS/ALLOW_LOCALNETWORKS. Edge cases where these settings were ineffective were fixed. Git option http.followRedirects=false is now set to prevent Git from following HTTP redirects that could violate config settings. Mirroring involving renamed or transferred remote Forgejo repositories will now treat redirects as errors; mirrors must be updated.

• EXIF Stripping Removed: Forgejo v13.0 added capability to remove EXIF metadata from user avatar images, but due to a licensing mistake relying on an AGPL-licensed library, this capability has been removed to ensure license compliance.

• Trusted proxies setting in containers: Default container setting REVERSE_PROXY_TRUSTED_PROXIES = * can allow unauthorized user impersonation if combined with certain other settings. Forgejo now requires sysadmins to set REVERSE_PROXY_TRUSTED_PROXIES to appropriate trusted addresses in containerized environments to avoid security risks.

New features

• Granular repository watch settings: Users can select notifications from specific parts of a repository (Issues, Pull requests, Releases) with a reworked notification backend for future granularity.

• Repository migration progress: Migration screen now shows progress of migrated issues and pull requests in batches (default batch size 45).

• Downsized avatar variants: Two downscaled avatar variants are generated and served where full size is not required, reducing bandwidth and improving load speeds.

• Easier way to add team members: Dialog accessible directly on organization members list allows adding members and assigning them to multiple teams at once.

• Consistency check of incoming objects: Git is now configured to check for inconsistencies in incoming objects to prevent repository corruption.

• Prevent Git hook examples in repositories: Forgejo no longer populates Git’s example hook files on backend repositories; instance-wide Git hooks are stored centrally, saving about 20 KiB per repository.

• Repository units hint: Fixed bug so hints about enabling repository units are shown to new users; easier to discover how to disable these hints.

Pull requests improvements

• Redesigned commits view: New cleaner, responsive layout for commit lists, currently on pull request pages with plans to expand.

• Multi-line reviews: Ability to add pull request review comments on multiple lines by holding Shift and selecting lines.

• Review comment placement: Fixed issues with comment placement using internal git blame --reverse to track code changes accurately.

Forgejo actions improvements

• Manual workflow run prioritization: Workflows can be manually marked as prioritized to run before others.

• Authorized Integrations: Forgejo v16 adds ability to authenticate API and Git access using JWTs, allowing external systems to access Forgejo APIs and Git repositories securely without static secrets.

Other notable enhancements

• Evaluation of conditions in Forgejo workflows without dispatching jobs to Forgejo Runner for faster execution.
• Removal of old workflow runs by repository admins.
• Workflow syntax enhancements supporting GitHub timezone syntax in cron expressions.
• Skipped checks are now marked as skipped instead of succeeded.

API improvements

• Added endpoints for obtaining workflow logs, interacting with artifacts (list, download, delete), cancelling workflow runs, and an endpoint providing info about the workflow run for the automatic token.
• Other API additions include organization model creation time, filtering pull requests by base and head branch names, managing user access tokens, and filtering users by 2FA status.

Release schedule and Long Term Support

• Major releases every three months; patch releases as needed.
• Forgejo v16.0 is a non-LTS release supported until 29 October 2026.

16.0-test daily releases

• Daily builds from v16.0 development branch deployed to https://v16.next.forgejo.org for manual verification.

Get Forgejo v16.0

• See the download page for installation instructions.

Upgrading

• Read breaking changes section carefully.
• Upgrade by replacing binary or container image with Forgejo binary or container image tagged 16.0.
• Check Forgejo upgrade documentation for backup recommendations.

Contribute to Forgejo

• Feedback and suggestions welcome via issue tracker, Fediverse, or Matrix chat.

Donate

• Forgejo is transparently funded and accepts donations through Liberapay or Codeberg e.V., supporting development and funding distribution controlled transparently.

Original source

Forgejo v15.0

Forgejo v15.0 refines areas of day-to-day usability and security, and incorporates new capabilities in advanced Forgejo Actions usage.

UI enhancements in issue filtering and the releases list make Forgejo easier to interact with. Auto-linking containers to repositories removes a manual step from repository administrators. Git notes can now be modified from the single-commit view in pull requests.

Repository specific access tokens allow for more secure API interactions.

Forgejo Actions can now expand reusable workflows, providing a better user experience and more powerful capabilities. OpenID Connect support allows for secure access to third-party systems. Forgejo Runner registration improvements allow a simpler installation process for most users, and ephemeral runners allow secure autoscaling capabilities for advanced integrations.

Default cookie names changed

Default cookie names have been stripped of branding. Unless cookies were renamed in the instance config, all users will have to re-login after upgrade. This can be prevented by changing the option COOKIE_REMEMBER_NAME back to gitea_incredible.

Docker rootless config file location

In Forgejo v8.0.0, the default location for the config file was changed from /etc/gitea/app.ini to /var/lib/gitea/custom/conf/app.ini. Backward compatibility logic and startup warnings were added to container setup and entrypoint scripts. Now they are removed. This change only affects those using container deployments with rootless images. If you have the config file stored in a volume bound to container’s /etc/gitea, move it to the new location or override the environment variable GITEA_APP_INI. An unused volume /etc/gitea can be safely removed from the container after moving the config or if the deployment never used versions prior to v8.0.0.

Repository specific access tokens

When creating an access token, it is now possible to restrict the new access token to a specific list of repositories. The access token will not be able to perform operations on any resources outside of this list, except for read-only access to public repositories. For more detailed information, review the updated Access Token Scope documentation.

Authorization changes were made to many Forgejo repository APIs to align the expectations of the new access tokens and the existing public only access tokens with the designed security expectations. Changes to the behaviour of public only tokens were included during this alignment, which have been documented as breaking changes in the Forgejo release notes.

Auto-linking containers

When uploading a container via Forgejo’s package registry, it is now automatically linked to a repository in the following scenarios:

1. The container has the org.opencontainers.image.source label set to a URL of a repository.
2. The name of the container begins with {owner}/{repo}.

Improved error messages

If an access token that doesn’t exist in Forgejo’s database is supplied via OAuth2, the error now explicitly tells that such token doesn’t exist. Previously it would yield a generic error that the user doesn’t exist.

When pushing to a repository without write permission, git push now returns a more detailed message: Who was pushing (helpful if you pushed with the wrong key or token), to which repository and branch (maybe the remote was wrong), and instructions on how to create a PR via AGit workflow.

Sessions only for logged-in users

If you’ve ever wanted to distinguish between logged-in and anonymous users at a reverse proxy or web application firewall, you’ve likely found that it’s not possible. Previously, every anonymous user received a session cookie, even when no data was attached to the session.

This situation was improved by setting a session cookie only when data needs to be set, either because the user is logged in or because they are going through the sign-in process. Validating that the cookie has been set by Forgejo and is valid is enough to distinguish between anonymous and logged-in users.

Exclude labels with button

The way of excluding labels in the filters menu has been reworked. Pressing the Alt key on the keyboard is no longer needed, a button can now be used, making the feature possible to use without a keyboard. The buttons are always visible when it’s not possible to hover, e.g. when using a touch screen.

Responsive releases list

Releases page has been reworked to be usable on screens of all kinds of shapes.

Improved Git notes editing

Git notes can be attached to commits. The addition, editing and removal of notes was improved. Editing can now be cancelled within the UI. Additionally, notes can now be modified from the single-commit view in pull requests.

Please document your archival

Although Forgejo will not require you to provide an archival reason when archiving a repository, it now suggest that you do so when applicable.

Accessibility improvements

There have been numerous improvements to screen reader usability in this release. Although they are not visible when looking at Forgejo’s UI, they are very important for accessibility to visually impaired people.

Reusable workflow expansion

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

Since this capability was implemented, it has been limited: the runs-on field was required preventing the target workflow from having multiple jobs with different runners, and all of the logs from the target workflow would be 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 some more complex needs at all.

Forgejo v15.0 includes a significant rework in order to make these workflows more usable, and function more inline with user’s expectations. When the top-level runs-on field is removed, the workflows referenced by uses will be expanded by Forgejo into their internal jobs and dispatched independently.

This separation of each individual job allows their logs to appear separately in the Forgejo Actions logs UI, making for a more easy-to-understand experience when reviewing the logs.

Expansion into individual jobs allows multiple runners to pick up each job, potentially with different labels, or running on different system configurations or platforms.

OpenID Connect Identity

It is very common for Forgejo Actions workflows to authenticate with 3rd-party systems for validation or deployment of software changes. Up to Forgejo v14.0, the typical solution is to create secrets in Forgejo that contain authentication tokens for these systems. This solution works, but it has security downsides — notably, an attacker who is capable of stealing those tokens has tokens that may last forever. Good security practices would include rotating these tokens from time-to-time to minimize the risk, but such practices are not as common as they should be.

OpenID Connect tokens offer an alternative federated identity option which, if supported by a 3rd-party system, avoids the security risks of static, unchanging tokens. With this system, an action workflow asks Forgejo for a signed JWT, Forgejo provides it, and the external system can authenticate that incoming service calls originate from a Forgejo workflow with specific claims. Unlike the static security token approach, the trust relationship is server-to-server and any intercepted, leaked, or exfiltrated tokens have a short applicability lifetime.

With changes to both the Forgejo Runner (>v12.5.0) and Forgejo (in v15.0), Forgejo Actions will support this capability as well. Detailed documentation is available to review the system architecture and support users in implementing this capability.

Ephemeral Runners

Forgejo now supports registering runners that are restricted to running a single job. Their registration with Forgejo is deleted after the job is completed, preventing the runner’s credentials from being re-used. This feature allows external orchestration tools for runner autoscaling to minimize their security risks by generating temporary credentials for each job being dispatched to a runner in an orchestrated fleet.

For example, a runner can be registered through Forgejo’s API:

After the job is fetched and completed, the runner’s credentials are invalidated.

Simplified Runner registration

Forgejo v15.0 contains a new registration workflow for Forgejo Runner which has a simple web experience. Rather than running a CLI registration tool on the Forgejo Runner, which can be an tricky step to manage when within a Docker container, it is now possible to create a runner through Forgejo’s web UI (and web API):

And then copy a few settings into the Forgejo Runner configuration file and start-up the Forgejo Runner.

Forgejo Runner’s installation documentation has been refreshed with the new updates, and detailed documentation on the interactive registration process is available.

Release schedule and Long Term Support

Based on the release schedule, major releases are published every three months. Patch releases are published more frequently, depending on the severity of the bug or security fixes they contain. Forgejo v15.0 is a Long Term Support (LTS) release and will be supported until 15 July 2027.

Forgejo v11.0, the previous LTS release, will be supported until 16 July 2026, giving everyone enough time to upgrade to Forgejo v15.0. If you upgrade from v11.0, please remember to also check the release notes for v12.0, v13.0, and v14.0 for breaking changes.

15.0-test daily releases

Releases are built daily from the latest changes found in the v15.0/forgejo development branch. They are deployed to the https://v15.next.forgejo.org instance for manual verification in case a bug fix is of particular interest ahead of the next patch release. It can also be installed locally with:

OCI images: root and rootless
Binaries

Their names are staying the same but they are replaced by new builds every day.

Get Forgejo v15.0

See the download page for instructions on how to install Forgejo, and read the release notes for more information.

Upgrading

Carefully read the breaking changes section of the release notes.

The actual upgrade process is as simple as replacing the binary or container image with the corresponding Forgejo binary or container image. If you’re using the container images, you can use the 15.0 tag to stay up to date with the latest 15.0.Y patch release automatically.

Make sure to check the Forgejo upgrade documentation for recommendations on how to properly backup your instance before the upgrade.

Release and upgrade party

On Thursday, after the release and starting 16.00 UTC (18.00 CEST), all members of the Forgejo community are invited to our release and upgrade party. It can be used to review the release cycle, exchange feedback and discuss future plans. Also, Forgejo admins are invited to perform upgrades of their installations during the meeting and get help from the Forgejo maintainers in case of any issues.

Audio + chat meeting on BigBlueButton:
https://lecture.senfcall.de/ott-hqp-axg-yvm

Contribute to Forgejo

If you have any feedback or suggestions for Forgejo do not hold back, it is also your project. Open an issue in the issue tracker for feature requests or bug reports, reach out on the Fediverse, or drop into the Matrix space (main chat room) and say hi!

Donate

Forgejo is proud to be funded transparently. Additionally, it accepts donations through Liberapay. It is also possible to donate to Codeberg e.V. in case the Liberapay option does not work out for you, and part of the funding is used to compensate for work on Forgejo.

However, the Liberapay team allows for money to go directly to developers without a round-trip to Codeberg. Additionally, Liberapay allows for a steady and reliable funding stream next to other options, a crucial aspect for the project. The distribution of funds through Liberapay is transparently controlled using the decision-making process, and Forgejo contributors are encouraged to consider applying to benefit from this funding opportunity.

Thank you for using Forgejo and considering a donation, in case your financial situation allows you to.

Original source

Summary

Forgejo v14.0 improves everyday usability while strengthening reliability and safety.

Issue and pull request search gains simple inline filters, the web editor switches to a lighter experience, and more parts of the interface work smoothly without JavaScript. In addition, a new stateless CSRF protection allows keeping tabs open for a long time and to resume work without interruptions.

Forgejo Actions adds finer-grained trust controls, better visibility for queued jobs and advanced concurrency and dynamic matrix support. Forgejo’s operational reliability has also been enhanced with database deadlock fixes and foreign‑key improvements.

Administrators are recommended to review Commit Status Cleanup for information about an optional post-upgrade data cleanup procedure.

UI features

• Search syntax support for Issues and PRs

  Several simple search filters are now available in Issue/PR search. Information about usage of these filters is accessible through in-app documentation (click the question mark located adjacent to the search bar) and via the dedicated documentation page. Dropdown filters are compatible with the new simple search filters.

• New file editor

  The previous web file editor, Monaco by Microsoft, was overly complex for single-file edits and had issues with performance, loading times, accessibility and mobile usability. It has been replaced with a lighter-weight editor CodeMirror, which is better suited to this use case and resolves the previously mentioned issues.

• Switch between formats when previewing CITATION.{cff,bib} files

  When previewing a CITATION file (CFF or BIB), a switch allows for switching between formats (other formats could be added, though some libraries have incompatible licenses). The “Cite repository” menu item now links directly to this preview page instead of opening a popup.

• Interact with UI without JavaScript

  Work has progressed on making the Forgejo web UI functional without JS. A bug has been fixed, making it possible to post comments without JS enabled. Several ellipsis menus have been made accessible, including the user menu in the navbar. There are now more expandable elements that work without JS.

Improvements to Forgejo actions

Pull Request Trust Management

Forgejo’s ability to “Approve” actions execution from a pull request has been enhanced with new options to approve once, always, and deny execution. Once a user is approved for execution, abuse can also be managed by revoking access for execution.

Commit Status Cleanup

During the Forgejo 14 development cycle, a bug was discovered in Actions that caused many redundant records to be added to the commit_status table while an action was running. In most cases, these records have accumulated since Actions was first developed, affecting all users. A fix for that defect has been introduced in Forgejo 14.

The Forgejo CLI has been augmented with a doctor cleanup-commit-status command which can be used to cleanup redundant records. When the Forgejo Devops team executed this tool on the code.forgejo.org instance, 14.9 million out of 15.2 million records (97%) were identified as redundant records caused by this bug.

Two options for the tool allow the administrator to control the memory usage as records are inspected (--buffer-size 100000) and the number of records deleted in each DELETE query (--delete-chunk-size 1000).

Forgejo instances running on SQLite may experiencing locking errors while the cleanup-commit-status command is running due to two processes accessing the same SQLite database files. For a typical SQLite-based instance with few users and light load, this is likely to be short-lived. For a larger SQLite-based instance, it is recommended to run with a smaller delete chunk size, or to run the command while Forgejo is offline.

”Waiting” status Display

Actions that are waiting for a runner with a specific configuration will display this information in the UI, enabling users to easily diagnose why jobs may not be running as expected.

Concurrency Groups

Forgejo Actions now supports the concurrency block in order to either permit or restrict concurrent execution of a Forgejo Actions workflow.

Dynamic Matrices & Runs-On

Forgejo Actions now supports matrix jobs and runs-on fields that are defined by earlier jobs in the workflow, allowing a workflow to apply custom logic to determine how and where its jobs will run. In this example, the define-matrix job would be a placeholder for custom logic, such as inspecting the changes in a pull request, to determine which jobs to spawn in the runs-on-dynamic-matrix job.

Security features

Validation of the authorized_keys file

When Forgejo is configured to use the authorized_keys file for SSH, upon startup this file will be read and its contents will be validated. If any unexpected keys are found in the file, Forgejo will terminate its startup in order to signal to the server administrator that a security risk is present that must be addressed.

Stateless CSRF protection

CSRF attacks are now prevented via a stateless method that uses browser fetch metadata request headers. Because it is stateless, you can now submit work on tabs that have been open for more than 24 hours. Forgejo instances that are hosted on a subpath are no longer protected against CSRF attacks from services that are hosted on the same origin (same scheme, host/domain and port). Anti-CSRF tokens are therefore no longer used and the CSRF_COOKIE_HTTP_ONLY option was removed.

Database improvements

Goodbye “Pull requests -1” caused by DB Deadlocks

Forgejo maintains statistics on repos, labels, and milestones which have been subject to internal deadlocks when being updated, often surfacing to the user as an indicator that they have “-1” pull requests on a repository. Following scalability work on these calculations, the number of database deadlocks resulting in incorrect statistics or even interrupting merge operations has been effectively reduced to zero.

Database foreign keys

Forgejo now implements a limited number of foreign keys in the database. About 5% of the cross-table references that Forgejo uses are protected from data inconsistencies by database foreign keys, which will be created automatically while upgrading to Forgejo 14.

Records that previously should have been deleted due to removal of their relationship are considered to be data inconsistencies, and may prevent the creation of a foreign key. For example, if an access token exists in the access table which references a user who was previously deleted, this record should have been removed when the user was deleted but this was never guaranteed by the database due to the lack of foreign keys.

Forgejo will automatically identify these data inconsistencies and correct them to create the necessary foreign keys, deleting the inconsistent records. This will not have any functional impact to your Forgejo instance.

The affected tables and the number of records are reported in the logs during the database migration if any are found.

Distributed database queries

In Forgejo v12 a new feature was introduced to distribute read queries over multiple databases. During testing conducted by Codeberg it was found that this behavior was almost never used. This has been fixed in this release and distributing read queries over multiple databases is now effective. We should note that this is not a high availability feature, there’s no mechanism to stop sending queries to a database that is offline.

Release schedule and Long Term Support

Based on the release schedule, major releases are published every three months. Patch releases are published more frequently, depending on the severity of the bug or security fixes they contain. Forgejo v14.0 is a non-LTS release that replaces the previous non-LTS release, Forgejo v13.0. It will be supported until 16 April 2026.

14.0-test daily releases

Releases are built daily from the latest changes found in the v14.0/forgejo development branch. They are deployed to the https://v14.next.forgejo.org instance for manual verification in case a bug fix is of particular interest ahead of the next patch release. It can also be installed locally with:

• OCI images: root and rootless
• Binaries

Their names are staying the same but they are replaced by new builds every day.

Get Forgejo v14.0

See the download page for instructions on how to install Forgejo, and read the release notes for more information.

Upgrading

Carefully read the breaking bug fixes section of the release notes.

The actual upgrade process is as simple as replacing the binary or container image with the corresponding Forgejo binary or container image. If you’re using the container images, you can use the 14.0 tag tag to stay up to date with the latest 14.0.Y patch release automatically.

Make sure to check the Forgejo upgrade documentation for recommendations on how to properly backup your instance before the upgrade.

Contribute to Forgejo

If you have any feedback or suggestions for Forgejo do not hold back, it is also your project. Open an issue in the issue tracker for feature requests or bug reports, reach out on the Fediverse, or drop into the Matrix space (main chat room) and say hi!

Donate

Forgejo is proud to be funded transparently. Additionally, it accept donations through Liberapay. It is also possible to donate to Codeberg e.V. in case the Liberapay option does not work out for you, and part of the funding is used to compensate for work on Forgejo.

However, the Liberapay team allows for money to go directly to developers without a round-trip to Codeberg. Additionally, Liberapay allows for a steady and reliable funding stream next to other options, a crucial aspect for the project. The distribution of funds through Liberapay is transparently controlled using the decision-making process, and Forgejo contributors are encouraged to consider applying to benefit from this funding opportunity.

Thank you for using Forgejo and considering a donation, in case your financial situation allows you to.

Original source

Forgejo v13.0 release notes

Forgejo v13.0 was released on 16 October 2025. You will find a short selection of the changes it introduces below and a complete list in the release notes.

A dedicated test instance is available to try it out. Before upgrading it is strongly recommended to make a full backup as explained in the upgrade guide and carefully read all breaking changes from the release notes. If in doubt, do not hesitate to ask for help in the chat room.

Summary

Content moderation is one of the main roadblocks for federation. A first step is now available to users and admins. It was completed while ActivityPub related pull requests were worked on in parallel and merged.

Security was improved under the hood for Forgejo Actions secrets now using a more secure module introduced in 2024 and already in use for TOTP secrets since Forgejo v10. In addition it is now possible to require 2FA instance wide.

Forgejo Actions usability was improved with access to all run attempts of each workflow: they were stored but not available via the web UI. The workflow files are now statically checked, for early detection of errors such as the usage of a wrong context in an expression like ${{ forgejo.server_url }}.

Reporting abusive content

Moderation on public Forgejo instance is a hard and time-consuming task as there are no builtin tools to help with this. Although self-moderation allows users with no elevated privileges to block abusive behavior, it is sometime necessary to get an instance administrator involved.

It is now possible to report users, organizations, repositories, issues, pull request or comments that should be looked at by instance administrators. A category and an explanation of why the content is problematic must be attached.

Those reports are then made available in the admin interface.

When multiple reports are submitted for the same content, they are grouped and the counter from the right side shows how many open reports are linked to that content. Clicking on this counter will open a details page where the full details of all grouped reports can be viewed.

Migration from Pagure

Repositories from Pagure can be migrated to Forgejo. It can be used, for instance, in the context of the transition of Fedora from Pagure to Forgejo that was decided in December 2024.

Configurable global 2FA enforcement

The [security].GLOBAL_TWO_FACTOR_REQUIREMENT setting was added to require two factor authentication (TOTP, etc.) for either all users or instance administrators.

Avatar image privacy

Uploaded avatar images can sometimes contain unexpected metadata such as the location where the image was created, or the device the image was created with, stored in a format called EXIF. Forgejo now removes EXIF data when custom user and repository images are uploaded in order to reduce the risk of personally identifiable information being leaked unexpectedly.

A new CLI subcommand forgejo doctor avatar-strip-exif can be used to strip EXIF information from all existing avatars; we recommend that administrators run this command once after upgrade in order to minimize this risk for existing stored files.

View previous Forgejo Actions attempts

It is now possible to view previous logs for Actions runs that have been retried.

Static check of Actions workflow files

Forgejo Actions workflows are statically verified in the web UI for common errors such as using an incorrect context (e.g. ${{ badcontext.FORGEJO_REPOSITORY }}) or a typo in a required keyword (e.g. ruins-on: instead of runs-on: ). It is reported in the action page and the web page that displays the file in the repository.

This is in addition to similar tooling provided by the Forgejo runner itself and helps detect errors as soon as possible.

Show CI status on force push

When force-pushing to a pull request, a line is added to the conversation view to compare the two. However, the CI status of commits in such line was hidden behind an additional click. It is now displayed next to the SHA of each commit, similar to commits from normal pushes.

Markdown editor bold & italic keyboard shortcuts

Keyboard shortcuts were implemented in the markdown editor for formatting features Bold and Italic so that they can be used more quickly. Behavior of using shortcuts is the same as clicking the buttons.

Timestamps on release attachments

The time when a release attachment was uploaded is now shown among other information about it.

Tags are shown in commit lists

When viewing repository’s commits, tags are now shown next to the commits they are associated with.

Logger mode settings LOGGER__MODE

The logger settings were renamed from logger..MODE to LOGGER__MODE to help setting them with environment variables when using a container image. For instance:

docker run --rm -e FORGEJO__log__LOGGER_ACCESS_MODE=file ... codeberg.org/forgejo/forgejo:13

Configuration files using logger..MODE are still supported but they are no longer documented. This change is specially useful when the name of the setting goes through various transformations that convert lowercase to uppercase, such as the Forgejo helm chart.

Release schedule and Long Term Support

The time based release schedule was established to publish a release every three months. Patch releases will be published more frequently, depending on the severity of the bug or security fixes they contain.

Version | Release date | End Of Life
11.0 (LTS) | 16 April 2025 | 16 July 2026
13.0 | 16 October 2025 | 15 January 2026
14.0 | 15 January 2026 | 16 April 2026

13.0-test daily releases

Releases are built daily from the latest changes found in the v13.0/forgejo development branch. They are deployed to the https://v13.next.forgejo.org instance for manual verification in case a bug fix is of particular interest ahead of the next patch release. It can also be installed locally with:

• OCI images: root and rootless
• Binaries

Their names are staying the same but they are replaced by new builds every day.

Get Forgejo v13.0

See the download page for instructions on how to install Forgejo, and read the release notes for more information.

Upgrading

Carefully read the breaking bug fixes section of the release notes.

The actual upgrade process is as simple as replacing the binary or container image with the corresponding Forgejo binary or container image. If you’re using the container images, you can use the 13.0 tag tag to stay up to date with the latest 13.0.Y patch release automatically.

Make sure to check the Forgejo upgrade documentation for recommendations on how to properly backup your instance before the upgrade.

Contribute to Forgejo

If you have any feedback or suggestions for Forgejo do not hold back, it is also your project. Open an issue in the issue tracker for feature requests or bug reports, reach out on the Fediverse, or drop into the Matrix space (main chat room) and say hi!

Donate

Forgejo is proud to be funded transparently. Additionally, it accept donations through Liberapay. It is also possible to donate to Codeberg e.V. in case the Liberapay option does not work out for you, and part of the funding is used to compensate for work on Forgejo.

However, the Liberapay team allows for money to go directly to developers without a round-trip to Codeberg. Additionally, Liberapay allows for a steady and reliable funding stream next to other options, a crucial aspect for the project. The distribution of funds through Liberapay is transparently controlled using the decision-making process, and Forgejo contributors are encouraged to consider applying to benefit from this funding opportunity.

Thank you for using Forgejo and considering a donation, in case your financial situation allows you to.

Original source