Forgejo 17.0 Breaks CI Webhooks, Adds Job Summaries [2026]

Forgejo shipped version 17.0 on October 15, 2026, and the release carries a breaking change that will catch some self-hosted Git admins off guard. The new build swaps the old action_run webhook events for a richer workflow_run format, which means any script, bot, or dashboard built against Forgejo’s previous CI webhooks needs a rewrite before it upgrades. Multiple outlets, including Linuxiac and the German tech blog S-EDV, confirmed the release date and its scope within days of launch.

The timing matters. Forgejo has spent the past three years positioning itself as the community-run alternative to GitHub for teams that want to keep their code, their CI pipelines, and their automation off someone else’s cloud. Version 17.0 is a non-LTS release, supported only through January 28, 2027, but it packs enough CI, Git LFS, and migration tooling to function as a real upgrade decision point for any team weighing self-hosted software sovereignty against the convenience of a managed forge.

Google · Preferred Sources

Don't miss new tech stories on Google

Add TrendinTech once in the Google app and our stories appear in your news suggestions.

Add Now

What Forgejo 17.0 actually changes

Forgejo Actions, the project’s built-in continuous integration system, is the centerpiece of this release. Version 17.0 adds job summaries that render as Markdown inside the Actions interface, a new API for restarting completed workflow runs or individual jobs without re-triggering the whole pipeline, improved retrieval and filtering of job logs, and webhooks that report status changes at the individual job level rather than only at the workflow level. Those four changes, confirmed across multiple sources tracking the release, turn Forgejo Actions from a bare-bones CI runner into something closer to feature parity with the CI dashboards teams are used to on hosted platforms.

The job-summary feature depends on Forgejo Runner 13.2 or newer. Teams running an older runner version won’t see summaries render, so the runner upgrade is effectively mandatory alongside the server upgrade, not optional. That’s a smaller lift than the webhook migration, but it’s one more item on the checklist before a production instance moves to 17.0.

The webhook break: why action_run is going away

The headline risk in this release is the replacement of the action_run webhook event with the new workflow_run event. Anyone who built a Slack notifier, a status dashboard, or an internal deployment gate against Forgejo’s older webhook payloads will need to update that integration, because the event headers, the event type itself, and the payload’s action fields all changed shape. Completion semantics changed too: a workflow_run webhook now fires only after every job inside that workflow run has finished, rather than reporting partial completion as jobs wrap up individually.

That’s a deliberate trade-off. The old action_run events were cheaper to build against because they fired early and often, but they left integrators guessing about whether a workflow was actually done or just one job into a longer run. The new model is more accurate and more consistent with how GitHub and GitLab structure their own workflow-completion webhooks, which should make third-party migration from those platforms easier going forward. It does mean every existing webhook consumer is broken until someone updates it.

Git LFS, repository migration, and the smaller features

Beyond CI, Forgejo 17.0 improves handling of Git Large File Storage, the extension that lets Git repositories store large binary files without bloating the core repository history. The release coverage describes better navigation and file management inside the LFS interface, improved handling of LFS pointer files, and the ability for users to trace which commits reference a particular LFS-tracked file. None of that is flashy, but for teams storing build artifacts, design files, or datasets alongside source code, LFS tooling that doesn’t fight the user is the difference between adopting Forgejo seriously and treating it as a toy.

Repository migration also gets attention in this cycle, with improvements aimed at teams moving codebases onto Forgejo rather than starting from scratch. Combined with the project’s broader push on organization-management features, such as bulk invitations and clearer repository funding links, the release reads less like a feature drop and more like a maturity pass: the kind of release aimed at teams deciding whether Forgejo is ready to host production work, not just side projects.

Where Forgejo sits among self-hosted Git platforms

Forgejo is a community-driven fork of Gitea, the lightweight Git forge software that itself positions as a self-hosted alternative to GitHub. The fork gives Forgejo an independent release cadence and governance separate from Gitea’s commercial backers, and the project publishes its release records through Codeberg, the nonprofit code-hosting service that also runs on Forgejo’s own software. That relationship, project built on the fork it maintains, hosted by a nonprofit that uses it in production, is part of why Forgejo has become a reference point for teams wary of concentrating their code history, issue trackers, and CI pipelines inside a single commercial vendor.

That wariness isn’t hypothetical. Centralization concerns have pushed some organizations toward alternatives even as the dominant platforms keep growing: Cloudflare recently crossed 10 million developers on its own platform, a reminder of how much weight sits on a small number of commercial infrastructure providers. Self-hosted forges like Forgejo exist precisely to give teams an exit ramp from that concentration, even if most will never need to use it.

Forgejo’s release cadence: LTS versus non-LTS tracks

Forgejo runs two release tracks in parallel, and understanding which one you’re on matters for anyone planning an upgrade. Forgejo 15.0, released April 16, 2026, is the long-term-support line; it’s what admins are advised to run if they want a release with the longest security-maintenance window. Forgejo 16.0 reached general availability on July 16, 2026, as a non-LTS release, and reporting on its support schedule places its planned end of support around October 29, 2026.

