Does GitHub Actions Work in China? Data Residency, ICP & Cross-Border Rules

A GitHub Actions workflow checks out your proprietary source and injects your secrets into the runner, then builds your artifacts. On GitHub-hosted runners that runs offshore in Azure — a data-residency and PIPL cross-border question, not reachability. Self-hosted runners in-country keep them resident.

By the 21YunBox Compliance Team · Reviewed 2026-10-13 · Verified against GitHub Actions's own documentation

Does GitHub Actions work in China?

Yes, GitHub Actions runs from inside China — but on GitHub-hosted runners the question that decides compliance is where your source and secrets live when a workflow runs, not whether the runner has connectivity. Every run checks out your proprietary source code and injects your secrets — deploy keys, cloud credentials, signing keys, registry tokens — into the runner that executes it, then produces your build artifacts there. GitHub-hosted runners are virtual machines hosted by GitHub in Microsoft Azure, outside the mainland, so that concentrated source, those secrets and those artifacts leave China and your deployment's build-and-deploy pipeline crosses the border — a data-residency question under the Cybersecurity Law — Article 39 (formerly Article 37) — and a cross-border transfer under PIPL, not a reachability one. The lever is self-hosted runners you deploy and manage on your own in-country machines, so the checkout, the secrets and the artifacts stay resident.

What GitHub Actions's own documentation says about China

Fact	Primary source
GitHub's documentation states that, with the exception of single-CPU runners, each GitHub-hosted runner is a new virtual machine hosted by GitHub, and that GitHub hosts Linux and Windows runners on virtual machines in Microsoft Azure — infrastructure outside mainland China.	GitHub Docs — About GitHub-hosted runners (retrieved 2026-10-13)
GitHub's documentation defines a self-hosted runner as "a system that you deploy and manage to execute jobs from GitHub Actions on GitHub," and states "You can host your own runners and customize the environment used to run jobs in your GitHub Actions workflows" — so an in-country, self-managed runner is a first-party option.	GitHub Docs — About self-hosted runners (retrieved 2026-10-13)
For a critical information infrastructure operator, personal information and important data collected and generated in mainland China must be stored within the mainland, with a security assessment before any export — the data-localization rule now at Article 39 (formerly Article 37) after the 2025 amendment in force 2026-01-01.	Cybersecurity Law of the People's Republic of China, Article 39 (formerly Article 37) (retrieved 2026-10-13)
Holding runner-side personal data — the identities and emails of whoever triggered a run, plus build logs — on infrastructure outside the mainland is a cross-border transfer under PIPL (Articles 38–40), requiring notice, a separate consent, and one transfer mechanism (a CAC security assessment, the CAC standard contract, or certification).	Personal Information Protection Law of the People's Republic of China, Articles 38–40 (retrieved 2026-10-13)

Sources verified by the 21YunBox compliance team on 2026-10-13.

For a mainland-China deployment, the deciding question about GitHub Actions is not whether a runner in Shanghai can reach GitHub or pull a public dependency — it is where your source code, your secrets and your build artifacts live at the moment the workflow runs. Every workflow run checks out your proprietary source code onto the runner, injects your secrets — deploy keys, cloud credentials, signing keys, registry tokens — into the run environment, and produces your build artifacts there. On GitHub-hosted runners, that work executes on virtual machines hosted by GitHub in Microsoft Azure, outside the mainland: your concentrated source, your secrets and your artifacts leave China, and your China deployment’s build-and-deploy pipeline crosses the border. Residency and cross-border transfer, not runner connectivity, are what decide whether this is defensible.

GitHub's official documentation on self-hosted runners, stating that you can host your own runners and customize the environment used to run jobs in your GitHub Actions workflows, and defining a self-hosted runner as a system that you deploy and manage — confirming an in-country self-hosted path exists as the residency lever — GitHub's own documentation states, “You can host your own runners and customize the environment used to run jobs in your GitHub Actions workflows,” and defines a self-hosted runner as “a system that you deploy and manage to execute jobs from GitHub Actions on GitHub.” Because you deploy and manage it, you choose where it runs — which is why the residency lever is a self-hosted runner in-country, not merely reaching the offshore one. Source: GitHub Docs — About self-hosted runners

Does GitHub Actions work in China? At a glance

What decides it	What it means for mainland China
What a workflow run handles	Each run checks out your proprietary source code onto the runner, injects your secrets — deploy keys, cloud credentials, signing keys, registry tokens — into the run environment, and produces your build artifacts there.
Where GitHub-hosted runners run	GitHub-hosted runners are virtual machines hosted by GitHub in Microsoft Azure, outside the mainland. GitHub publishes no mainland-China region for its hosted runners (confirm current with GitHub).
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	Secrets, the identities and email addresses of whoever triggered a run, and build logs, held on an offshore runner, are a PIPL cross-border transfer (Articles 38–40): notice, a separate consent, and one transfer mechanism.
Your deployment's pipeline	A China deployment built and shipped from an offshore runner runs its build-and-deploy pipeline across the border. Making the runner merely reachable does not move your source, secrets or artifacts in-country.
The residency lever	A self-hosted runner — a system you deploy and manage — run inside the mainland keeps the checkout, the injected secrets and the build artifacts resident.

