Does Quay Work in China? Data Residency, ICP & Cross-Border Rules
Your private container images on Quay.io bake proprietary code into their layers — often with embedded secrets — and on Red Hat's hosted registry they sit offshore in AWS us-east-1: a data-residency and PIPL cross-border question, not a reachability one. Self-host Red Hat Quay in-country to keep them resident.
Does Quay work in China?
Whether Quay “works” in China is the wrong question — your private container images on Quay.io bake your proprietary code into their layers, and on Red Hat's hosted registry they live offshore. That, not whether a node in Shanghai can pull an image, is what decides whether the setup is defensible.
In Red Hat's own words, Quay.io is “a hosted registry service for storing, building, and distributing container images,” where “developers can create private repositories, ensuring sensitive or proprietary code remains secure within their organization” — a service primarily hosted in AWS us-east-1 in the United States. So your private images, and the credentials, tokens and build config their layers routinely embed, sit outside the mainland, and your China cluster's image supply chain crosses the border on every pull. Held abroad, any personal data or secrets in those layers is a cross-border transfer PIPL governs, and for a CIIO or large-volume handler the data-localization duty (Article 39 (formerly Article 37)) points the other way. Red Hat Quay — the vendor's own self-hostable edition — or a self-hosted registry such as Harbor, run inside the mainland, keeps those private images and embedded secrets resident.
This is a risk picture, not a verdict — your obligations turn on what your private images carry and who pushes them. Our China team can map your Quay residency and image-supply-chain exposure with you →
What Quay's own documentation says about China
| Fact | Primary source |
|---|---|
| In Red Hat's own words: Quay.io is “a hosted registry service for storing, building, and distributing container images and other artifacts,” and “developers can create private repositories, ensuring sensitive or proprietary code remains secure within their organization.” Those private images bake your proprietary code into their layers and routinely embed build credentials, API tokens and config. Quay.io is primarily hosted in AWS us-east-1 in the United States — offshore; Red Hat publishes no mainland-China region for it (confirm current with Red Hat). A node pulling an image is not the same as that code being resident. | Red Hat — About Quay.io overview, retrieved 2026-10-13 |
| A genuine in-country path exists, shipped by the vendor itself: Red Hat Quay, the self-deployable edition of the same registry. Red Hat documents that it “is available as a standalone component or running on top of Red Hat OpenShift” — i.e. you run it on your own infrastructure. Deploy it (or a self-hosted registry such as Harbor) inside the mainland and your private images, build artifacts and the secrets baked into their layers stay resident, with your China cluster's image supply chain kept in-country. | Red Hat — Red Hat Quay product page, retrieved 2026-10-13 |
| For a critical information infrastructure operator or a large-volume handler, personal information and important data collected and generated in 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. Private images and build artifacts held on an offshore registry have no mainland footing to satisfy that. | PRC Cybersecurity Law, Article 39 (formerly Article 37); 2025 amendment in force 2026-01-01 |
| Robot-account and user identities, access logs, the secrets baked into image layers, and any personal data inside a private image, held on an offshore registry, are a PIPL cross-border transfer (Articles 38–40): the handler must give notice, obtain separate consent, and clear one mechanism — a CAC security assessment, the CAC standard contract, or certification. | PRC Personal Information Protection Law, Articles 38–40; CAC cross-border rules (March 2024) |
Sources verified by the 21YunBox compliance team on 2026-10-13.
For a mainland-China operation, the deciding question about Quay is not whether a node in Shanghai can pull a public base image — it is where your private container images live, what they carry, and on what legal basis they got there. Pulling community images is a reachability topic, and not the one that decides whether your setup is defensible. Your private images on Quay.io are different: a container image bakes your proprietary code into its layers, and those layers routinely carry build credentials, API tokens, registry auth and configuration — sometimes with data riding along. Pushed to Quay.io, Red Hat’s hosted registry, that concentrated intellectual property sits offshore, and your China cluster’s image supply chain — which images, with what provenance and integrity, run in the mainland — crosses the border on every pull. Residency and cross-border transfer, not pull latency, are what decide this.
Does Quay work in China? At a glance
| What decides it | What it means for mainland China |
|---|---|
| What your private images hold | A private container image bakes your proprietary code — trade secrets — into its layers, and routinely embeds build credentials, API tokens, registry auth and configuration, plus any data baked into a layer during the build. |
| Where the registry runs | Pushed to Quay.io, private images live on Red Hat's hosted registry, which Red Hat documents as primarily hosted in AWS us-east-1 in the United States — offshore. Red Hat publishes no mainland-China region for Quay.io (confirm current with Red Hat). |
| 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 registry cannot meet. |
| Cross-border transfer | Robot-account and user identities, access logs, the secrets baked into image layers and any personal data inside a private image, held offshore, are a PIPL cross-border transfer (Articles 38–40): notice, a separate consent, and one transfer mechanism. |
| Your deployment's supply chain | A China cluster pulling from an offshore registry runs its image supply chain across the border. A registry mirror or pull-through cache speeds pulls — it does not move your private images or secrets in-country. |
| The residency lever | Red Hat Quay — the vendor's own self-hostable edition — or a self-hosted registry such as Harbor, run inside the mainland, keeps the private images, build artifacts and embedded secrets resident. |
Door one — your private images are proprietary code, and residency follows where they’re hosted
Start with what the registry holds, because that is what China’s law answers to. The public side of Quay.io distributes community images, but that is not the part that decides this. Your private repositories are different: a container image is an artifact that bakes your proprietary code into its layers — internal services, build tooling, a concentrated slice of your intellectual property — and those layers routinely carry baked-in credentials, API tokens, registry auth and configuration, with the occasional fixture of data riding along. In Red Hat’s own words, Quay.io is “a hosted registry service for storing, building, and distributing container images and other artifacts,” where “developers can create private repositories, ensuring sensitive or proprietary code remains secure within their organization.”
That hosting is the point. Quay.io is Red Hat’s hosted service, and Red Hat documents it as primarily hosted in AWS us-east-1 in the United States — with no mainland-China region (something to confirm with Red Hat directly rather than assume). 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 registry holding your proprietary images and the secrets baked into them has no mainland footing to satisfy that.
Door two — image provenance, embedded secrets and cross-border identities
The second door is PIPL and the integrity of what runs in your China cluster. A private registry carries more than image layers: the robot-account and user identities of who pushed, signed and promoted an image, access and audit logs, the credentials and tokens baked into layers, and any personal data that finds its way into image contents or build metadata. Under the Personal Information Protection Law, holding 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. Minimizing the secrets and personal data baked into image layers in the first place is part of the fix, but it does not move the store on its own. And because your China cluster pulls its images from wherever the registry runs, the provenance and integrity of what runs in your China deployment 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 node pull the image from Shanghai” test answers the wrong question. A registry mirror or pull-through cache, or connectivity tuning, changes how fast and how reliably an image pull completes — it does not change where your private images, their embedded secrets and the image provenance actually live. So a setup can look perfectly healthy from inside China while every private image, every token baked into a layer, and every robot-account record still sits offshore in us-east-1. The residency and cross-border questions above are invisible to a reachability probe precisely because the images keep pulling — which is why the move that matters is moving the private store in-country, not making the offshore store merely reachable or mirrored. We publish no first-party measurement of Quay.io 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 storage, a transfer mechanism, a reworked consent flow, an ICP filing for any public-facing developer portal, or some combination depends on what your private images carry, how much, and who pushes them — worth settling with counsel before you build.
The lever — map, localize, deliver
Because Quay ships its own self-hostable edition, there is a genuine first-party in-country path, and 21YunBox never uses or suggests circumvention of any kind.
- Map — inventory which of your images are private (your proprietary code), whether their layers embed credentials, tokens or configuration, where the registry and cluster Secrets live today, the residency basis, and how your China cluster’s image supply chain crosses the border.
- Localize / govern — run the private registry in-country (self-hosted — Red Hat Quay, its own self-hostable edition, or a self-hosted registry such as Harbor in your own infrastructure), so the proprietary images and embedded secrets stay resident; keep your China cluster’s image supply chain in-country; and minimize what crosses the border.
- Deliver — put a compliant, in-country private registry and image delivery in front of (or in place of) the offshore service; 21YunBox stands up the in-country layer without a rebuild.
Making the public registry merely reachable or mirrored is not the answer — your private images and secrets are still offshore, and pulling them faster does not change that. Keeping the private registry and image artifacts in-country is.
Where 21YunBox fits — a compliant overlay, not a migration
You keep using Quay. We add the piece an offshore registry cannot provide on its own: a lawful, in-country home for a self-hosted private registry — Red Hat Quay, the vendor’s own self-hostable edition, or a self-hosted registry such as Harbor — so your proprietary images, build artifacts and embedded secrets stay resident where the law requires, with compliant ICP-filed delivery for the developer access and any public-facing portal in front of it — placed around your existing setup, with no rebuild, no second codebase, and no migration off your toolchain. 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 registry 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