Forgejo 17.0 slots in as the newest non-LTS release, supported only through January 28, 2027. That’s a roughly three-and-a-half month support window, standard for Forgejo’s non-LTS cadence, and it means teams that adopt 17.0 now are signing up for another upgrade cycle relatively soon. Teams that prioritize stability over the newest CI features have reason to stay on the LTS track instead and wait for the next LTS release to inherit 17.0’s Actions and LFS improvements.

Release	Track	Release date	Support ends
Forgejo 15.0	LTS	April 16, 2026	July 15, 2027
Forgejo 16.0	Non-LTS	July 16, 2026	October 29, 2026
Forgejo 17.0	Non-LTS	October 15, 2026	January 28, 2027

Competitive context: Gitea, GitHub, GitLab, and Bitbucket

Forgejo’s closest relative, Gitea, moved through its own version jump this cycle too, with Gitea 28.0.0 landing in September 2026 carrying audit logging, stricter handling of malformed Git objects, improved SSH-key fingerprint display, and mandatory approval locks for pull requests originating from forks. Gitea’s release coverage also describes the project as carrying “leadership and commercial support from CommitGo,” underlining the governance split between Gitea’s commercially backed roadmap and Forgejo’s community-run one. For teams picking between the two forks, that governance difference is often as decisive as any individual feature.

Zoom out to the broader version-control market and the scale gap is enormous. According to the 2021 Stack Overflow Developer Survey, 93.43% of developers reported using Git as their version-control system, and the 2022 edition of the same survey found GitHub used by 55.93% of respondents for professional work, with GitLab at 28.9% and Bitbucket at 18.42% for the same professional-use category. GitHub’s personal-use share was even higher, at 87.02% in that same 2022 survey. Self-hosted forges like Forgejo and Gitea are a rounding error against those numbers today, but they serve a specific, durable niche: regulated industries, government agencies, and privacy-conscious teams that need code hosting they fully control.

Platform	Professional use share	Survey year	Hosting model
GitHub	55.93%	2022 (Stack Overflow Developer Survey)	Hosted / self-hosted (Enterprise)
GitLab	28.9%	2022 (Stack Overflow Developer Survey)	Hosted / self-hosted
Bitbucket	18.42%	2022 (Stack Overflow Developer Survey)	Hosted / self-hosted (Data Center)
Forgejo / Gitea	Not separately tracked	n/a	Self-hosted only

Migrating off Bitbucket Data Center

One detail in the 17.0 release coverage stands out for a specific audience: teams migrating off Atlassian’s Bitbucket Data Center product. Forgejo’s release notes describe improved migration tooling aimed at transferring repositories, pull requests, reviews, comments, and discussion threads out of Bitbucket Data Center and into a Forgejo instance. That’s a narrow but meaningful signal. Bitbucket Data Center is Atlassian’s self-hosted enterprise tier, and organizations running it are, almost by definition, already committed to self-hosting their code. A smoother migration path from one self-hosted platform to another lowers the switching cost for exactly the customers Forgejo is trying to win: teams that already value control over their Git infrastructure and are shopping for a better-maintained option.

Why open-source CI tooling keeps gaining ground

Forgejo’s push to deepen its own Actions system lands amid a broader pattern of infrastructure vendors open-sourcing pieces of their stack rather than keeping everything proprietary. NVIDIA opened the source on several of its AI-factory GPU tools this year, a move covered in our report on NVIDIA’s open-sourcing of Run:ai and related GPU tooling, and retailer Inditex followed a similar playbook by publishing three of its internal developer tools to GitHub. Even Microsoft has leaned into the trend, as detailed in our coverage of Microsoft opening the source on its Scope coding-agent testing framework. None of those projects compete directly with Forgejo, but together they describe an industry where “open source” is no longer a niche preference, it’s a credible go-to-market strategy even for companies that could just as easily keep their tools closed.

That broader shift cuts both ways for Forgejo. On one hand, it validates the idea that developer tooling doesn’t have to be owned by a single vendor to be trustworthy or well-maintained. On the other, it means Forgejo now competes for attention not just against GitHub and GitLab, but against a growing field of open-source developer infrastructure projects, all vying for the same pool of engineering teams that care about where their tools come from.

The risk of depending on any single platform, hosted or not

Self-hosting removes dependence on a third-party vendor’s uptime and pricing decisions, but it doesn’t remove platform risk entirely, it just relocates it. Our coverage of Deno’s runtime team joining Cloudflare as the standalone Deno project winds down is a reminder that even well-funded, well-regarded open-source projects can reach a point where their maintaining organization folds the project into something else. Forgejo’s community governance model, spread across Codeberg and a wider volunteer base rather than concentrated in one company, is partly a hedge against that exact failure mode. Whether it’s a durable hedge is untested; Forgejo itself is only a few years removed from its own founding fork of Gitea, and long-term governance resilience is the kind of thing that’s only provable in hindsight.

