To export a GitLab project, a Maintainer or Owner opens Settings, General, Advanced and presses Export project, then downloads the .tar.gz archive from the email link. Keep the official export instructions open while you work.
Who runs it
Who can run it: A project Maintainer or Owner runs it. To include inherited members as direct project members, the person must have the Owner role for the exported project's group or administrator access to the instance. GitLab's file-export page lists Free, Premium and Ultimate, on GitLab.com, Self-Managed and Dedicated. In the GitLab pages we read on 7 October 2026, we found no stated generation time.
On Self-Managed and Dedicated, GitLab says administrators must enable file exports on the source instance. If you cannot find Export project, ask whoever runs your GitLab instance whether that is switched on.
Before you start, read How to export your Google Workspace data and How to export your HubSpot CRM data.
The steps
Use the Search or go to... box in the top bar to find the project, then open Settings > General in the left sidebar. Expand Advanced and press Export project. Use the link in the email, or refresh the page and press Download export, and do it as soon as the email arrives. Keep the file unchanged on your computer, then repeat for each project you need. GitLab limits exports to 6 projects per minute and downloads to 1 per project per minute.
GitLab says a worker deletes export files every 24 hours, so download as soon as the email arrives. If the file or link is gone, run the export again.
If an export fails, GitLab retries it until the maximum number of retries is reached and then marks the export as failed. For GitLab.com, GitLab suggests that you try the export during the weekend when less load exists on the instance.
What you get, and what it leaves out
Inside you'll find the project and wiki repositories, uploads, and issues with their comments and events. Merge requests come with diffs and comments, but GitLab says only the latest diff is preserved. You also get commit comments, labels, milestones, snippets, releases, time tracking, design data and Git LFS objects, with the records in NDJSON.
It doesn't have CI/CD job traces and artifacts, CI/CD variables, pipeline triggers, packages, container registry images, webhooks or encrypted tokens. GitLab also lists secure files and deploy keys allowed to push to protected branches as not exported. GitLab says not all items are exported, and that you should not use project export files to back up your data.
Check the archive on your computer before you upload
The GitLab .tar.gz archive stays on your computer. Unpack a copy and check it against the list below before you prepare anything.
- Extract each
.tar.gzand confirm that it unpacks. GitLab says the records inside are in NDJSON format. - Open
project_members.ndjsonand look for the people you expect on the project. GitLab says you can make sure that all members were exported by checking the project_members.ndjson file. - Compare the number of issues and merge requests the project shows with the records in the matching NDJSON files. This comparison is our suggestion.
- Write down what GitLab lists as not exported, and tell us if the project depends on any of it, such as packages or CI/CD variables.
- Merge requests carry only their latest diff. Note which merge requests you expect to review in full.
- Write down the date and time of each export.
What to settle before anything leaves your computer
A GitLab archive holds source code, which is different from the email and contact tables the removal tool is built for. The current tool supports email and CRM-table modes. Before you prepare a package from a GitLab archive, ask us whether it is in scope. You, or whoever runs your systems, review flagged items on your own computer, and the original export stays there (how personal data is removed). These checks do not guarantee that all personal data has been removed.
Check whose code it is. Client-owned code, client production data and code under licences that do not allow this use are yours to set aside before you share anything.
GitLab's Subscription Agreement has the customer retain all right, title, and interest in and to Customer Content, and its API terms bar repeated or systematic bulk exporting of API data, except where permitted by applicable law. So your own export is where any package starts (why we ask for an export).
Code is only part of an engineering archive. Planning and notes usually live in a wiki or task tool, covered by the Confluence export guide and the Asana export guide.