Does GitLab CI/CD Work in China? Data Residency, ICP & Cross-Border Rules
A GitLab CI/CD pipeline checks out your proprietary source and injects your deploy keys, cloud credentials and signing keys into the job, then writes build artifacts; on GitLab.com's hosted runners that runs on GitLab's offshore infrastructure — a PIPL data-residency question, not a reachability one. Self-managed GitLab with a self-hosted GitLab Runner in-country keeps source, secrets and artifacts resident.
Does GitLab CI/CD work in China?
Whether GitLab CI/CD works in China is a data-residency question about your source and secrets, not a speed one. A pipeline job runs fine from inside the mainland — what decides this is where your code and credentials live while it executes.
Every CI/CD job checks out your proprietary source into the runner's workspace and injects your secrets — deploy keys, cloud credentials, signing keys, registry tokens — then writes build artifacts. On GitLab.com's hosted runners that happens on GitLab's own offshore infrastructure, so your concentrated source, secrets and artifacts sit abroad and your China deployment's build pipeline crosses the border: a cross-border transfer of personal information PIPL governs, and for a CIIO or large-volume handler a data-residency duty too. The lever is a self-managed GitLab with a self-hosted GitLab Runner in-country, which keeps the checkout, secrets and artifacts resident.
This is a risk picture, not a verdict — your obligations turn on your data volumes and your role. Our China team can map your pipeline's residency exposure with you →
What GitLab CI/CD's own documentation says about China
| Fact | Primary source |
|---|---|
| In GitLab's own words: "GitLab-hosted runners are managed by GitLab and available on GitLab.com," and GitLab "provides them as a service" — its own infrastructure — whereas "Self-managed runners are GitLab Runner instances that you install, configure, and manage in your own infrastructure," and "You can install and register self-managed runners on all GitLab installations." So the hosted runners that check out your source and run your secrets are GitLab's offshore service, and the in-country residency path is a self-hosted runner you run yourself. | GitLab Docs — GitLab Runner, retrieved 2026-10-13 |
| A CI/CD job does not just reach a service — it holds your source and secrets while it runs. GitLab's documentation describes CI/CD variables as "a type of environment variable" you use to "store values you want to re-use, for example in job scripts": the mechanism that injects deploy keys, cloud credentials, signing keys and registry tokens into the run environment. On a hosted runner that environment, and the proprietary source checked out beside it, execute on GitLab's offshore infrastructure. | GitLab Docs — CI/CD variables, retrieved 2026-10-13 |
| Because a hosted runner holds the identities of your committers, job logs, and any personal data inside artifacts or variables, and executes them on infrastructure outside the mainland, that is a cross-border transfer of personal information. PIPL governs it (Articles 38–40): the personal-information handler (you, the GitLab customer) must give notice, obtain separate consent, and satisfy one transfer mechanism — a CAC security assessment, the CAC standard contract, or certification. | Personal Information Protection Law, Articles 38–40 |
| For a CIIO or large-volume handler, personal information and important data collected and generated in mainland China must be stored in the mainland, with a security assessment before any export — the Cybersecurity Law data-localization rule, Article 39 (formerly Article 37) as renumbered by the 2025 amendment in force 2026-01-01. A runner hosted offshore that checks out your source and runs your secrets has no mainland footing to meet that. | Cybersecurity Law of the PRC, Article 39 (formerly Article 37) |
Sources verified by the 21YunBox compliance team on 2026-10-13.
For a mainland-China deployment, the deciding question about GitLab CI/CD is not whether a runner in Shanghai can reach GitLab or pull a public dependency — it is where your source code, your build and deploy secrets, and your build artifacts live at the moment the pipeline runs. Reaching the service and resolving dependencies are reachability topics, and connectivity tuning can help them; they are not the part that decides whether your setup is defensible. A CI/CD job is different. Every job checks out your proprietary source into the runner’s workspace, then injects your secrets — deploy keys, cloud credentials, signing keys and registry tokens — into the run environment, and produces build artifacts. On GitLab.com’s hosted runners, that concentrated source, those secrets and those artifacts all execute on GitLab’s own infrastructure, and your China deployment’s build pipeline crosses the border. Residency and cross-border transfer, not pull latency, are what decide this.
Does GitLab CI/CD work in China? At a glance
| What decides it | What it means for mainland China |
|---|---|
| What the job checks out | Every CI/CD job clones your proprietary source into the runner's workspace — a concentrated slice of your intellectual property sitting wherever the runner runs. |
| What secrets the job holds | CI/CD variables inject deploy keys, cloud credentials, signing keys and registry tokens into the run environment; by GitLab's docs they are “a type of environment variable” available to the job. |
| Where the runner runs | GitLab.com's hosted runners are “managed by GitLab” and “provided as a service” on GitLab's offshore infrastructure. GitLab publishes no mainland-China hosted-runner region (confirm current with GitLab). |
| Data residency | For a CIIO or large-volume handler, personal information and important data collected in China must be stored in the mainland (Cybersecurity Law Article 39 (formerly Article 37)) — a duty an offshore runner cannot meet. |
| Cross-border transfer | Committer identities, job logs and any personal data inside artifacts or variables, executed offshore, are a PIPL cross-border transfer (Articles 38–40): notice, a separate consent, and one transfer mechanism. |
| The residency lever | A self-managed GitLab with self-hosted GitLab Runners run inside the mainland keeps the checkout, the injected secrets and the build artifacts resident. |
Door one — your source is checked out into the runner, and residency follows where the runner runs
Start with what actually executes, because that is what China’s law answers to. Reaching GitLab and pulling a public package is a connectivity topic, and it is not the part that decides this. The job is. When a pipeline runs, GitLab Runner clones your private repository into the runner’s workspace — your proprietary source, dependencies and build logic, a concentrated slice of your intellectual property. GitLab’s own documentation describes GitLab-hosted runners as “managed by GitLab and available on GitLab.com,” with GitLab providing them “as a service” — a hosted fleet running on GitLab’s own offshore infrastructure, with no mainland-China hosted-runner region for your jobs (worth confirming with GitLab rather than assuming). If you are a critical information infrastructure operator, or you handle personal information at volume, personal information and important data collected and generated in China must be stored in the mainland, with a security assessment before any export — the Cybersecurity Law data-localization rule, Article 39 (formerly Article 37) as renumbered by the 2025 amendment in force 2026-01-01. A hosted runner that checks out your source abroad has no mainland footing to satisfy that.
Door two — injected secrets, committer identities and your build artifacts
The second door is PIPL and the concentrated secrets a pipeline carries. A CI/CD job holds far more than source: GitLab’s documentation describes CI/CD variables as “a type of environment variable” you use to “store values you want to re-use, for example in job scripts” — the mechanism that injects your deploy keys, cloud credentials, signing keys and registry tokens into the running job. Around them sit the usernames and email addresses of whoever pushed, reviewed and triggered the pipeline, the job logs, and the build artifacts the job writes — with the occasional personal record riding along in a fixture or test dataset. Under the Personal Information Protection Law, holding and processing that data on infrastructure outside the mainland is a cross-border transfer (Articles 38–40): the handler must give notice, obtain a separate consent for the transfer, and clear one mechanism — a CAC security assessment, the CAC standard contract, or certification. Masking variables and trimming what lands in logs and artifacts is part of good hygiene, but it does not move the runner that executes them. And because your China deployment is built and deployed by whichever runner runs the job, the provenance and integrity of what ships to the mainland — built from what source, signed with which key — are governed across the border too: a supply-chain exposure a connectivity check never surfaces.
Why a reachability check misses this
A “can my runner reach GitLab from Shanghai” test answers the wrong question. Connectivity tuning or a dependency cache changes how fast and how reliably a job starts and resolves its packages — it does not change where your source gets checked out, where your injected secrets execute, and where your build artifacts are written. So a pipeline can look perfectly green from inside China while every checkout of your proprietary source, every deploy key and signing key injected into the job, and every committer record still runs offshore. The residency and cross-border questions above are invisible to a reachability probe precisely because the jobs keep passing — which is why the move that matters is running the runners in-country, not making the hosted ones merely reachable. We publish no first-party measurement of GitLab connectivity from inside China, so we put no figures here; it is something we would measure against your actual setup rather than assert.
This is a risk map, not a verdict: whether you need in-country runners, a transfer mechanism, a reworked consent flow, an ICP filing for any public-facing developer or deployment portal, or some combination depends on what your pipelines check out, which secrets they hold, and who your committers are — worth settling with counsel before you build.
The lever — map, localize, deliver
Because a genuine self-managed GitLab and self-hosted GitLab Runner exist, there is a real in-country path, and 21YunBox never uses or suggests any unlawful workaround — the in-country path is the lawful one.
- Map — inventory which pipelines check out proprietary source, which secrets (deploy keys, cloud credentials, signing keys, registry tokens) the runner holds, where the runners and artifact store live today, the residency basis, and how your China deployment’s build pipeline crosses the border.
- Localize / govern — run the runners in-country (self-hosted — a self-managed GitLab with self-hosted GitLab Runners in your own infrastructure), so the checked-out source, the injected secrets and the build artifacts stay resident; keep your China deployment’s build pipeline in-country; and minimize what crosses the border.
- Deliver — put compliant, in-country self-hosted runners and a self-managed control plane in front of (or in place of) the offshore hosted runners; 21YunBox stands up the in-country layer without a rebuild.
Making the hosted service merely reachable is not the answer — your source, secrets and artifacts still execute offshore, and starting jobs faster does not change that. Keeping the runners and what they hold in-country is.
Where 21YunBox fits — a compliant overlay, not a migration
You keep using GitLab and your existing pipelines. We add the piece a hosted runner cannot provide on its own: a lawful, in-country home for a self-managed GitLab with self-hosted GitLab Runners, so your proprietary source, injected secrets and build artifacts stay resident where the law requires, with compliant ICP-filed delivery for the developer access and any public-facing deployment portal in front of it — placed around your existing setup, with no rebuild, no second codebase, and no migration off GitLab. As a partner to the toolchain you already run, our China team maps your PIPL cross-border, consent and data-residency obligations against your entity and your pipeline, then stands up the in-country runners and delivery a defensible China presence needs. We never use or suggest any unlawful workaround.
Related reading:
- Cross-border data transfers under PIPL
- China’s Cybersecurity Law and data localization
- How to get an ICP filing for China
