Platform discussion: the use of mirrors

General
1

Dear community,

we’d like to get your opinions about the use of the “mirrors” feature in the platform. Right now, this feature is enabled, meaning users can create repositories which are mirrors of repositories from other platforms (GitHub, GitLab, Codeberg, etc.).

The problem

We’re seeing continuous abusive usage of this functionality where some accounts have repos that only consist of mirrors. Some of these are also (very) large repos (100MB+, sometimes in the GB range). These repos don’t have much value in our view as they are either never being used or mainly act as pull rate limit alternatives if these are reached on the main platform.

Another possible reason might be to increase SEO for the repos at hand as they now appear multiple times in the web under different domains, making them possibly “more important” to search engines.

On top, the periodic sync of these repos cause quite some CPU activity on the server. While we’ve already applied custom patches to how these processed are handled compared to vanilla Forgejo (e.g. using renicing on these processed and limiting their overall CPU share), their need is still substantial at times. In some cases mirrors throw errors due to missing credentials or the upstream repo being gone, leaving a non-functional repo which doesn’t stop trying to sync in the given intervals (this could/should likely be fixed within Forgejo but is the current state as of right now).

Last, we have increased manual effort to contact these users, explain their (abusive) use and moderate the whole topic. We are aware that not everyone might see what their use of mirrors actually means and why it might be a problem. We also don’t wanna prejudge every new mirror as being potentially suspicious and created with bad intent. Additionally, we don’t wanna delete such repos without any warning or general communication with the owning users. These cases will always exist and increase over time with more users joining the platform. Right now we don’t think that we can (and want) keep up with this manual moderation effort for this specific topic but we’re open to suggestions on how to possibly handle it (see below).

How other platforms handle it

GitHub and GitLab don’t allow mirrors resp. don’t provide this feature in the first place. Codeberg has disabled it since quite some time as they also concluded that it was mainly used for abusive purposes and caused their repo storage size to increase for a almost no added value of these repos.

Poll

Besides written feedback, we’ve added a poll (closing in 2026-05-14) to gather feedback on the topic. If you vote for “Keep enabled”, we’d also love to hear how you think this can work on the practical side with respect to moderation and abuse control.

How to deal with the mirror feature moving forward?
  • Keep enabled
  • Disable it
0 voters
2

Back when it was supported on Codeberg, I did use it and I guess it was helpful right at the start, but it was rather unreliable and I ended up moving away from it anyway. Since pushing to multiple Git origins isn’t hard, I think it’s of limited utility. If it’s causing sysadmin headaches, I suspect it’s just not worth the effort.

3

I see the value in being able to migrate repositories to Codefloe (I used this myself.)

I can see some value in mirroring my own repositories (although I don’t currently need it nor use it.)

I can’t see any value (for me and for the Codefloe platform) in being able to mirror third party repositories.

Another thought: maybe it is an option to enable mirroring only for “paying customers”?

4

Don’t confuse the feature with the “migration” option, which allows you to import repos from other Forges. The repo is then just a normal repo and not a mirror. It allows for even more granularity and doesn’t lack anything compared to the “mirror” feature.

It would be interesting to understand the motivation better of those who use it, i.e. what their use case is for doing so.

Resource-wise this would make sense given how resource-heavy mirrors can be, depending on their size. However, implementing this custom gate would be substantial work in many areas of the source code and we aren’t really sure if its worth it. Maybe we should wait for explicit requests for this to be sure the effort might actually be worthwhile – but good idea overall, thanks for mentioning!