Heroku China — keep the PaaS or rebuild origin
Heroku China is overseas PaaS. herokuapp China is typically reachable-but-slow from Mainland China; you cannot bind ICP to a US dyno. Keep Heroku for HQ/export, or rebuild origin on China-reachable PaaS.
Heroku China is overseas PaaS. herokuapp China (*.herokuapp.com) is typically reachable-but-slow or degraded from Mainland China. You cannot bind ICP filing to a US Heroku dyno. Keep Heroku for HQ / export-only, or rebuild origin on a China-reachable PaaS or host (Alibaba Cloud / Tencent Cloud class, or a static mirror). This is reach vs rebuild — not a yes/no SKU.
What Heroku China is as overseas PaaS
Hard names your stack decision will use:
- Heroku — Salesforce PaaS that runs apps on dynos plus add-ons (Postgres, Redis, and peers). Default public hostname is
*.herokuapp.com. Landscape labels Heroku Limited — not a categorical block, and not “works as PaaS China.” - herokuapp China — That default hostname as seen from Mainland China. HTML can return 200 from HQ while ordinary users wait on cross-border TTFB, dyno APIs, and add-on hops. Do not freeze one HQ laptop load as proof. Measure first: Core Web Vitals China.
- Regions are not Mainland China — Common Runtime is
usoreu. Private Spaces add Tokyo, Singapore, Mumbai, and other overseas metros. Tokyo / Singapore is still not in-country termination. - ICP bind is impossible on a US dyno — Filing lists Mainland China service IPs. A Heroku dyno is not one of those IPs. Depth: host in Mainland China and ICP filing — domain DNS.
- Same overseas PaaS class as Vercel / Netlify — Frontend/static-plus-functions vs dyno-plus-add-on. Contrast without rewriting those Guides: Vercel and China, Netlify and China. Heroku has no Cloudflare-class in-country network product — see Cloudflare and China.
- Usual rebuild — China-reachable origin on Alibaba Cloud / Tencent Cloud class (SAE, CVM, or equivalent), or a static mirror of what can leave the dyno. Keep Heroku residual for HQ / export-only, off the China hostname.
- TLD does not move the dyno — A
.cnon custom domains is region-agnostic. It does not make Heroku onshore — CN domain China.
Vocabulary first. Next: what must be true before Heroku stays in scope at all.
What must be true before Heroku stays Plan A
Missing a clear keep-vs-rebuild job stops your product team before another “make herokuapp fast in China” sprint is real work.
| Precondition | Why your process stalls |
|---|---|
| Job locked — HQ / export-only vs ordinary Mainland China users on the critical path | A rebuild is staffed while Heroku could stay capped — or herokuapp is kept as Plan A for China users |
Origin named — *.herokuapp.com / custom domain on a US or EU dyno vs China-reachable PaaS or host | Acceleration is bought for a US dyno while Mainland China users still wait on that hop |
| Honest surface inventory — HTML, dyno/API, add-ons (Postgres, Redis, files), and third-party tags | “The page loads” still leaves APIs and add-ons overseas |
| ICP filing scoped only if you choose Mainland China termination — not claimed as a ban on overseas-only Heroku | Filing starts on a US dyno, or teams treat overseas Heroku as illegal |
| Mainland China vantage proof on HTML and dyno/API/add-on hosts — broadband + mobile; HQ laptop is not proof | Overseas QA “passes” while China users wait — same class as website accessible in China |
| Hong Kong / Tokyo / Singapore ≠ Mainland China | A Private Space in Tokyo is reported as PaaS China |
Product teams usually cannot treat “ship the same herokuapp globally” as the Mainland China plan. Naming keep vs rebuild is the floor. SKU orientation lives on Heroku alternatives.
Keep Heroku capped or rebuild the China origin
| Stage | Decision / outcome |
|---|---|
| 1. Name the job | Ordinary Mainland China users on the critical path, or HQ / export-only? |
| 2. If HQ / export-only | Keep Heroku as a capped architecture. Do not market herokuapp China as a China launch |
| 3. If China users are the job | Rule US/EU herokuapp as Plan A. Rebuild origin on a China-reachable PaaS or host (Aliyun / Tencent class) — or a static mirror of what can leave the dyno |
| 4. Inventory hops | HTML, dyno/API, add-ons, tags. Chatty APIs belong with SaaS performance in China |
| 5. If Mainland China termination | Treat ICP filing as a go-live stall; bind host + domain DNS — see ICP filing — domain DNS |
| 6. Prove from Mainland China | Broadband + mobile on origin and leftover Heroku hosts (or China Network Diagnostics). Measure herokuapp first on Core Web Vitals China |
| 7. Cut over, then re-test | China-reachable origin on the China hostname. Keep Heroku residual off that path |
Hard gate — keep capped vs rebuild
Necessity: confusing these two jobs wastes the quarter — either you underfund a China origin, or you rebuild Heroku when HQ / export-only was the job.
| Job | Heroku role | What must already be true |
|---|---|---|
| HQ / export-only | Plan A, capped | China users are not the critical path; herokuapp China limits are named |
| Ordinary Mainland China users | Not Plan A | China-reachable origin named; add-ons remapped or dropped; ICP in motion if you terminate in Mainland China |
| CMS sitting on Heroku | Same fork, plus CMS | Keep vs replace the CMS is a second decision — enterprise CMS China |
| “CDN the herokuapp” | Myth as Mainland China plan | Origin reachability from the user network — not an HTML cache |
Hard gate — PaaS China is origin, not a geo toggle
PaaS China here is a China-reachable origin versus accelerating a US Heroku dyno. Hong Kong / Tokyo / Singapore ≠ Mainland China — see host in Mainland China. A CDN in front of herokuapp is a different architecture with known limits; dynamic dyno and add-on hops still pay the border.
Why herokuapp reach does not bind ICP
Engineering constraints you must design around:
| Constraint | What breaks | What to do |
|---|---|---|
| Overseas dyno | HTML may connect from Mainland China and still feel slow. Dyno/API hops stay in us / eu (or a Private Space metro that is still not in-country). | Keep Heroku capped, or rebuild origin on Aliyun / Tencent class. Do not treat “try herokuapp, then a China host on timeout” as Plan A. |
| Add-ons stay with the region | Postgres and other add-ons provision in the app region — or fail if they cannot. Mainland China users wait on that data hop even when HTML is cached. | Remap data and files onto in-country services when you rebuild. Do not assume “we moved HTML” moved Postgres. |
| Custom domain ≠ onshore | Custom domains are region-agnostic. A .cn or China marketing hostname still answers at the Heroku dyno. | TLD does not make Heroku onshore — CN domain China. Cut China-facing DNS to a filed in-country origin if you terminate there. |
| ICP filing vs US dyno | Filing needs Mainland China service IPs. A US Heroku dyno cannot be that bind. Overseas-only Heroku does not automatically create the duty — and does not become a China launch. | If you terminate in-country, file on the new origin (ICP filing — domain DNS). Do not open a filing pack against herokuapp. |
| HTML 200 ≠ CWV | Reachable-but-slow still fails paint and interaction from Mainland China. Same class as website accessible in China. | Measure herokuapp from Mainland China broadband and mobile before you rebuild — Core Web Vitals China. |
| Same class as Vercel / Netlify | Teams paste a frontend-PaaS playbook onto a dyno app, or the reverse. | Contrast the class, then decide this origin: Vercel, Netlify. Cloudflare China Network is a different product — not a Heroku region toggle. |
herokuapp 200 ≠ PaaS China. A US dyno with a custom domain and a CDN hope is still a capped overseas architecture.
HQ laptop QA → false confidence. Testers outside Mainland China never see the stall, so the ticket never opens.
Tokyo Private Space reported as PaaS China → wrong stack. Closest-Asia is not Mainland China termination.
CDN without rebuild → partial win. Faster HTML does not move dyno APIs or add-ons onshore.
What stalls teams that treat Heroku as PaaS China
- Yes/no SKU thinking — Product treats “Does Heroku work?” as a geo toggle before keep vs rebuild is named. Landscape Limited is an operating signal, not a launch.
- herokuapp as the China origin — Default hostname is confused with a China-reachable PaaS.
- ICP treated as a Heroku ban — or as a checkbox on a US dyno — Filing is skipped on a real in-country origin, or demanded against herokuapp that cannot bind.
- Add-ons assumed local after HTML moves — Postgres, Redis, and file add-ons stay overseas on the China journey.
- Vercel / Netlify playbook pasted on dynos — Static-mirror thinking is staffed while the product is a chatty dyno API. The class is the same overseas PaaS; the rebuild surface is not.
- CMS on Heroku ignored — A marketing CMS still sits on the dyno while the “rebuild” only moved a static sheet. See enterprise CMS China.
- HQ laptop QA — Green screenshots from outside Mainland China close the ticket.
- Hong Kong / Tokyo / Singapore conflated with Mainland China — Regional or Private Space hosting is reported as PaaS China.
- No owner for the remap — The fork stalls because nobody owns HTML vs dyno vs add-on inventory — only “make Heroku work in China.”
What “fixed” means: Mainland China users can complete the journeys you claim on a China-reachable origin; Heroku is named and capped for HQ / export-only if it remains; add-ons on the China path are in-country or gone; ICP filing is done when termination is in Mainland China; proof is from Mainland China broadband and mobile. herokuapp with a China marketing claim is not fixed.
China landing partner when the origin is still a US dyno
Most product teams exploring Mainland China entry need a China landing partner once they stop treating herokuapp as Plan A — to place a China-reachable origin, bind ICP filing when termination is in Mainland China, remap add-ons, run Mandarin consoles, and prove the journey from Mainland China broadband and mobile. Your team still owns whether Heroku stays for HQ / export-only, which app surfaces rebuild, and which residual overseas line to keep; the partner path makes that rebuild executable when those rails are not already in-house. Keeping a capped Heroku line for outside-Mainland China viewers does not remove the need for that China landing partner on the primary China path.
What we can offer?
Heroku China work for Mainland China is a reach vs rebuild decision before any “keep the same herokuapp globally” sprint. Chinaready helps your product team cap overseas PaaS where it belongs — or rebuild origin on rails that Mainland China users can actually complete:
- China Readiness Assessment — Decide whether Heroku stays capped for HQ / export-only, which HTML / dyno / add-on hops sit on the critical path, and whether ICP filing is a go-live stall before a rebuild date.
- China Access Acceleration — Keep China-facing pages reachable and fast from Mainland China vantage so a remapped origin does not die on leftover herokuapp, add-on, or tag hosts.
- China Product Hosting — Place the China-critical origin where ICP adjacency, entity consistency, and a China-reachable PaaS or host stay coherent after Heroku leaves that hostname.
- Mobile App Distribution — Align any China app that still wraps a Heroku API with the same origin and add-on gates — not mistake a global herokuapp feed for a China backend plan.
Contact us when you need a Heroku China keep-capped or rebuild path before you staff another herokuapp sprint.
Frequently asked questions
Does Heroku in China work as the primary origin?
Not as Plan A for ordinary Mainland China users. Heroku China is overseas PaaS. herokuapp China is typically reachable-but-slow or degraded from Mainland China. Landscape labels Heroku Limited. Keep Heroku for HQ / export-only, or rebuild origin on a China-reachable PaaS or host. This is reach vs rebuild — not a yes/no SKU.
What does herokuapp China actually mean?
The default *.herokuapp.com hostname on a Common Runtime or Private Space dyno. HTML can return 200 from HQ while Mainland China users wait on cross-border TTFB, dyno APIs, and add-ons. A custom domain does not move that dyno onshore. Measure herokuapp from Mainland China before you call it launched.
Can we bind ICP filing to a Heroku dyno?
No. ICP filing lists Mainland China service IPs. Heroku Common Runtime regions are United States and Europe; Private Spaces add Tokyo, Singapore, and peers — none are Mainland China termination. You cannot bind filing to a US Heroku dyno. A .cn hostname does not make Heroku onshore.
How is Heroku different from Vercel or Netlify for China?
Same overseas PaaS class for Mainland China reach. Heroku is dyno-plus-add-on app PaaS; Vercel and Netlify are typically static, edge, and functions. None of those US origins become an ICP bind. Depth lives on the Vercel and Netlify Guides — this Guide is keep-capped vs rebuild origin.
Is PaaS China a CDN in front of Heroku?
No. PaaS China for this job is a China-reachable origin (Alibaba Cloud / Tencent Cloud class, or a static mirror) plus ICP when you terminate in Mainland China. A CDN in front of herokuapp is a different architecture with known limits. Dynamic dyno and add-on hops still pay the border.
Can product teams finish a Heroku China rebuild without Mainland China ops?
Usually no. China-reachable hosting, ICP host bind when termination is in-country, add-on remap, Mandarin consoles, and Mainland China vantage proof sit on rails most global teams lack. That is when a China landing partner becomes the realistic path.
