After a full year of preparation, the Community Linux Engineering (CLE) team is excited to announce that Fedora Forge, powered by Forgejo, is ready for use! We are proud of this modern Open Source platform and what it means for the future of Fedora Infrastructure. While pagure.io has been a vital part of our community for many years, the time has come to retire our homegrown forge and transition to this powerful new tool.
The final cutover is planned for Flock to Fedora 2026. We strongly encourage teams to migrate their projects well before the conference to ensure a smooth transition. The pagure.io migration is only the first step in a broader infrastructure modernization effort. By the 2027 Fedora 46 release, we plan to retire all remaining Pagure instances across the project, including the package source repositories on src.fedoraproject.org. Getting familiar with Fedora Forge now will help ensure your team is ready as the rest of the Fedora ecosystem transitions.
pagure.io users, it is time to migrate!
If you own a project at pagure.io, you must migrate out of it before June 2026. We’ve prepared a Migration Guide. If you’re unsure about what’s happening, please keep reading
A Focused Scope for Fedora Forge
Historically, the Fedora Project utilized pagure.io, which operated as a general-use public forge where Fedora repositories coexisted alongside personal projects, unrelated upstream software, and individual portfolios.
The Fedora Forge (powered by Forgejo) intentionally adopts a narrower scope. It is an internal piece of project infrastructure, explicitly provisioned to host the code, documentation, and tooling that directly build, manage, and govern the Fedora Project.
What belongs on Fedora Forge:
- Infrastructure and Operations: Configuration management, deployment scripts, or tooling used by the Fedora Infrastructure team.
- Release Engineering and Packaging: Tools, scripts, and templates used to build, compose, and distribute Fedora releases.
- Governance and Team Organization: Trackers, documentation, and collaborative spaces for official Fedora Teams, Special Interest Groups (SIGs), and Working Groups.
- Fedora-Specific Software: Software projects conceptualized and developed primarily to serve the Fedora community (e.g., Fedora Badges, Bodhi, fedmsg).
What does NOT belong:
- Personal Projects: Personal portfolios, dotfiles, or hobby projects not directly tied to Fedora are prohibited.
- General Upstream Development: If you are developing a general-purpose open-source application, its primary upstream development should be hosted elsewhere (e.g., GitHub, GitLab, Codeberg), even if it is packaged in Fedora. (Note: Foundational ecosystem tools like Koji or FreeIPA may qualify for exceptions via a ticket request ).
Why Migrate Early?
Migrating now avoids the “last-minute bottleneck” and gives your team time to adapt to the new resource limits outlined in the Usage Policy:
- Rewrite Automation: Refactor scripts and webhooks to use the new Forgejo API. Automated tools must respect rate limits and include descriptive user-agent strings.
- Test Your CI/CD: Native Forgejo Actions are available, but runners are a shared community resource. Builds are subject to a maximum timeout of 10 minutes per job.
- Clean Up Repositories: Repositories should ideally remain under 500MB. If your project requires large assets, you must use Git LFS (Large File Storage).
Feature Parity & Transparency
We are aware that Forgejo is not a 1:1 clone of Pagure. Most notably, private issues within public repositories are not currently supported in the same way. The CLE team is actively working with the upstream Forgejo community to bridge these functional gaps.
The Migration Roadmap
- Now – Pre-Flock: Proactive migrations. Please note that the Infrastructure team reserves the right to automatically archive repositories that have seen no activity for 6 months.
- Flock 2026: The final cutover.
- Post-Flock: pagure.io becomes a static, read-only historical archive.
Other Related Work
The Fedora Council currently has a draft usage policy under consideration, aimed at filling in the details of usage of the new forge instances inside the Fedora Project. Please watch for an additional article here on the Fedora Community Blog that starts the formal feedback process ahead of a Council vote on the policy.
Need help? For technical issues, please open a ticket on the Fedora Infrastructure Tracker or ask in the #fedora-admin Matrix channel.
Technical FAQ
How do authentication and team management work?
Authentication is fully integrated with the Fedora Account System (FAS) via OIDC. Team membership is directly mapped to FAS groups; if you are in a group, your permissions will automatically map to the corresponding Organization/Team on the Forge.
What happens to my API tokens and automation scripts?
Pagure API tokens will not migrate. You must generate new tokens within your account or organization settings on the new Forge and update your scripts to point to the Forgejo API.
Will my local git remote URLs break?
Yes. Once your repository is migrated, pushes to Pagure.io will be rejected. Update your remotes to the new instance:
git remote set-url origin https://forge.fedoraproject.org/<organization>/<your-project>.git
Are Issues and PRs migrating with full fidelity?
Yes. As outlined in the documentation, our tools port Pull Requests, Issues, and Issue Dependencies/Assignments. Pagure-specific tags will be mapped to Forgejo Labels.
Where do I go if my project’s migration fails?
The CLE team is monitoring the #fedora-forge Matrix channel. Reach out there for help with permission desyncs, missing refs, or pipeline breakages.
Was quick-fedora-mirror missed in the migration? Perhaps it should be migrated to releng?
I think this might be better under infra, since infra manages mirrors,
but I guess it could be either place… but yes, it should be migrated.
Are forks migrated along with the forked projects? I only have forks on pagure.io, and I’m wondering wether I should or should not migrate them myself.
(Also, let’s make it clear that this is strictly about the pagure.io instance of pagure, not the dist-git one.)
As the Forgejo instance will also be superseding package source forge, where should the generic package migrate to? From what I’ve read in the documentation available, a repo should migrate to an Forgejo organization (which is usually a SIG), does that mean all generic, non-SIG-covered packages should be requesting SIG adoption now?
They are not.
Right.
You should make new forks on the forge side and push any in progress
changes to those.
Packages won’t be moving to Fedora Forge -
forge.fedoraproject.org. They will move to a separate Forgejo instance dedicated to packages, just as we had separatepagure.ioandsrc.fedoraproject.orginstances of Pagure.(This is why we’re trying to stick to calling this instance “Fedora Forge”.)
Do you happen to know what is the reasoning for this separation also in the future? I had asked also before but I haven’t been able to find the answer.
Interesting. i never noticed that in the original discussion.
And no, “Fedora Forge” does not make this clear, on the contrary: We’ve been talking about Fedora’s new source forge all the time. So, “Fedora Forge” is not the new Fedora source forge.
In particular, the title “The forge is our new home” is even more misleading than I thought.
Note that
pagure.iowas misnamed already because it conflated the platform with the purpose, whereassrc.fpowas named by the purpose. Are we “keeping that tradition”?This was indeed a great cause for annoyance when trying to handle problems in the past “I cannot login to pagure” doesn’t provide enough info to help (which pagure instance?).
The intent back then was:
pagure.io → A general sources forge for any open source project
src.fedoraproject,.org → the sources for packages/flatpaks/etc that the fedoraproject distributes.
New world:
forge.fedoraproject.org → sources for fedoraproject adjacent activities. sigs, working groups, applications we run, releng, infra, scripts around packaging, etc.
new src.fedoraproject.org → instance that is just for rpms/flatpaks/etc.
There’s a lot of unknowns around the new src setup. I know the folks working on it are hoping to stand up a staging instance that can be used as a starting point for what we want to do. In particular tho, there are some who want to just as directly as we can migrate to forgejo there, and some who think it would be a good time to radically change the workflow and do things differently. I imagine this will be a topic of robust discussion at flock.
As for the reasoning for seperation there in the past it the two instances had two very different use cases. We 100% did NOT want packages src in the same place that any random person could make projects on. This would increase the security footprint a ton. Also, src.fedoraproject.org is not just a pagure instance, but it also has ‘pagure-dist-git’ deployed that changes the interface in the way that src needs/wants. (example: generic pagure projects don’t need/understand things like branch acls or release monitoring checks).
It may be that in the end we do decide to just merge them into one instance. I think thats more likely than with pagure, but also there’s definitely interface and other choices that may not make sense to impose on non rpms/flatpak packages.
Maybe naming along the lines of “Fedora Community Forge” and “Fedora Packages Forge”?