Does GitLab Work in China? Data Residency, Localization & PIPL Cross-Border

For a mainland-China engineering team, the first thing to settle about GitLab is that the question is not whether it installs, or whether git push reaches the server. GitLab is a complete DevOps platform, and it holds some of a company’s most sensitive assets: source code (a trade secret in its own right, and routinely carrying embedded credentials, API keys, and personal information inside configs, fixtures, and test data), CI/CD pipeline secrets, build logs and artifacts, and the infrastructure-as-code state that maps your whole topology. Where all of that is allowed to come to rest is the real question. GitLab’s posture is three-shaped: GitLab.com, the multi-tenant SaaS, runs on Google Cloud with no customer-selectable region; GitLab Dedicated, the single-tenant managed service, deploys only to a fixed list of AWS regions — none in mainland China; and GitLab Self-Managed, the open-core software, installs on infrastructure you choose, including servers in mainland China. That residency fact, not reachability, is the whole question.

GitLab in China at a glance

Where the code, secrets and state actually rest

Start with where a GitLab deployment physically keeps your data, because that is what the whole China question rests on. GitLab comes in three shapes, and they give three different answers.

GitLab.com, the multi-tenant SaaS, is a single global instance. GitLab’s own blog announced that “GitLab.com is migrating to Google Cloud Platform,” and there is no customer-selectable region: you do not choose where your projects live, and none of them live in mainland China.

GitLab Dedicated, the single-tenant managed service, does let you choose a region — but only from a fixed list of AWS regions. GitLab’s “Data residency and high availability” page puts it plainly: “During onboarding, you select the AWS region for your instance deployment and data storage.” That list spans Asia Pacific (Mumbai, Seoul, Singapore, Sydney, Tokyo), Europe (Frankfurt, Ireland, London, Stockholm), the United States, Canada, and Bahrain — and it contains no mainland-China region. The AWS China partition (the Beijing and Ningxia regions, operated by Sinnet and NWCD) is a wholly separate cloud that GitLab Dedicated does not deploy into. So a Dedicated instance’s repositories, pipelines, logs, and artifacts come to rest offshore.

GitLab Self-Managed is the opposite. GitLab is open-core — its Community Edition is open source under an MIT license — and the self-managed software installs on infrastructure you control. GitLab’s own install page describes it as an instance where you “install, host GitLab on your own setup” with “full control of your data and infrastructure,” with instructions for Linux, Kubernetes, Docker, and the major clouds. You can run it on servers physically in mainland China, and with self-hosted runners the CI/CD jobs, logs, and artifacts stay in-country too. The software is residency-neutral; where you deploy it decides residency.

There is also a distinct in-country option. In 2021 GitLab Inc. “licensed its technology to an independent Chinese company (JiHu)” — GitLab Information Technology (Hubei) Co., Ltd. — which GitLab describes as “an independent company with full autonomy over its operation and management” that “will provide GitLab’s DevOps platform as both a self-managed and SaaS offering hosted in China.” By GitLab’s own terms its GitLab.cn and GitLab.com services “share no common infrastructure, networking connectivity, systems, services, data, or resources,” the Enterprise Edition “will only be sold outside China,” and the JiHu Edition “will only be sold in China.” That is a genuine in-country operator — but it is a separate company and a separate product, not your GitLab.com or GitLab Dedicated tenant, and standing on it is not automatic compliance: you remain the handler of the personal information involved.

What it holds is personal information — and trade secrets

A DevOps platform is where an engineering organization’s most sensitive assets come to rest. GitLab holds your source code — itself a trade secret, and routinely carrying embedded credentials, API keys, and tokens, plus personal information inside configuration files, fixtures, and test data — along with CI/CD pipeline secrets, build logs and artifacts, issue and merge-request history, and the infrastructure-as-code state that maps your entire topology and often stores secrets in plaintext. Wherever commits, tickets, or fixtures carry names, emails, or real customer records, that content is personal information under the Personal Information Protection Law, and sensitive personal information under PIPL Article 28 where it includes government IDs, financial, or health data.

