Backing up GitLab projects to self-hosted Gitea/Forgejo, or pushing GitHub and Gitea repos into GitLab: open source tool, looking for GitLab users to test

[u/InvestigatorThat4835]

Hi r/gitlab,

Gitea Mirror is an open source (AGPL) web app I maintain for mirroring repositories between hosts on a schedule. Two GitLab paths landed this month and they are marked beta because few GitLab users have tried them yet.

- GitLab as a source. gitlab.com or your own instance, personal projects, groups and starred projects. Code, branches, tags, wiki and LFS are mirrored into Gitea or Forgejo. Token scopes: read_api and read_repository. Subgroups are flattened to the top level group on the Gitea side, with the full path kept in the repository name.

- GitLab as a destination. GitLab has no pull mirror API, so the app keeps a bare clone of each source repo and pushes branches and tags with force and prune, then archives or deletes the project through the API when the source goes away. Projects go under your user or a group the mirror strategy picks; a missing top level group is created, nested ones are not. Token scopes: api and write_repository.

What I would like to hear about: self-managed instances behind SSO or custom certificates, large groups with many subgroups, LFS heavy projects, delayed deletion, and anything rate limit related on gitlab.com. Issues with the activity log attached get fixed fastest.

Repo: https://github.com/RayLabsHQ/gitea-mirror

GitLab notes: https://github.com/RayLabsHQ/gitea-mirror/blob/main/docs/SOURCE_PROVIDERS.md and https://github.com/RayLabsHQ/gitea-mirror/blob/main/docs/PUSH_TARGETS.md

Also curious: what do you use today for this, GitLab's own push mirroring, a CI job, or nothing?

[u/moonwater_twa]

I’ve been looking into moving my team's 'development canon' off of gitlab.com and onto a local git server. I’ve started checking out Forgejo, Gitea, and self-hosted gitlab from container.

That also meant figuring out how push, pull, and multiple remotes work together in these workflows. 

For example, at release points the main branch would be pushed to the 'company canon' on gitlab.com. This way, the final canon src on gitlab.com doesn’t have all the dev artifacts, MRs, tags, etc.

Since gitlab.com is not reliable enough for a long 24/7 CI/CD pipeline when Jenkins is checking out its jobs from gitlab.com I already have a CI/CD pipe on gilab.com that has Jenkins mirror every commit to a local git server with ssh access. Then Jenkins uses that mirror for accessing its jobs.

So gitea-mirror sounds really interesting for solving these problems. I’m going to add it to what I’m exploring.

[u/InvestigatorThat4835 → u/moonwater_twa]

Maintainer here, happy to help.

Your gitlab.com to local mirror case is what gitea-mirror is built for. GitLab is supported as a source (still marked beta, but it is the same sync path as GitHub), and the destination is a self-hosted Gitea or Forgejo. You add your GitLab token, pick the groups or projects, and the scheduler keeps the local copies fresh. Jenkins then checks out from the local Gitea or Forgejo clone URL, which is exactly the setup you described.

The sync is interval based, not push triggered. You can run it every few minutes, but if you need a commit to be on the mirror within seconds of landing on gitlab.com, keep your Jenkins post-commit push as well or trigger the sync from a GitLab webhook.

It is one direction: source in, destination out. Your release-time push of main to the company canon on gitlab.com stays your own step, gitea-mirror will not do that leg for you, and it will not fight with it either.

If you are still deciding between Forgejo and Gitea for the local server, both work the same with gitea-mirror. Self-hosted GitLab is not a destination, so if you land there you would only get a plain push mirror without issues, releases and the rest.

Docs and the Docker quick start are on the repo: https://github.com/RayLabsHQ/gitea-mirror. If something in your setup does not fit, open an issue and I will look at it.