Door one — your source checkout is proprietary code, and residency follows where the runner runs

Start with what the runner holds, because that is what China’s law answers to. A GitHub Actions job does not reach out to your code from a safe distance; it checks your repository out onto the runner’s own disk, a concentrated copy of your proprietary source that then sits in the run environment alongside everything the job touches. On GitHub-hosted runners that environment is, in GitHub’s own words, “a new virtual machine (VM) hosted by GitHub” on “virtual machines in Microsoft Azure” — infrastructure outside the mainland, with no mainland-China region published for the hosted runners (worth confirming with GitHub 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 runner that checks your source out onto an offshore VM has no mainland footing to satisfy that.

Door two — injected secrets, build artifacts and your deployment’s supply chain

The second door is PIPL and the integrity of what actually ships to the mainland. A workflow run carries far more than source: it injects your secrets — the built-in GITHUB_TOKEN, deploy keys, cloud and signing credentials, registry tokens — into the run environment, it records the username and email of whoever pushed or triggered the run, it keeps build logs, and it emits the artifacts you deploy. Under the Personal Information Protection Law, holding that actor data and those logs 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. Scoping secrets down and trimming what the run records is part of the fix, but it does not move the run environment on its own. And because your mainland release is built and signed on whichever runner executes the job, the provenance and integrity of what runs in China — built from what source, with which secrets, producing which artifact — are governed across the border too: a software-supply-chain exposure a connectivity check never surfaces.

Why a reachability check misses this

A “can my runner reach GitHub from Shanghai” test answers the wrong question. Connectivity tuning changes how fast and how reliably a job starts and pulls its dependencies — it does not change where your source gets checked out, where your secrets are injected, or where your artifacts are produced. So a pipeline can look perfectly green from inside China while every checkout, every injected secret and every artifact still executes on an offshore VM in Azure. The residency and cross-border questions above are invisible to a reachability probe precisely because the jobs keep running — which is why the move that matters is running the runner in-country, not making the offshore one merely reachable. We publish no first-party measurement of GitHub Actions connectivity from inside China, so we put no figures here; it is something we would measure against your actual pipeline 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 workflows check out, which secrets they hold, and who triggers them — worth settling with counsel before you build.

The lever — map, localize, deliver

Because a genuine self-hosted runner path exists — a system you deploy and manage — there is a real in-country route, and 21YunBox never uses or suggests circumvention of any kind.

Map — inventory which workflows check out proprietary source, which secrets each run holds (GITHUB_TOKEN, deploy keys, cloud and signing credentials, registry tokens), where your runners and artifact store live today, the residency basis, and which pipelines build and deploy to mainland infrastructure.
Localize / govern — run your runners in-country (self-hosted runners, the system you deploy and manage), so the checkout, the injected secrets and the build artifacts stay resident; keep your China deployment pipeline in-country; and minimize what crosses the border.
Deliver — put compliant, in-country self-hosted runners in front of (or in place of) the offshore control plane; 21YunBox stands up the in-country layer without a rebuild.

Making the hosted runner merely reachable is not the answer — your source, secrets and artifacts still execute offshore, and a faster job start does not change that. Keeping the checkout, the secrets and the artifacts in-country is.

Where 21YunBox fits — a compliant overlay, not a migration

You keep using GitHub and the workflows you already wrote. We add the piece a hosted runner cannot provide on its own: a lawful, in-country home for self-hosted runners, so your source checkout, injected secrets and build artifacts stay resident where the law requires, with compliant ICP-filed delivery for 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 move off GitHub Actions. 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 circumvention of any kind.

Get a compliance assessment →

Related reading:

Frequently Asked Questions

Can we just use GitHub-hosted runners from inside China?

Reachability is not the deciding issue. On GitHub-hosted runners your proprietary source is checked out, your secrets are injected, and your artifacts are produced on virtual machines GitHub hosts in Microsoft Azure, outside the mainland. That concentration of source, secrets and artifacts offshore is a data-residency question under the Cybersecurity Law, Article 39 (formerly Article 37), and a PIPL cross-border transfer, regardless of how fast the job starts.

What is a self-hosted runner, and does it fix the residency problem?

GitHub defines a self-hosted runner as a system you deploy and manage to execute jobs from GitHub Actions. Because you deploy and manage it, you choose where it runs: run it on your own machines in-country and the checkout, the injected secrets and the build artifacts stay resident in the mainland. That is the lever — it keeps the sensitive parts of the run in-country rather than moving your code and secrets offshore.

Is this a PIPL problem or a Cybersecurity Law problem?

It can be both. The Cybersecurity Law's localization duty — Article 39 (formerly Article 37) — reaches source and important data for a CIIO or large-volume handler, while PIPL Articles 38–40 govern the actor identities and logs a run holds as a cross-border transfer. Whether, and which mechanism you need, depends on your entity, your data volumes and who triggers your workflows — settle it with counsel before you build.