Today I got an email from GitLab titled “Important Change to Your GitLab.com Account.” It was blunt: GitLab.com will no longer provide accounts to individuals and organizations located in Mainland China, Hong Kong and Macao. Accounts must be migrated before September 7, 2026, after which they will be deleted.
The email reads:
Please be advised that GitLab can no longer service GitLab.com accounts for individuals and organizations located in Mainland China, Macao, and Hong Kong. Our system indicates that you are visiting GitLab from one of these locations. We advise you to sign up with JiHu https://gitlab.cn/saasmigration/. JiHu is an independent company with a localized GitLab offering that has an exclusive right to provide GitLab to individuals and organizations located in this region. You must complete the transition by September 07, 2026, after which GitLab will delete your account from our systems. If you believe you are receiving this notification in error, please log in to GitLab.com from a supported service location. For further information or support, please feel free to contact saasmigration@gitlab.cn. Best Regards, GitLab Team
This isn’t the first time I’ve seen a notice like this. Back on December 22, 2024, I wrote GitLab’s Global Site Will Delete Accounts in Mainland China, Hong Kong and Macao Within 60 Days. At the time I found the hints in the source code: individuals and organizations in those regions had to migrate to JiHu GitLab within 60 days, after which accounts would be deleted.
Back then I assumed it was a short-term adjustment. Two years later, it has landed on me.
I won’t pretend I’m not disappointed. A GitLab account is more than a place to park a few repositories — it’s a ticket into open source collaboration. Without it, filing issues (now called Work Items), opening MRs, or even maintaining the projects I’ve left behind all get a lot more annoying.
GitLab has restricted service by region before
This isn’t new, and it isn’t only a “what should Chinese users do” story. GitLab.com is an online service run by a US company, and it has to deal with export control and sanctions compliance on an ongoing basis. The practical impact tends to land first on ordinary developers — their logins, their collaboration, their access to data.
2018: a public warning ahead of a cloud migration
In July 2018, GitLab announced it was moving GitLab.com from Azure to Google Cloud Platform. The notice specifically warned that due to what Google described as legal restrictions, users in Crimea, Cuba, Iran, North Korea, Sudan and Syria might lose access to GitLab.com after the migration. GitLab’s advice at the time was plain: download your code first, or export your projects as backups. That text is still visible in GitLab’s migration announcement.
What’s worth noticing isn’t how long the list of regions was. It’s that an ordinary infrastructure migration can change who the service is reachable for. For a user, remembering to back up once the login page stops loading is usually too late.
Rules change; data shouldn’t live in only one place
GitLab’s current trade compliance page still states that some of its software and services are subject to US export control and sanctions rules, and that the listed countries and regions change as regulations change. It isn’t a permanent “ban list,” but it’s enough to make the point: hosting your code on a cloud service doesn’t buy you permanent, unconditional access.
So the email in this post isn’t an isolated event. It’s the same category of compliance risk landing at a different time, in a different region. For individual developers and small teams, the realistic response isn’t complicated: keep local copies of your repositories, keep a working mirror of anything important, and make sure collaboration data can be exported and restored.
Don’t wait for the last day
This email at least reminded me of one thing: code and project data sitting on someone else’s platform can’t be underwritten by the assumption that “the platform will still be there.” Once your account is flagged as belonging to an affected region, the time you get to deal with your data may be short.
If you got this email too, do these first:
- Clone and verify you still have local copies of every important repository — don’t forget Wikis, LFS files and Release attachments;
- Export collaboration records: issues, Work Items, merge requests;
- Take stock of CI/CD variables, deployment configuration, webhooks and access tokens. Tokens shouldn’t be written straight into a backup file, but confirm you can reconfigure them after migrating;
- Pick your migration target early, based on what your team actually needs, and leave time to verify permissions, pipelines and mirrors.
The important part isn’t gambling on how your region gets classified. It’s getting your own data and collaboration records back first. Code can move. Once the account is gone, fixing things afterward is rarely as calm an affair.