Does Pulumi Work in China? Data Residency, ICP & Cross-Border Rules
Pulumi's state is a full map of your infrastructure and routinely embeds secrets; by default it lives in the hosted Pulumi Cloud state backend offshore — a data-residency and PIPL cross-border question, not a reachability one. A self-managed state backend in-country keeps state and secrets resident.
Does Pulumi work in China?
Whether you can use Pulumi in China is a data-residency question about your state, not a speed one. Reaching the backend from inside China is a connectivity topic; the risk is legal, not performance.
Pulumi's state is the authoritative map of your entire infrastructure — every resource, input and output your program manages — and it routinely embeds secrets like cloud credentials, database passwords and signing keys. By Pulumi's own documentation, "Pulumi Cloud is the default backend" and "the default experience is to use the hosted Pulumi Cloud" — a managed service that runs offshore. So the map of your infrastructure and the secrets inside it are stored abroad, and your China deployment's provisioning path crosses the border every time state is read or written: a cross-border transfer of personal information that PIPL governs, and for a CIIO or large-volume handler a data-localization duty too. Pulumi's own docs point to the fix — a self-managed state backend you run in-country, so "you gain control over where your state is located."
This is a risk picture, not a verdict — your obligations turn on your data volumes and your role. Our China team can map your Pulumi state exposure with you →
What Pulumi's own documentation says about China
| Fact | Primary source |
|---|---|
| In Pulumi's own words: "Pulumi Cloud is the default backend," and "the default experience is to use the hosted Pulumi Cloud, which takes care of the state and backend details for you." Pulumi Cloud is "a managed backend" that runs offshore, and Pulumi publishes no mainland-China region for the hosted backend. Its state docs add that with a self-managed backend "you gain control over where your state is located" — the residency lever. | Pulumi Docs — State and Backends, retrieved 2026-10-13 |
| Pulumi's state carries your secrets. In Pulumi's own words, "All resource input and output values are recorded as stack state and stored in Pulumi Cloud, in a state file, or in your DIY backend of choice," and the product encrypts sensitive values so that "these values never appear as plain text in your state file." Encrypted or not, cloud credentials, database passwords and API or signing keys live inside the state — so where the backend is hosted decides where those secrets reside. | Pulumi Docs — Secrets, retrieved 2026-10-13 |
| For a critical information infrastructure operator or a large-volume handler, personal information and important data collected and generated in mainland China must be stored inside 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. An offshore state backend has no mainland footing to satisfy this. | China Cybersecurity Law, data-localization rule (Article 39, formerly Article 37); 21YunBox compliance explainer, retrieved 2026-10-13 |
| Holding personal data — operator identities, deployment metadata, and any personal records captured in state — on a backend outside the mainland is a cross-border transfer under PIPL (Articles 38–40): the personal-information handler must give notice, obtain a separate consent, and satisfy one transfer mechanism — a CAC security assessment, the CAC standard contract, or certification. | PIPL Chapter III, Articles 38–40; 21YunBox cross-border explainer, retrieved 2026-10-13 |
Sources verified by the 21YunBox compliance team on 2026-10-13.
For a mainland-China deployment, the deciding question about Pulumi is not whether a pulumi up run in Shanghai can reach its backend or call a cloud API — it is where your state lives, what that state carries, and on what legal basis it got there. Reaching the service is a connectivity topic; it is not the part that decides whether your setup is defensible. Pulumi’s state is the authoritative description of your entire infrastructure topology — every resource, input and output your program manages — and that state routinely embeds secrets: cloud credentials, database passwords, API tokens and signing keys. By Pulumi’s own documentation, the default experience is the hosted Pulumi Cloud, a managed state backend that runs offshore. Held there, that concentrated map of your infrastructure and the secrets inside it sit abroad, and your China deployment’s provision-and-deploy path crosses the border every time state is read or written. Residency and cross-border transfer, not run latency, are what decide this.
Does Pulumi work in China? At a glance
| What decides it | What it means for mainland China |
|---|---|
| What your state holds | Pulumi's state is the authoritative description of your whole infrastructure topology — every resource, input and output — and it routinely embeds secrets: cloud credentials, database passwords, API tokens and signing keys. |
| Where the backend runs | By default, state lives in the hosted Pulumi Cloud managed backend, which runs on offshore infrastructure. Pulumi publishes no mainland-China region for the hosted backend (confirm current with Pulumi). |
| 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 state backend cannot meet. |
| Cross-border transfer | Operator identities, deployment metadata and any personal data captured in state, held offshore, are a PIPL cross-border transfer (Articles 38–40): notice, a separate consent, and one transfer mechanism. |
| Your deployment's provisioning path | A China deployment whose state lives offshore runs its provision-and-deploy path across the border on every update. Connectivity tuning speeds a run — it does not move your state or secrets in-country. |
| The residency lever | A self-managed state backend — object storage you control, or an S3-compatible store such as Minio or Ceph you self-host — run inside the mainland keeps the state and embedded secrets resident. |
Door one — your state is a map of your infrastructure, and residency follows where it’s hosted
Start with what the state holds, because that is what China’s law answers to. Pulumi’s state is not a disposable cache: it is the authoritative, machine-readable description of your infrastructure — every resource Pulumi manages, its inputs, its outputs, and the dependencies between them. That is a concentrated slice of how your systems are built and wired, and for a mainland deployment it describes mainland infrastructure. By Pulumi’s own documentation, “Pulumi Cloud is the default backend” and “the default experience is to use the hosted Pulumi Cloud, which takes care of the state and backend details for you” — a managed service running offshore, with no mainland-China region for the hosted backend (worth confirming with Pulumi 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. An offshore state backend holding that map of your infrastructure has no mainland footing to satisfy that.
Door two — embedded secrets, deployment metadata and your provisioning path
The second door is PIPL and what rides inside the state itself. Pulumi’s own documentation is explicit that state carries secrets: “All resource input and output values are recorded as stack state and stored in Pulumi Cloud, in a state file, or in your DIY backend of choice,” and the product encrypts the sensitive ones so that “these values never appear as plain text in your state file.” Encrypted or not, those values — cloud credentials, database passwords, connection strings, API and signing keys — are in the state, and so are the identifiers and metadata of whoever ran the deployment. Under the Personal Information Protection Law, holding that personal 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. Trimming the secrets and personal data that get written into state is part of good hygiene, but it does not move the store on its own. And because every pulumi up, preview and refresh for your China environment reads and writes that offshore state, the provisioning path for what actually runs in the mainland is governed across the border too — an exposure a connectivity check never surfaces.
Why a reachability check misses this
A “can my run reach the backend from Shanghai” test answers the wrong question. Connectivity tuning changes how fast and how reliably a state operation completes — it does not change where your state, the secrets encrypted inside it, and the map of your infrastructure actually live. So a pipeline can look perfectly healthy from inside China while every byte of state, every credential in it, and every record of who deployed still sits offshore. The residency and cross-border questions above are invisible to a reachability probe precisely because the state keeps reading and writing — which is why the move that matters is moving the state backend in-country, not making the offshore one merely reachable. We publish no first-party measurement of Pulumi Cloud 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 state storage, a transfer mechanism, a reworked consent flow, an ICP filing for any public-facing console or developer portal, or some combination depends on what your state carries, how much, and who your operators are — worth settling with counsel before you build.
The lever — map, localize, deliver
Because Pulumi supports a self-managed state backend you run yourself, there is a real in-country path, and 21YunBox never uses or suggests circumvention of any kind.
- Map — inventory which stacks hold state that describes mainland infrastructure, which secrets (cloud credentials, database passwords, signing keys) that state embeds, where the state backend lives today, and the residency basis for it.
- Localize / govern — run a self-managed state backend in-country (object storage you control, or an S3-compatible store such as Minio or Ceph you self-host), so the state and the secrets inside it stay resident; keep your China deployment’s provisioning path in-country; and minimize what crosses the border.
- Deliver — put a compliant, in-country self-managed state backend in front of (or in place of) the offshore managed backend; 21YunBox stands up the in-country layer without a rebuild.
Making the hosted backend merely reachable is not the answer — your state and the secrets inside it are still offshore, and completing a run faster does not change that. Keeping the state backend and your state in-country is.
Where 21YunBox fits — a compliant overlay, not a migration
You keep using Pulumi and your existing workflow. We add the piece an offshore backend cannot provide on its own: a lawful, in-country home for a self-managed state backend, so your infrastructure state, the secrets inside it and your provisioning path stay resident where the law requires, with compliant ICP-filed delivery for any public-facing console, portal or developer access in front of it — placed around your existing setup, with no rebuild, no second codebase, and no migration off Pulumi. 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 state backend and delivery a defensible China presence needs. We never use or suggest circumvention of any kind.
Related reading:
- Cross-border data transfers under PIPL
- China’s Cybersecurity Law and data localization
- How to get an ICP filing for China
