The forge is our new home.

News & Announcements Community Blog
1

Originally published at: The forge is our new home. – Fedora Community Blog

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.

5 Likes
Is https://pagure.io/fedora-packages-static the place where packages website is maintained?
2

Was quick-fedora-mirror missed in the migration? Perhaps it should be migrated to releng?

3

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.

1 Like
4

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.)

5

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?

6

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.

They are not.

(Also, let’s make it clear that this is strictly about the pagure.io instance of pagure, not the dist-git one.)

Right.

You should make new forks on the forge side and push any in progress
changes to those.

7

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 separate pagure.io and src.fedoraproject.org instances of Pagure.

(This is why we’re trying to stick to calling this instance “Fedora Forge”.)

8

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.

9

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.io was misnamed already because it conflated the platform with the purpose, whereas src.fpo was named by the purpose. Are we “keeping that tradition”?

1 Like
10

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.

1 Like
11

Maybe naming along the lines of “Fedora Community Forge” and “Fedora Packages Forge”?

1 Like
12

I want to migrate my three projects from Pagure to Forge, but I can’t find the “New migration” button.

  • Is the button disabled?
  • Also, is the “New repository” button disabled?
  • What is happening?
13

Migrations are done (and new repos created) at the organization level. You have to be on the front page for an organization, and you have to have sufficient rights to create repositories in that organization. In that case, you’ll see the “New repository” and “New migration” buttons on the right hand side under Settings.

14

I guess that’s an outcome of the naming here: I’d expect “our home” to be where I can migrate or put my Fedora related repos, but it’s really not. In particular, you cannot just migrate any pagure project.

If it’s not in an organization, the current recommendation seems to be to go “somewhere else”, e.g. codeberg, sourcehut or disroot if you prefer forgejo instances. (I’m currently moving some spec-tracking and copr-driving from github to codeberg; working fine so far.)

Also, fedorapeople is still around, but I don’t know about the timeline, and it’s not a full forge of course (just web space and (c)git).

15

Ah ok, I’m in 0 (zero) organizations, that’s why I can’t create repositories.

16

I guess that’s an outcome of the naming here: I’d expect “our home” to be where I can migrate or put my Fedora related repos, but it’s really not. In particular, you cannot just migrate any pagure project.

Yes, pretty much. We specifically didn’t want to be on the hook for running a generic forge (any more), because that comes with substantial moderation headaches and infrastructure cost. Fedora Forge is supposed to be for things with some kind of tangible Fedora connection.

Also, fedorapeople is still around, but I don’t know about the timeline, and it’s not a full forge of course (just web space and (c)git).

We had a huge bot flood on cgit last week. We were able to mitigate that with anubis and a tighter robots.txt , but I wouldn’t count on it being around forever; if the bots get around our current mitigations and we can’t find any others, we might have to turn it off.

17

Ah ok, I’m in 0 (zero) organizations, that’s why I can’t create repositories.

Yeah, that’d explain it. If the things you want to host are Fedora related, we can try and do something about that. What is it you wanted to move?

18

I have a question. I’m writing my last and only software that it’s intended to be used as part of the i3 Spin. Where should I host the code? I was aiming to use pagure, but if it’s going to die, should I use gitlab/github and use the fedora infra just for packaging?

19

Codeberg, the same people that make Forgejo.

But you are basically right, use any git host and then deploy to Fedora upon packaging.

First a Copr, then Fedora repos.

20

is https://pagure.io/fedora-packages-static (repo for https://packages.fedoraproject.org/) also supposed to be migrated to the new https://forge.fedoraproject.org/ forge ?

Asking this as I wanted to open an issue on the pagure repo but was unsure if I should because the repo seems to be inactive (no discussion on issues)