From GitLab to Forgejo.
Repository import is one part of a production migration, not the whole of it. This guide covers what moves on its own, what is rewritten, and what has to be replaced.
GitLab.com Free, 15 August 2026
What is happening, in GitLab's words
“We will be enforcing user limits on all remaining Free GitLab.com namespaces with private visibility on August 15, 2026.”
This is the final phase of a five-user limit GitLab announced in 2022, not a new price change. GitLab estimates it will impact fewer than 2% of Free tier users within 0.3% of top-level groups. If you are on a paid tier, on self-managed GitLab, or your top-level group is public, it does not apply to you.
Source: GitLab Blog: Upcoming changes to user limits on Free tier of GitLab SaaS, read 2026-08-05.
Who is affected
GitLab.com Free, GitLab Self-Managed, GitLab Dedicated, Premium and Ultimate are different products, and this change lands on exactly one of them. Check which row you are in before you do anything else.
| Where you are | Affected? | What GitLab documents |
|---|---|---|
| GitLab.com Free, private top-level namespace GitLab’s SaaS offering on the Free tier, where the top-level group is set to private visibility. | Yes | This is the only configuration the 15 August 2026 enforcement targets. The limit is five users per top-level namespace. GitLab Docs: Free tier user and group limits |
| GitLab.com Free, public top-level group The same SaaS Free tier, with the top-level group set to public visibility. | No | GitLab states that user limits do not apply to top-level groups with public visibility. GitLab Docs: Free tier user and group limits |
| GitLab.com Free, personal namespace A personal namespace rather than a group. | No | GitLab lists personal namespaces as excluded, because they are public by default. GitLab Docs: Free tier user and group limits |
| GitLab Premium and Ultimate Paid GitLab.com tiers. GitLab lists Premium at $29 per user/month billed annually; Ultimate is custom pricing. | No | GitLab states the user limits do not apply to paid tiers. GitLab pricing |
| GitLab Self-Managed GitLab you install, administer and maintain on your own infrastructure, including its Free tier. | No | GitLab lists Free tier self-managed users among those the limits do not apply to. A self-managed instance is not a GitLab.com namespace. GitLab Blog: Upcoming changes to user limits on Free tier of GitLab SaaS |
| GitLab Dedicated GitLab’s single-tenant SaaS offering, fully isolated and deployed in a chosen AWS region, hosted and maintained by GitLab. | No | GitLab documents Dedicated at the Ultimate tier. There is no Free tier for it. GitLab Docs: GitLab Dedicated |
| GitLab for Open Source, Education, Startups GitLab’s community programs. | No | GitLab lists these community programs as excluded from the user limits. GitLab Docs: Free tier user and group limits |
What becomes read-only
GitLab describes this in two places: the categories a read-only namespace cannot write new data to, and a table of restricted actions. Both are quoted below rather than merged into a tidier claim than either page supports.
Repositories
GitLab lists repositories among the categories a read-only namespace cannot write new data to.
GitLab Docs: Free tier user and group limitsGit LFS
Git Large File Storage is listed in the same set of categories that cannot take new data.
GitLab Docs: Free tier user and group limitsPackages
Packages cannot receive new data. The restricted-actions table lists publishing packages to the package registry.
GitLab Docs: Read-only namespaces and projectsContainer registry
The restricted-actions table lists pushing images, and creating, editing or deleting cleanup policies.
GitLab Docs: Read-only namespaces and projectsCI/CD
The restricted-actions table lists creating, editing, administering and running pipelines and builds, and administering environments, deployments, clusters and releases.
GitLab Docs: Read-only namespaces and projectsMerge requests
The restricted-actions table lists creating and updating merge requests.
GitLab Docs: Read-only namespaces and projectsUsers
The restricted-actions table lists inviting new users to the namespace. Every unique user across the group, its subgroups and its projects counts toward the five-user limit.
GitLab Docs: Free tier user and group limitsStorage limits are a different rule
GitLab documents a separate allowance of 10 GiB of free storage per project on the Free tier, covering the repository and Git LFS only, with the container registry, package registry and build artifacts excluded from that number. Exceeding it makes the project read-only. That is a different mechanism from the five-user namespace limit, and it is not what changes on 15 August 2026.
GitLab Docs: StorageGitLab.com, Self-Managed and Dedicated are different offerings
GitLab describes GitLab.com as its software-as-a-service offering, Self-Managed as an instance you install, administer and maintain yourself, and Dedicated as a single-tenant SaaS service for highly regulated and large enterprises. The 15 August 2026 enforcement concerns GitLab.com namespaces only.
GitLab Docs: GitLab plansPre-migration inventory
Importing the repositories is the part that works on its own. The migration is everything around it, and the work is far easier to size before you start than halfway through. Take this inventory first.
Project and group structure
Group and subgroup tree, project count, and which projects are genuinely active rather than archived in place.
Users, permissions and ownership
Who has access, at what level, and who owns each project. GitLab does not migrate users or their personal access tokens, so accounts are established on the new forge.
Repositories and Git LFS
Repository sizes, LFS object counts and total LFS size. Large LFS stores are the most common cause of a migration taking longer than expected.
Issues, merge requests and attachments
Issue and merge-request volume, comment history, labels, milestones, releases, and uploaded attachments.
CI: pipelines, templates and includes
Pipeline count, .gitlab-ci.yml complexity, cross-project includes and templates, protected variables, schedules, environments, caches, services and runner tags.
Container and package registries
Which registries are in use, image and package counts, and which tags anything still pulls from in production.
GitLab Pages
Any Pages sites, their custom domains and certificates, and what publishes them.
Webhooks and integrations
Every webhook and third-party integration, plus what consumes them. These are re-created rather than imported.
SSO, SCIM, audit and policy
Identity provider wiring, provisioning, audit requirements, approval rules and protected branches. Policy is recreated deliberately, not copied.
What moves, what is rewritten, what is replaced
Rows citing a GitLab source describe what GitLab's own export does and does not include, which is the half of a migration GitLab decides rather than us. Rows without one describe Forgejo and Fjord behaviour, which is ours to stand behind.
| Item | Status | Detail |
|---|---|---|
| Git history, branches, tags | Migrates automatically | Project and wiki repositories are included in GitLab’s project export. GitLab Docs: Migrate projects by using file exports |
| Issues, merge requests, comments, labels, milestones | Migrates automatically | GitLab’s export includes issues, merge requests with diffs and approvals, commit comments, labels and milestones. Merge requests arrive as Forgejo pull requests. GitLab Docs: Migrate projects by using file exports |
| Releases | Migrates automatically | Releases are listed in GitLab’s project export. GitLab Docs: Migrate projects by using file exports |
| Git LFS objects | Migrates automatically | GitLab lists LFS objects among exported items. Confirm object counts after import rather than assuming. GitLab Docs: Migrate projects by using file exports |
| GitLab CI pipelines | Requires manual conversion | GitLab exports pipelines in archived form, and direct transfer migrates job records without job logs or artifacts. The .gitlab-ci.yml itself is rewritten as Forgejo Actions workflows. This is the real work in most migrations. GitLab Docs: Items migrated when using direct transfer |
| CI/CD variables and secrets | Requires manual conversion | GitLab explicitly excludes CI/CD variables and any encrypted tokens from its export. They are re-created as Forgejo Actions secrets by hand. GitLab Docs: Migrate projects by using file exports |
| CI/CD job logs and artifacts | Not currently supported | GitLab excludes job traces and artifacts from export, and does not migrate them by direct transfer. Treat historical job output as staying behind. GitLab Docs: Migrate projects by using file exports |
| Container and package registry images | Requires a replacement | GitLab explicitly excludes package and container registry images from its export. Images are re-pushed to the new registry as a planned cutover, not an import. GitLab Docs: Migrate projects by using file exports |
| Webhooks and integrations | Requires a replacement | GitLab excludes webhooks and project integrations from its export. Each one is re-created and re-pointed. GitLab Docs: Migrate projects by using file exports |
| Deploy keys | Requires a replacement | GitLab lists deploy keys among items not exported. Re-issue them on the new forge. GitLab Docs: Migrate projects by using file exports |
| Users and their access tokens | Requires manual conversion | GitLab states users and any personal access tokens they create are excluded from direct transfer. Accounts and tokens are established on the new forge. GitLab Docs: Items migrated when using direct transfer |
| Epics, iterations, issue boards | Requires manual conversion | Planning surfaces above the issue. Forgejo has no one-to-one equivalent for epics and iterations, so decide what flattens into labels and milestones. |
| Approval rules, protected branches, group policy | Requires manual conversion | Policy rather than content. Re-created as Forgejo branch protection and required reviews. |
Migration checklist
Each step says who does it. We are a managed forge, not a custodian of your GitLab account: the steps marked as yours stay yours on purpose.
1. Confirm whether you are actually affected
You control thisCheck whether your top-level namespace is on GitLab.com Free with private visibility, and count every unique user across the group, its subgroups and its projects. Self-managed, paid tiers, public top-level groups and personal namespaces are outside this change.
2. Inventory before you move anything
We do it togetherList projects and groups, repository and LFS sizes, registries in use, pipeline count and complexity, protected variables, scheduled pipelines, environments, approval rules, protected branches, Pages sites, webhooks and integrations, and any SSO or SCIM dependency.
3. Decide what is not coming with you
You control thisJob logs and artifacts, registry images, CI variables, webhooks and deploy keys are not in GitLab’s export. Decide deliberately what gets re-created, what gets archived, and what is genuinely dead.
4. Stand up the Forgejo instance
Fjord does thisWe provision a dedicated single-tenant Forgejo, run the upgrades, TLS, backups and CI infrastructure, and give you an admin account on it.
5. Import one representative project first
We do it togetherPick a project that exercises your awkward cases rather than your simplest one. Validate history, merge requests, labels and LFS objects against the source before repeating.
6. Rewrite CI
We do it togetherGitLab CI stages, rules, caches, includes and runner tags become Forgejo Actions workflows. We map the pattern and can do the conversion with you; you own the pipeline semantics, because you are the ones who know what the pipeline is for.
7. Re-create secrets, registries and integrations
You control thisProtected variables become Actions secrets, registry images are re-pushed, webhooks and deploy keys are re-issued. Secrets are entered by you: we do not ask for, copy, or hold your GitLab credentials or CI secrets.
8. Cut over remotes and validate
We do it togetherRepoint git remotes and any deploy automation, then verify clone, push, pipeline run, release and registry pull on the new forge before you retire anything.
Cutover sequencing, validation and acceptance testing, rollback planning, DNS and remote changes, post-migration monitoring, and safely decommissioning GitLab are covered when we plan the move with you.
Questions people actually ask
What changes on 15 August 2026?
GitLab has said it will enforce user limits on all remaining Free GitLab.com namespaces with private visibility on that date. The limit is five users per top-level namespace, and it was first announced in 2022 rather than being a new change. GitLab estimates the change affects fewer than 2% of Free tier users, within 0.3% of top-level groups.
Am I affected?
Only if your top-level namespace is on GitLab.com Free, is set to private visibility, and has more than five unique users across the group, its subgroups and its projects. GitLab states the limit does not apply to public top-level groups, personal namespaces, paid tiers, self-managed installations, or its Open Source, Education and Startups programs. GitLab also says impacted users are notified in-app and by email at least 60 days before enforcement.
What exactly becomes read-only?
GitLab states that affected namespaces cannot write new data to repositories, Git LFS, packages or registries. Its restricted-actions list also covers creating and running CI/CD pipelines and builds, creating and updating merge requests, pushing container images, and inviting new users to the namespace.
Does this apply to self-managed GitLab or GitLab Dedicated?
No. GitLab lists Free tier self-managed users among those the limits do not apply to, and a self-managed instance is not a GitLab.com namespace. GitLab Dedicated is a separate single-tenant SaaS offering documented at the Ultimate tier, with no Free tier.
Can I stay on GitLab?
Yes, and for many teams that is the right answer. GitLab’s own options are to bring the namespace under five users, upgrade to a paid tier, or use a top-level group with public visibility, which the limit does not apply to. GitLab also runs Open Source, Education and Startups programs. Moving forge is a decision about what you want to own, not something this date forces.
What does Fjord do, and what stays with me?
We provision and operate a dedicated single-tenant Forgejo instance, including upgrades, TLS, backups and CI infrastructure, and we help plan and run the import and the CI rewrite. You keep control of your GitLab account and its data: we do not ask for or hold your GitLab credentials or CI secrets, and you enter secrets on the new forge yourself. Your data exports from Forgejo in the upstream format at any time.
Why teams make the move
A calmer, owned forge without the sprawl: single-tenant, priced per instance rather than per seat, with written no-AI-training terms. Team and Pro add dedicated, unmetered runners, so the CI you rewrite runs on capacity that is yours.
And if you ever leave
Your data exports in the upstream Forgejo format any time, per-repository or as a full forgejo dump. The same openness that lets you come in lets you go out.