Forgejo v15.0 Release: Enhanced Security and LTS Support

On April 16, 2026, the landscape of self-hosted DevOps reached a significant milestone with the official Forgejo v15.0 release. This launch represents far more than a simple version bump; it is the 100th release of the Forgejo project and a definitive Long Term Support (LTS) anchor that secures the platform’s future through July 2027. Since its divergence as a “hard fork” from Gitea in 2024, Forgejo has aggressively pursued a mission of radical transparency and community-governed sovereignty. Version 15.0 is the culmination of that journey, offering a hardened, enterprise-ready forge that prioritizes granular security and high-velocity developer workflows.

The Forgejo v15.0 release arrives at a time when the “supply chain attack” is no longer a theoretical threat but a daily reality for software maintainers. By introducing ephemeral runners and repository-specific access tokens, Forgejo v15.0 provides administrators with the architectural tools necessary to implement a true Zero Trust environment. This editorial deep-dives into the technical intricacies of these new features and explains why this LTS version is a mandatory upgrade for organizations seeking a 100% Free Software stack without sacrificing the power of modern CI/CD.

The Security Paradigm Shift: Repository-Specific Access Tokens

One of the most requested features in the history of the project has finally reached maturity. Previously, personal access tokens (PATs) in many Git forges—including Forgejo’s predecessors—often acted as “golden keys.” While they could be scoped to broad categories like “repo” or “user,” they typically granted those permissions across an account’s entire portfolio. For an administrator or an automated bot, this was a security liability; a leaked token meant every repository under that account was compromised.

In the Forgejo v15.0 release, the introduction of Repository-Specific Access Tokens fundamentally changes the API security model. Administrators can now generate tokens that are strictly tethered to a whitelist of specific repositories. This follows the Principle of Least Privilege (PoLP) by ensuring that even if a token is exfiltrated from a CI/CD environment, its “blast radius” is contained to the defined targets.

Technical Constraints and Scoping

Forgejo v15.0 enforces strict logic on these new tokens to prevent privilege escalation:

• Permission Isolation: Users can select specific scopes such as read:repository, write:repository, read:issue, and write:issue.
• Administrative Lockdown: These tokens cannot be used to perform high-level administrative tasks, such as transferring ownership, adding new collaborators, or changing a repository from private to public—even if the token creator has those rights.
• Public Access Logic: By default, these tokens maintain read-only access to public repositories to ensure basic API functionality remains intact while strictly guarding private resources.

Forgejo Actions and the Rise of Ephemeral Runners

Continuous Integration (CI) is the heart of the modern development cycle, but persistent runners are often the weakest link. In traditional setups, a runner is a long-lived process or daemon that stays registered with the forge. If a job is compromised, an attacker can potentially persist within that runner’s environment, waiting to infect subsequent builds or exfiltrate credentials stored on the disk.

The Forgejo v15.0 release addresses this by introducing Ephemeral Runners. These runners are designed for a “one-and-done” lifecycle. Utilizing the new --one-job command, a runner can be spun up, execute a single task, and immediately deregister itself from the Forgejo instance. This creates a clean slate for every build and virtually eliminates the risk of cross-job contamination.

Autoscaling with KEDA and Kubernetes

To support these ephemeral environments, Forgejo v15.0 has refined its integration with KEDA (Kubernetes-based Event Driven Autoscaling). A new “Pending Tasks” API allows external orchestrators to query the exact number of jobs waiting in the queue at the repository, organization, or global level. When a spike in pull requests occurs, KEDA can trigger the creation of a fleet of ephemeral pods. Once the jobs are finished, the pods terminate, scaling the infrastructure back to zero and significantly reducing cloud compute costs.

OpenID Connect (OIDC) Integration

Security within Actions is further bolstered by native OIDC support. Workflows can now request a cryptographically signed JSON Web Token (JWT) from the Forgejo instance. This allows workflows to authenticate with third-party services—such as AWS, Google Cloud, or HashiCorp Vault—without storing long-lived secrets in the Forgejo database. The trust relationship is established server-to-server, ensuring that identity is verified dynamically for every job execution.