The moment a developer in China pushes that content to an instance hosted offshore, the code and any personal information in it have left the country. Under PIPL that is a cross-border transfer (数据出境), and Articles 38–40 put the duty on you, the handler: give notice, obtain a separate consent, and satisfy one transfer mechanism — a CAC security assessment, the CAC standard contract, or certification. Where volumes or data types cross the thresholds, the data-export security assessment is mandatory rather than optional.

And for some handlers, storage is not a matter of mechanism at all — it must stay in-country. If your organization operates critical information infrastructure, or handles personal information at scale, the Cybersecurity Law imposes a data-localization duty: Article 39 (the 2025 Cybersecurity Law amendment, in force January 1, 2026, renumbered the data-localization article from 37 to 39; the substance is unchanged) requires personal information and important data collected and generated in-country to be stored in-country, with a security assessment before any export. PIPL Article 40 states the same duty for critical information infrastructure operators and large-volume handlers. An offshore GitLab SaaS with no mainland-China region structurally cannot meet it.

A no-China-region SaaS can’t meet the residency duty — and what can

Put those facts together and the conclusion is narrow and practical. If your source code, pipeline secrets, and state must stay in-country — because you operate critical information infrastructure, because the personal information in your repositories crosses the volume thresholds, or because you simply decide not to carry the cross-border exposure — then a managed DevOps cloud with no mainland-China region cannot be the system of record. GitLab.com and GitLab Dedicated are excellent managed services; they simply have no home on mainland soil for the assets that must rest there.

The practical point is that you do not need to migrate off GitLab to fix this, because the lawful lever is the same platform run in a different place. Run GitLab Self-Managed on mainland-China infrastructure and the repositories, pipelines, and infrastructure-as-code state never leave the country; pair it with self-hosted runners and the build logs and artifacts stay in-country as well. Or use the licensed in-country option operated by JiHu. Either way you keep GitLab — the same Git workflows, the same CI/CD, the same merge requests — while the data comes to rest in-country. GitLab.com stays reachable from the mainland for the work that does not need to be localized (it can be throttled, but that is a delivery matter, not the residency question). Any China-facing surface in front of GitLab — a developer portal, documentation site, GitLab Pages, or review app your mainland users reach — still carries an ICP filing (备案) duty and needs compliant, in-country delivery.

This page maps exposure; it does not rule on your facts. Whether a given deployment triggers the in-country storage duty, which transfer mechanism applies, and what consent and records you need are decisions to settle with your own counsel, against the real data you handle and the entity that handles it.

The lawful path — map, localize, deliver

21YunBox is a compliant overlay on the stack you already run — not a migration, and not a competitor to GitLab. Our role is three moves.

First, we map the exposure: whose personal information sits in your repositories, issues, and CI logs, how much of it, whether any is sensitive or “important data,” whether your source code and state carry trade-secret and key-management risk, whether your entity is a critical information infrastructure operator, and how all of that lands against PIPL’s cross-border rules, Article 28, PIPL Article 40, and the Cybersecurity Law — so you and your counsel can decide what must stay in-country.

Second, we localize: run GitLab in-country so the code, secrets, and state rest on mainland soil — GitLab Self-Managed on mainland infrastructure with self-hosted runners, or a licensed domestic option — with consented, in-country storage for what must stay. Localize means standing up a lawful, in-country GitLab, not reaching back to an offshore SaaS endpoint.

Third, we deliver: any China-facing surface in front of the platform — the developer portal, documentation, Pages, or review apps your mainland users hit — over ICP-filed, in-country infrastructure (the 21YunBox Optimizer), in front of the stack you already run, with no rebuild and no second codebase.

The result runs legally and compliantly for your users in China. 21YunBox never uses or suggests circumvention of any kind.

Get a compliance assessment →

Related reading:

• Cross-border data transfers under PIPL
• China’s Cybersecurity Law (data localization, Article 39)
• China’s data-export security assessment measures
• How to get an ICP filing for China

RELATED TECHNOLOGIES

Bitbucket

Bitbucket

CircleCI

CircleCI

GitHub

GitHub

HashiCorp Vault

HashiCorp Vault

Jenkins

Jenkins

Terraform

Terraform