What this means for engineering teams evaluating self-hosted Git

For a team currently running Forgejo in production, the practical to-do list from this release is short but not trivial: audit every webhook consumer that listens for action_run events and update it to handle workflow_run payloads before upgrading, confirm Forgejo Runner is at version 13.2 or newer to get job summaries working, and decide whether to ride the non-LTS 17.0 line for the newest CI features or stay on the 15.0 LTS track for a longer support window. None of that is exotic engineering work, but skipping the webhook audit is the kind of mistake that silently breaks a deployment pipeline’s notification chain and isn’t noticed until someone asks why Slack has gone quiet.

For teams not yet on a self-hosted forge, 17.0’s maturity signals, deeper Actions APIs, better LFS handling, and a real Bitbucket Data Center migration path, make a stronger case for evaluation than Forgejo could make a year or two ago. The gap between what a self-hosted CI system can do and what a hosted one offers is narrowing release by release, even if it hasn’t closed.

Predictions: where Forgejo and self-hosted Git go next

Expect Forgejo’s next LTS release to inherit most of 17.0’s Actions and LFS improvements once the non-LTS line has had time to shake out bugs in production.
The webhook breaking change will likely push more third-party integration maintainers to build against Forgejo’s API more defensively, version-pinning payload parsing rather than assuming event shapes are stable long-term.
Bitbucket Data Center migration tooling will keep improving across the self-hosted forge ecosystem as Atlassian’s own roadmap decisions continue to push enterprise self-hosters to shop for alternatives.
Gitea and Forgejo’s parallel but separate release cadences will keep diverging gradually, as commercial backing on one side and community governance on the other pull feature priorities in different directions.
Expect continued growth in open-source developer tooling generally, as more infrastructure vendors treat open-sourcing internal tools as a credibility and recruiting strategy rather than a cost to be contained.

How Forgejo 17.0 compares to the last two releases

Looking at the last three Forgejo release cycles side by side shows a project steadily filling out its CI and storage story rather than chasing any single flagship feature. Forgejo 15.0 introduced ephemeral runner registrations and single-job-restricted runner credentials, both aimed at making CI runners safer to autoscale without leaving reusable long-lived credentials sitting around. Forgejo 16.0’s cycle was comparatively quieter from a feature standpoint based on available reporting, serving mainly as a maintenance line before 17.0’s larger CI and LFS push. Forgejo 17.0 now adds the job-summary, webhook, and migration features described above, while explicitly breaking backward compatibility with the webhook format the two prior releases used.

That pattern, security and safety features in one release, quieter maintenance in the next, a larger capability jump in the third, is fairly typical of how smaller open-source infrastructure projects manage limited maintainer bandwidth. It also means teams that skip a release or two when upgrading should expect to absorb multiple generations of change at once, which raises the stakes of the webhook migration specifically for anyone who has been running 15.0 or 16.0 without closely tracking the project’s release notes.

Frequently asked questions

When was Forgejo 17.0 released?
Forgejo 17.0.0 was released on October 15, 2026, as a non-LTS release.

How long will Forgejo 17.0 be supported?
Reporting on the release places Forgejo 17.0’s support window through January 28, 2027, consistent with the project’s standard non-LTS support length.

What is the breaking change in Forgejo 17.0?
Forgejo 17.0 replaces the action_run webhook event with a new workflow_run event. The event headers, event type, and payload action fields all changed, and workflow-completion notifications now fire only after every job in the workflow run finishes, so existing webhook integrations need to be updated before upgrading.

Do I need to upgrade Forgejo Runner for this release?
Yes. The new Markdown job-summary feature requires Forgejo Runner version 13.2 or newer; older runner versions won’t display summaries.

Is Forgejo 17.0 an LTS release?
No. Forgejo 17.0 is a non-LTS release. Forgejo 15.0, released April 16, 2026, remains the current long-term-support line, with its support window reported to run through July 15, 2027.

What is the relationship between Forgejo and Gitea?
Forgejo is a community-driven fork of Gitea. The two projects now run independent release cycles, with Gitea carrying commercial backing and support from CommitGo according to its release material, while Forgejo is maintained through community governance and publishes release records via Codeberg.

Can I migrate from Bitbucket Data Center to Forgejo?
Forgejo 17.0’s release coverage describes improved migration tooling for moving repositories, pull requests, reviews, comments, and discussion threads from Bitbucket Data Center into a Forgejo instance.

How popular is self-hosted Git compared to GitHub or GitLab?
Self-hosted forges remain a small slice of the overall market. The 2022 Stack Overflow Developer Survey found GitHub used professionally by 55.93% of respondents, GitLab by 28.9%, and Bitbucket by 18.42%, with self-hosted alternatives like Forgejo and Gitea not separately broken out in that data.