Advanced Git Notes: A First-Class UI Citizen

While Git notes have existed in the Git protocol for years, they have largely been relegated to the command line. Most developers use them to attach metadata or external build information to a commit without changing the commit’s SHA-1 hash. However, the lack of visibility in web interfaces has limited their adoption for human-centric workflows.

In the Forgejo v15.0 release, Git Notes receive a major UI overhaul. Developers can now view, add, edit, and even cancel note modifications directly within the single-commit view of a pull request. This turns Git notes into a powerful tool for asynchronous code review and audit logging. For example, a security auditor can attach a signed note to a commit after a manual review, and that note will remain persistently visible to all contributors without cluttering the main commit message.

Streamlining the Developer Experience (DX)

Beyond the “under-the-hood” security improvements, v15.0 introduces several refinements aimed at reducing the daily friction of repository management. The goal of the “Ninja Editor” and the Forgejo community is to ensure the software “just works” so developers can focus on code rather than infrastructure.

Auto-Linking Container Images

Managing a container registry often involves manual steps to link an uploaded image to its source repository. Forgejo v15.0 automates this through two primary methods:

1. OCI Label Detection: If a container is pushed with the org.opencontainers.image.source label pointing to a Forgejo repository URL, the platform automatically creates the link.
2. Naming Conventions: Containers named using the {owner}/{repo} format are intelligently associated with the corresponding repository upon initial creation.

Enhanced Issue Filtering and Responsive Design

The web interface has been optimized for high-density information environments. The issue filtering system now supports advanced boolean operators (+term for mandatory inclusion, -term for exclusion) and exact phrase matching. Furthermore, the UI team has removed the requirement to hold the “Alt” key for certain multi-select filtering operations, making the interface significantly more accessible for mobile and touch-screen users. The releases list has also been completely reworked to be fully responsive, ensuring that project managers can track deployment statuses from any device.

The Milestone: 100th Release and Community Sovereignty

The Forgejo v15.0 release is a landmark moment. Reaching 100 releases is a testament to the project’s velocity and the health of its contributor base. Unlike centralized competitors, Forgejo is governed by Codeberg e.V., a non-profit organization dedicated to Free Software. This governance model ensures that Forgejo remains immune to corporate “Open Core” shifts, where critical security features are often locked behind a paywall.

Since the 2024 “hard fork,” Forgejo has successfully differentiated itself through:

• Comprehensive E2E Testing: Every release undergoes rigorous browser-based and upgrade testing to prevent the regressions common in faster-moving forges.
• Radical Localization: Using the community-driven Weblate platform, Forgejo v15.0 is available in dozens of languages with nearly 100% coverage.
• Decentralized Vision: Ongoing work on federation (ActivityPub) promises a future where Forgejo instances can communicate across the “Fediverse,” allowing contributors on Codeberg to interact with those on private enterprise instances seamlessly.

Critical Upgrade Notes for Administrators

While the upgrade to v15.0 is designed to be straightforward, there are several breaking changes that administrators must address:

• Cookie Branding: In an effort to further distance the project from its roots, default cookie names have been stripped of legacy branding. Unless manually overridden in the app.ini configuration, all users will be required to re-login after the upgrade.
• Docker Rootless Config: For those running rootless container images, the default configuration file location has been standardized. Users should verify their volume mappings against the updated v15.0 documentation to ensure persistent data is correctly detected.
• LTS Transition: Version 15.0 replaces v11.0 as the primary LTS branch. Support for v11.0 will officially end in July 2026, giving administrators a three-month window to perform a validated migration.

Conclusion: The New Gold Standard for Open Source Forges

The Forgejo v15.0 release is more than just a software update; it is a declaration of independence. By providing an LTS version that rivals the feature set of GitHub Enterprise while remaining firmly rooted in Free Software principles, Forgejo has established itself as the premier choice for sovereign code hosting. From the granular control of repository-specific tokens to the scalable power of ephemeral runners, v15.0 offers a mature, secure, and highly efficient environment for the next decade of software development. As we look toward the 2027 support horizon, it is clear that Forgejo isn’t just following the industry—it is forging the future.