Funktioniert ButterCMS in China? Offshore-Content-Auslieferung, ICP & die PIPL-Linie
ButterCMS liefert Ihre redaktionellen Inhalte von einem globalen Offshore-CDN (Fastly und Amazon CloudFront) ohne Point of Presence in Festlandchina aus — sie live aus China zu holen, ist also ein Auslieferungsrisiko —, während die ICP-Beian und die PIPL-Pflichten, die über die Rechtmäßigkeit entscheiden, auf der Site sitzen, die ButterCMS einbettet, nicht auf dem CMS. Ein ehrlicher, Compliance-zuerst-Blick.
Funktioniert ButterCMS in China?
Für ButterCMS ist dies zuerst eine Auslieferungsfrage, keine Datenresidenz-Frage. ButterCMS ist ein headless CMS, das Ihre Inhalte Ihrer Site über ein globales CDN ohne Point of Presence innerhalb Festlandchinas reicht, sie live hinter der Großen Firewall abzurufen, ist also ein Erreichbarkeitsrisiko — während die ICP-Beian und die PIPL-Pflichten, die tatsächlich entscheiden, ob Ihre Site rechtmäßig ist, auf der Website ruhen, die ButterCMS einbettet, nicht auf dem CMS.
ButterCMS gibt an, es „is hosted on infrastructure provided by AWS and Heroku“, dass „the content API traffic is served through Fastly“ und dass sein Inhalt „stored at edge locations around the world“ ist. Keiner dieser Edges sitzt innerhalb des Festlands, eine Seite, die Butter zur Anfragezeit abfragt, lehnt sich also an einen Grenz-Hin-und-Rückweg, der stocken oder abbrechen kann. Aber was reist, sind Ihr eigener Text, Ihre Bilder und Blogbeiträge — nicht die personenbezogenen Daten Ihrer Besucher —, ButterCMS erzeugt für sich allein also im Allgemeinen keinen Grenztransfer von Nutzerdaten nach PIPL. Die Pflichten, die über die Rechtmäßigkeit entscheiden — eine ICP-Beian auf inländischem Hosting und PIPL für alle personenbezogenen Daten, die Ihre Site erhebt —, gehören der einbettenden Site. Die Tabelle unten setzt Butters eigenen Wortlaut neben die Regel, die jede Zeile auslöst.
Dies ist eine Risikokarte, kein Urteil — wo die Linie fällt, hängt davon ab, wie Sie die Site hosten, welche Nutzerdaten sie erhebt und ob Sie je personenbezogene Daten als Inhalt speichern. Unser China-Team kann Ihre Exponierung mit Ihnen kartieren →
Compliance-Momentaufnahme
- ! ButterCMS liefert Inhalte von einem globalen Offshore-CDN (Fastly + CloudFront) — kein Festlandchina-Edge
- ! ButterCMS-Inhalte live aus China zu holen, ist ein Erreichbarkeitsrisiko
- ✓ Die Payload sind Ihre eigenen redaktionellen Inhalte, keine Nutzerdaten — ButterCMS wirft keinen eigenen PIPL-Transfer auf
- ! Die öffentliche Festland-Site, die es einbettet, braucht weiterhin eine ICP-Beian — diese Pflicht ist die der Site, nicht die des CMS
- ! Legen Sie personenbezogene Daten in ein Butter-Feld, und sie überqueren die Grenze wie jeder andere Inhalt
Was die offizielle ButterCMS-Dokumentation über China sagt
| Fakt | Primärquelle |
|---|---|
ButterCMS läuft auf einem globalen Offshore-CDN, ohne Point of Presence in Festlandchina. Seine eigenen Infrastruktur-Docs geben an, ButterCMS „is hosted on infrastructure provided by AWS and Heroku“, dass „the content API traffic is served through Fastly, a reliable and quick content delivery platform (CDN)“ und dass Ihre „media assets are stored and delivered via Amazon CloudFront“. Butter beschreibt das Ergebnis als „a global CDN“, dessen Inhalt „stored at edge locations around the world“ ist — ein Offshore-Netzwerk, das das Festland nur von Points of Presence außerhalb erreicht (Schlussfolgerung: Fastly und CloudFront veröffentlichen keinen inländischen Festlandchina-Edge für ein öffentliches .com), Butter-Inhalte werden also immer von jenseits der Grenze bedient. | ButterCMS — Infrastructure & Hosting and CDN & Global Delivery docs, abgerufen 2026-10-07 |
| Ihre Site zieht ButterCMS-Inhalte zur Anfragezeit über die Grenze. Ein Butter-gestütztes Frontend ruft die Content-API — in Butters Worten „through Fastly“ bedient — auf, um jede Seite zu bauen oder zu rendern. Weil dieses CDN keinen Festland-Edge hat, hängt eine Seite, die live aus China von Butter holt, von einem Grenz-Hin-und-Rückweg durch die Große Firewall ab, woher langsame oder zeitweilige Inhalts-Ladevorgänge kommen. Butter merkt sogar an, sein Cache werde „served around the world irrespective of country or region“ — ein globaler Cache, kein inländischer. Das ist ein Auslieferungsrisiko, kein rechtliches. | ButterCMS — CDN & Global Delivery docs, abgerufen 2026-10-07 |
| Die Payload sind Ihre redaktionellen Inhalte, nicht die Daten Ihrer Nutzer — die Compliance-Türen sitzen also auf Ihrer Site, nicht auf ButterCMS. Was Butter speichert und ausliefert, sind die Inhalte, die Ihr Team für die öffentliche Anzeige verfasst — Marketingtexte, Blogbeiträge, Bilder —, nicht die personenbezogenen Daten Ihrer Endnutzer, das durch Butters AWS- und Heroku-Infrastruktur zu routen, erzeugt für sich allein also keinen PIPL-Grenztransfer von Nutzerdaten. Was über die Rechtmäßigkeit entscheidet, ist die öffentliche Site, die diesen Inhalt Festland-Besuchern zeigt: Sie braucht eine ICP-Beian auf inländischem Hosting (Staatsratserlass Nr. 292; MIIT-Erlass Nr. 33), und jede personenbezogene Information, die sie von chinesischen Nutzern erhebt, ist ihre eigene PIPL-Angelegenheit (Art. 38–43; Art. 40; Cybersicherheitsgesetz Art. 39 (vormals Art. 37)). | ButterCMS — Infrastructure & Hosting docs, abgerufen 2026-10-07; State Council Order No. 292; MIIT Order No. 33; PIPL Articles 38–43 & 40; Cybersecurity Law Article 39 (formerly Article 37) |
| Wenn Sie personenbezogene Daten als Inhalt in ButterCMS modellieren, überquert dieser Inhalt die Grenze ebenfalls. Butter speichert, was immer Sie zu modellieren wählen, personenbezogene Daten — Nutzerprofile, Formulareinträge, alles, was eine reale Person identifiziert — in ein Butter-Feld zu legen, sendet sie also offshore an AWS und Heroku wie jede andere Payload, und die PIPL-Grenzübertritts-Regeln (Art. 38–43) heften sich daran. Die saubere Linie ist, Butter für redaktionellen Inhalt zu behalten und personenbezogene Daten herauszuhalten, sodass Datenresidenz nie zum Problem des CMS wird. | ButterCMS — Infrastructure & Hosting docs, abgerufen 2026-10-07; PIPL Articles 38–43 |
Quellen vom 21YunBox Compliance-Team am 7. Oktober 2026 geprüft.
Für ein Festland-China-Publikum spaltet sich „Funktioniert ButterCMS“ in zwei sehr verschiedene Fragen, und es zahlt sich aus, sie auseinanderzuhalten. ButterCMS ist ein headless CMS: Es verwahrt Ihre redaktionellen Inhalte und bedient sie Ihrer Site über eine Content-API, die auf einem globalen CDN läuft. Dieses Netzwerk hat Edge-Standorte rund um die Welt, aber keinen innerhalb Festlandchinas, das ehrliche Risiko auf ButterCMS-Ebene ist also Erreichbarkeit — eine Site, die ihre Inhalte live hinter der Großen Firewall abruft, kann langsam oder unzuverlässig sein. Was ButterCMS nicht tut, ist, Ihr Projekt für sich allein zu einem Datenresidenz-Problem zu machen, denn was es trägt, ist Ihr eigener Text und Ihre eigenen Bilder, nicht die personenbezogenen Daten Ihrer Besucher. Die Melde- und Datenschutz-Pflichten, die tatsächlich entscheiden, ob Ihre auf China ausgerichtete Site rechtmäßig ist, sitzen auf der Site, die ButterCMS einbettet — und diese von der Auslieferungsfrage zu trennen, ist der ganze Sinn dieser Seite.
ButterCMS in China auf einen Blick
| Worüber es entscheidet | In ButterCMS' eigenen Worten |
|---|---|
| Wo es läuft | ButterCMS „is hosted on infrastructure provided by AWS and Heroku“ und bedient Inhalte über Fastly und Amazon CloudFront — ein „global CDN“ mit „edge locations around the world“. Diese Edges sind offshore; keiner ist innerhalb Festlandchinas. |
| Wie Ihre Site Inhalte bekommt | Ihr Frontend fragt Butters Content-API — „served through Fastly“ — zur Anfragezeit ab. Ohne Festland-Point-of-Presence überquert jeder Abruf die Grenze. |
| Was in der Payload steckt | Ihre eigenen redaktionellen Inhalte — Marketingtexte, Blogbeiträge, Bilder —, verfasst für die öffentliche Anzeige, nicht die personenbezogenen Daten Ihrer Endnutzer. Für sich allein ist das im Allgemeinen kein PIPL-Grenztransfer von Nutzerdaten. |
| Die Öffentlichkeit bedienen | Die öffentliche Site, die Butter einbettet und Festland-Besuchern gezeigt wird, braucht eine ICP-Beian auf inländischem Hosting. Diese Pflicht gehört der Site und ihrem Host, nicht dem CMS. |
| Der Grenzfall | Modellieren Sie personenbezogene Daten als Inhalt innerhalb von Butter, und sie verlassen das Festland mit jedem Abruf — und PIPLs Grenzübertritts-Regeln heften sich daran wie an jede andere Payload. |
Erreichbarkeit ist die ehrliche Frage auf ButterCMS-Ebene
ButterCMS ist offen darüber, wo es läuft. Seine Infrastruktur-Dokumentation gibt an, die Plattform „is hosted on infrastructure provided by AWS and Heroku“, dass „the content API traffic is served through Fastly, a reliable and quick content delivery platform (CDN)“ und dass Ihre „media assets are stored and delivered via Amazon CloudFront“. Es fasst die Auslieferung als „a global CDN“ zusammen, dessen Inhalt „stored at edge locations around the world“ ist. Das Wort, das hier die Arbeit tut, ist global: Fastly und CloudFront bedienen das Festland von Points of Presence auf der fernen Seite der Grenze, nicht von innerhalb, eine Anfrage aus Shanghai oder Shenzhen muss also weiterhin hinaus und zurück reisen, um Butters Edge zu erreichen. Diese Distanz — plus die Filterung dazwischen — ist, woher die langsamen Aufbauten und der gelegentlich gescheiterte Abruf kommen. Es ist ein echtes Auslieferungsrisiko, und es ist auch die Hälfte der Frage, die Netzwerk-Design tatsächlich angehen kann. Lesen Sie es als Erreichbarkeit, nicht als Urteil über die Rechtmäßigkeit.
Ein Content-CMS ist für sich allein kein Datenresidenz-Problem
Es ist leicht, „mein CMS läuft auf US-Infrastruktur“ zu sehen und zum Grenzdaten-Alarm zu greifen. Für ein Content-CMS ist das meist das falsche Instrument. Was ButterCMS hält und ausliefert, ist das Material, das Ihr Team für die Öffentlichkeit schreibt — Marketingtexte, Blogbeiträge, Bilder, Dokumentation —, nicht die personenbezogenen Daten der Menschen, die es lesen. Das durch Butters AWS- und Heroku-Backend zu bewegen, ist für sich allein kein Grenztransfer von Nutzerdaten nach PIPL. Das klar zu sagen, ist wichtig: Blähen Sie ein Content-CMS zu einem Datenresidenz-Verstoß auf, erfinden Sie eine Pflicht, die es nie auslöste, während die Pflichten, die real sind, aus dem Fokus gleiten.
Es gibt einen einzigen Grenzfall, der Beachtung verdient. Butter speichert alles, was Sie als Inhalt zu modellieren wählen, in dem Moment also, in dem Sie personenbezogene Daten — ein Nutzerprofil, eine Formular-Einreichung, alles, was eine reale Person kennzeichnet — in ein Butter-Feld legen, verlässt dieser Datensatz nun mit jedem Abruf das Festland, genau wie ein Blogbeitrag, und PIPLs Grenzübertritts-Regeln (Art. 38–43) heften sich daran. Die Disziplin ist einfach: Behalten Sie Butter für redaktionellen Inhalt, behalten Sie personenbezogene Daten in Systemen, die Sie kontrollieren, und die Residenzfrage landet nie auf dem CMS.
Die Compliance-Türen leben auf Ihrer Site, nicht auf dem CMS
Die Pflichten, die entscheiden, ob Ihre auf China ausgerichtete Site rechtmäßig ist, ruhen überhaupt nicht auf ButterCMS; sie ruhen auf der Website, die es einbettet. Eine öffentliche Site, die Festland-Besuchern gezeigt wird, braucht eine ICP-Beian (ICP 备案) nach Staatsratserlass Nr. 292 und MIIT-Erlass Nr. 33, und diese Beian muss an Hosting physisch innerhalb des Festlands gebunden sein. Was es entscheidet, ist, von wo Ihr HTML und Ihr Origin bedient werden — nicht wo Ihr CMS lebt —, ein headless Frontend mit Butter im Rücken braucht also weiterhin sein eigenes inländisches, ICP-gemeldetes Hosting, um für chinesische Nutzer sauber zu laufen. Separat: Jede personenbezogene Information, die Ihre Site von diesen Nutzern erhebt — Anmeldungen, Bestellungen, Support-Tickets —, ist Ihre als Verarbeiter zu verantworten: Mitteilung, gesonderte Einwilligung und ein Transfermechanismus, wenn diese Daten offshore gehen (Art. 38–43), und inländische Speicherung, wenn Sie ein Betreiber kritischer Informationsinfrastruktur oder Verarbeiter großer Mengen sind (PIPL Art. 40; Cybersicherheitsgesetz Art. 39 (vormals Art. 37)). Nichts davon ist Butters zu tragen, und nichts davon wird gelöst, indem Inhalte schneller ankommen.
Dies ist eine Risikokarte, kein Urteil: Ob Ihre Site eine ICP-Beian, inländische Speicherung oder schlicht einen stetigeren Weg zu ButterCMS braucht, hängt davon ab, wie Sie sie hosten, welche personenbezogenen Daten sie erhebt und wer Ihre Nutzer sind — es lohnt, es mit Rechtsbeistand zu klären, bevor Sie bauen.
Wo 21YunBox hineinpasst — eine rechtskonforme Overlay, keine Migration
Sie verfassen weiter in ButterCMS, genau wie heute. Was wir hinzufügen, ist das Stück, das eine global gehostete Content-API nicht kann: rechtskonforme, ICP-gemeldete Auslieferung aus dem Festland heraus, vor Ihren bestehenden Origin gesetzt, sodass Ihre Seiten chinesische Nutzer erreichen, ohne auf einen Grenz-Hin-und-Rückweg zu Butters Edge zu warten — ohne Neuaufbau, ohne zweite Codebasis und ohne Änderung an Ihrem Butter-Workflow. Unser China-Team nimmt die zwei Hälften einzeln: wie zuverlässig Ihre Inhalte ankommen, und die ICP- und PIPL-Pflichten, die auf Ihrer einbettenden Site sitzen, abgewogen gegen Ihre Gesellschaft, Ihr Hosting und die personenbezogenen Daten, die Ihre Site tatsächlich erhebt. ButterCMS bleibt Ihr CMS; die rechtskonforme China-Präsenz wird darum herum gebaut.
Compliance-Einschätzung anfordern →
Weiterführend:
Häufige Fragen
Ist ButterCMS in Festlandchina gesperrt oder nur langsam?
Behandeln Sie es als Erreichbarkeitsrisiko statt als harte Sperre. ButterCMS liefert Inhalte über Fastly und Amazon CloudFront — ein globales CDN, dessen Edge-Standorte „rund um die Welt“ sitzen, keiner davon innerhalb des Festlands —, eine Site, die Butter-Inhalte live aus China abruft, lehnt sich also an einen Grenz-Hin-und-Rückweg durch die Große Firewall. In der Praxis zeigt sich das als langsame oder zeitweilige Inhalts-Ladevorgänge statt als garantierte Sperre, und das Ergebnis verschiebt sich mit Netzwerk, Route und Tageszeit. Diese Auslieferungs-Hälfte ist genau, was inländische Auslieferung vor Ihrem Origin stetigen soll.
Bringt es unsere Site in einen PIPL-Verstoß, ButterCMS zu nutzen?
Nicht für sich allein, obwohl es sich lohnt, mit Rechtsbeistand präzise zu sein. ButterCMS trägt Ihre redaktionellen Inhalte — Text, Bilder, Blogbeiträge —, nicht die personenbezogenen Daten Ihrer Endnutzer, diesen Inhalt durch seine AWS- und Heroku-Infrastruktur zu routen, ist im Allgemeinen also kein PIPL-Grenztransfer von Nutzerdaten. Die PIPL- und ICP-Pflichten hängen an der Site, die Butter einbettet: ihr Hosting, ihre ICP-Beian und alle personenbezogenen Daten, die sie von chinesischen Nutzern erhebt. Die eine Ausnahme ist, personenbezogene Daten als Inhalt innerhalb von Butter zu speichern, was diese Daten ebenfalls in die Grenzübertritts-Frage zieht.
Kann 21YunBox helfen, unsere ButterCMS-Site in China zum Laufen zu bringen?
Ja. Unser China-Team kann die zwei Hälften für Sie trennen — stetigen, wie zuverlässig Festland-Besucher Ihren Butter-gestützten Inhalt erreichen, und die ICP-Beian und die PIPL-Pflichten kartieren, die auf Ihrer einbettenden Site für Ihre Gesellschaft, Ihr Hosting und die Nutzerdaten, die Sie erheben, sitzen — und dann eine ICP-gemeldete, inländische Auslieferung vor Ihren bestehenden Origin setzen, während Ihr ButterCMS-Workflow unangetastet bleibt. Nehmen Sie Kontakt auf, um Ihr konkretes Setup durchzugehen.
