Does Composer (Packagist) Work in China? Data Residency, ICP & Cross-Border Rules
Your private Composer packages are proprietary PHP code — trade secrets — that often embed API tokens and secrets. Packagist.org and hosted private registries run offshore with no mainland-China instance, so that code and your supply chain sit abroad. Self-hosting a private repo in-country is the residency lever under PIPL.
Does Composer (Packagist) work in China?
The real China question for Composer is not whether your build can reach packages — it is where your private packages live. Your organization's private, scoped Composer packages are proprietary source code (trade secrets), and they routinely carry API tokens, deploy keys and config secrets. Hosted on Packagist.org or on a hosted private registry, that concentrated code and those secrets sit offshore — a data-residency and trade-secret exposure — while your China build's dependency supply chain runs across the border on every resolve.
If any package or test fixture carries personal data of people in China, moving it offshore is a cross-border transfer under PIPL; for a critical information infrastructure operator the Cybersecurity Law Article 39 (formerly Article 37) adds an in-country storage duty.
The lever is a self-hosted, in-country private Composer repository (Satis, or an on-premise private registry) that keeps your proprietary code and embedded secrets resident, with your China build's supply chain in-country — never any form of circumvention. Treat the specifics as a risk to confirm with counsel.
What Composer (Packagist)'s own documentation says about China
| Fact | Primary source |
|---|---|
| Packagist.org is the public, offshore PHP package registry — there is no mainland-China instance. Packagist's own About page states: "Packagist is the default Composer package repository. It lets you find packages and lets Composer know where to get the code from," and that it "aggregates public packages that anyone can install with Composer." | Packagist.org, "About" (packagist.org), retrieved 2026-10-13 |
| Composer supports a self-hosted, in-country private registry. Composer's own "Handling private packages" documentation states that Satis "is open source but only a static composer repository generator" that "can be used to host the metadata of your company's private packages, or your own," and that Private Packagist is "available as a hosted SaaS solution or as an on-premise self-hosted package." | Composer documentation, "Handling private packages" (getcomposer.org), retrieved 2026-10-13 |
| Shipping China personal data offshore is a regulated cross-border transfer. If a private package, build artifact or test fixture carries personal information of people in mainland China, sending it to an offshore registry engages PIPL Articles 38–40: notice, a separate consent, and one transfer mechanism — a CAC security assessment, the CAC standard contract, or certification. | PIPL Chapter III, Articles 38–40 (Personal Information Protection Law of the PRC); 21YunBox cross-border data transfer explainer, retrieved 2026-10-13 |
| A critical information infrastructure operator faces an in-country storage duty. China's Cybersecurity Law Article 39 (formerly Article 37) requires personal information and important data generated in mainland China to be stored in-country — a residency obligation an offshore-only registry cannot meet. | Cybersecurity Law of the PRC, Article 39 (formerly Article 37) (amended CSL, effective 2026-01-01); 21YunBox data-localization explainer, retrieved 2026-10-13 |
Sources verified by the 21YunBox compliance team on 2026-10-13.
Ask whether Composer “works” in mainland China and the honest answer does not start with whether your build can pull packages quickly from Shanghai. Composer is PHP’s dependency manager, and Packagist.org is the public registry it resolves against — but the compliance question lives on the other face of a registry. Your organization’s private, scoped Composer packages are your proprietary source code — trade secrets — and they routinely carry API tokens, deploy keys and config secrets, and sometimes personal data sitting in a test fixture. Hosted on Packagist.org or on a hosted private registry, that concentrated code and those secrets live offshore, outside the mainland, and your China build’s dependency supply chain — what code enters your China deployment, with what provenance and integrity — runs across the border every time it resolves. Whether the registry is reachable is real, but it is the least of what you are deciding.
Composer in China at a glance
| What decides it | For Composer (Packagist) |
|---|---|
| Where it runs | Packagist.org is, in its own words, "the default Composer package repository" — a public registry hosted offshore. Private packages live on a hosted private registry (for example Private Packagist's SaaS) unless you self-host. There is no mainland-China instance of either. |
| What it holds | Your private, scoped packages are your proprietary PHP source code — trade secrets. They routinely embed API tokens, deploy keys and config secrets, and sometimes personal data left in a test fixture. That is your most concentrated IP, not community dependencies. |
| Where that data sits | Offshore, unless you self-host. Concentrating proprietary code and embedded secrets on a registry abroad is a data-residency and trade-secret exposure; any personal data inside a package or fixture becomes a cross-border transfer PIPL governs. |
| Your dependency supply chain | What code enters your China deployment — and its provenance and integrity — is decided at resolve and install time. Run the private registry offshore and that supply chain crosses the border on every build, outside your in-country control. |
| A self-hosted option? | Yes. Composer's docs describe Satis, an open-source "static composer repository generator" that hosts "the metadata of your company's private packages," and note Private Packagist ships "as an on-premise self-hosted package." Run one in-country to keep code and secrets resident. |
| Is it reachable? | Whether the build can resolve packages from the mainland is a delivery question — separate from, and lesser than, whether you are cleared to hold this proprietary code and these secrets offshore at all. |
Where your private packages live — and that settles the first question
A package registry has two faces. One is the public, open-source face: pulling community dependencies, which is a reachability and mirroring topic. The other is the one that decides the China question — your own private packages. Packagist.org is, by its own About page, “the default Composer package repository” that “aggregates public packages that anyone can install with Composer”; it is a single hosted service run offshore, with no mainland-China instance. Your private packages do not go there — they sit on a hosted private registry (such as Private Packagist’s SaaS) unless you host your own. Either way, the private packages that hold your proprietary code and your secrets rest abroad the moment they are published. That single fact decides the compliance question before reachability is ever measured: this is not about whether composer install finishes quickly, but about where your trade-secret code and embedded credentials are stored.
Prong one — your private packages are proprietary code and embedded secrets, held offshore
Composer’s job on this axis is to store and distribute your private packages, and those packages are your most concentrated intellectual property: proprietary PHP source that you deliberately did not open-source. Inside them, in practice, ride the API tokens, deploy keys, database credentials and config secrets your services use — including the keys that reach systems inside China — and, now and then, personal data left in a test fixture. Hosted on a registry run offshore, that corpus of code and secrets rests outside the mainland, concentrated in one place abroad. If any of it is the personal information of people in China, moving it offshore engages the Personal Information Protection Law: notice, a separate consent, and one cleared transfer mechanism — a CAC security assessment, the CAC standard contract, or certification, under PIPL Articles 13/23 and 38–40. For a critical information infrastructure operator or a large-volume handler, personal information generated in China must be stored in the mainland (Cybersecurity Law Article 39 (formerly Article 37); PIPL Article 40) — a residency duty an offshore-only registry cannot meet. A check that only confirms the build resolves never sees that your proprietary code and your secrets live abroad.
Prong two — your China build’s dependency supply chain crosses the border
Composer does not only store code; it assembles it. Every composer install or composer update resolves your dependency graph against a registry and pulls the packages that become your running China deployment. When the private registry that serves those packages is offshore, your China build’s supply chain — what code enters the deployment, from where, with what provenance and integrity — runs across the border on every build, outside your in-country governance. That is the distinctive second half a reachability probe never sees: it can confirm the registry answered, but it cannot see that the trusted private packages feeding your China release are governed abroad, nor that your secrets travel with them. A legitimate in-country registry mirror or cache can speed and harden how public dependencies are fetched, but mirroring the public face does not move your private packages or your supply chain in-country — your proprietary code and secrets are still offshore.
Why a reachability check misses all of this
A test that only asks “can the build pull packages from Shanghai?” measures the wrong thing. It cannot see that your private packages — your proprietary code — are held on a registry outside the mainland, it cannot see the API tokens and credentials embedded inside them, and it cannot see the notice-consent-and-mechanism duties that attach to any China personal data in a package or fixture. Making the public registry merely reachable or mirrored does not move the regulated code, the secrets or the supply chain in-country, and it does not create the transfer basis PIPL requires. Reaching a Chinese audience and being cleared to hold and carry your private code and secrets are two different tests — and only one of them shows up on a latency chart.
Where 21YunBox fits — map, localize, deliver
We do not ask you to abandon Composer or Packagist. We add the layer a hosted, offshore registry cannot. Map: we inventory which of your packages and build artifacts are private — your proprietary code — whether they embed secrets, where that private registry is hosted, and what your China build’s dependency supply chain pulls in. Localize and govern: we help you run the private registry and artifact store in-country, so proprietary code and embedded secrets stay resident — Composer supports this directly through a self-hosted Satis repository (a static Composer repository generator for your private package metadata) or an on-premise private registry — keep your China build’s supply chain in-country, and minimize what crosses the border. Deliver: we stand up the compliant in-country private registry and artifact delivery in front of (or in place of) the offshore cloud, and ICP-file any China-facing surface — no rebuild, no second codebase. 21YunBox never uses or suggests circumvention of any kind.
This is a risk map, not a verdict: whether you owe notice and consent, a transfer mechanism, in-country storage, an ICP filing, or some combination depends on your entity, your data volumes and what your packages and fixtures carry — worth settling with counsel before you ship Composer-built releases to China-facing work.
Related reading:
- Cross-border data transfers under PIPL
- China’s Personal Information Protection Law
- China’s Cybersecurity Law and data localization
- How to get an ICP filing for China
