Funktioniert Django in China? Datenresidenz, ICP & Grenzregeln
Django ist quelloffener Python-Code, den Sie auf Ihren eigenen Servern betreiben, es ist also residenz-neutral — es läuft in Peking genauso wie in Frankfurt. Die China-Frage ist, wo Sie es deployen und wo seine Datenbank lebt: Eine auf das Festland ausgerichtete App schuldet ICP und MLPS, und die personenbezogenen Daten in ihrer Datenbank und Admin fallen unter PIPL.
Funktioniert Django in China?
Django ist quelloffener Python-Code, den Sie auf Ihren eigenen Servern betreiben, das Framework selbst hat also kein China-Residenz-Problem — es läuft in einem Pekinger Rechenzentrum genauso wie in einem Frankfurter. „Funktioniert Django in China?“ ist eigentlich eine Deployment-und-Daten-Frage: wo die App läuft und wo ihre Datenbank lebt.
Richten Sie Django auf ein Festland-Publikum, und der Host schuldet eine ICP-Beian (备案) und MLPS (等级保护) als Betreiber. Die personenbezogene Information in der Datenbank der App und ihrer eingebauten Admin wird durch PIPL geregelt; eine Offshore-Datenbank macht die Daten von China-Nutzern zu einem Grenztransfer (Artikel 38–40: Mitteilung, eine gesonderte Einwilligung und ein Transfermechanismus), und ein Betreiber kritischer Informationsinfrastruktur oder Verarbeiter großer Mengen muss sie im Festland halten (Cybersicherheitsgesetz Art. 39 (vormals Art. 37)). Paket-Abrufe von PyPI und Absturz-Telemetrie leiten standardmäßig offshore.
21YunBox stellt eine ICP-gemeldete, MLPS-geeignete inländische Grundlage mit Ihren ansässigen China-Daten auf und liefert die auf China ausgerichtete Oberfläche vor Ihrer bestehenden Django-App aus — ohne Neuaufbau und niemals über Umgehung. Behandeln Sie die Einzelheiten als ein mit Rechtsbeistand zu klärendes Risiko.
Compliance-Momentaufnahme
- ! Django ist quelloffener Python-Code — es läuft in China auf Ihren eigenen Servern problemlos
- ! Eine auf das Festland ausgerichtete Django-App schuldet eine ICP-Beian (备案) und MLPS auf ihrem Host
- ! Ihre Datenbank und die Django-Admin halten die personenbezogenen Daten — PIPL regelt es
- ! Eine Offshore-Datenbank macht die personenbezogenen Daten von China-Nutzern zu einem Grenztransfer
- ! pip-/PyPI-Abrufe, Telemetrie und Drittanbieter-APIs leiten standardmäßig offshore
- ✓ Django im Inland auf ICP-gemeldeter, MLPS-bereiter Infrastruktur mit ansässigen Daten betreiben — wir richten es ein
Was die offizielle Django-Dokumentation über China sagt
| Fakt | Primärquelle |
|---|---|
| Django ist quelloffener Code, den Sie selbst betreiben. Djangos Website nennt es „a high-level Python web framework that encourages rapid development“ und erklärt unverblümt „It's free and open source.“ Es gibt keinen gehosteten Django-Dienst und keine inländische Region zur Auswahl — es läuft, wohin Sie es deployen, das Festland eingeschlossen. | Django Software Foundation — djangoproject.com homepage („Meet Django“), abgerufen 2026-10-14 |
| Sie wählen die Datenbank und wo sie läuft — Django nicht. Djangos Dokumentation sagt, es „officially supports the following databases: PostgreSQL, MariaDB, MySQL, Oracle, SQLite.“ Das ORM formt Ihr Datenmodell; die Datenbank-Engine und der Server, auf dem sie sitzt, sind Ihre Deployment-Wahlen — was dort ist, wo Residenz tatsächlich entschieden wird. | Django documentation, „Databases“ (docs.djangoproject.com), abgerufen 2026-10-14 |
| Ein auf das Festland ausgerichtetes Deployment schuldet eine ICP-Beian und MLPS. Jede App, die Nutzer im Festland bedient, muss auf einer Hosting-Ressource mit einer ICP-Beian (备案) laufen, und das System trägt MLPS-(等级保护-)Pflichten als Betreiber — Pflichten, die sich an Ihr Deployment heften, nicht an das Django-Framework. | 21YunBox — How to get an ICP filing for China (备案), abgerufen 2026-10-14 |
| Die personenbezogenen Daten von China-Nutzern, offshore gesendet, sind ein Grenztransfer. Unter PIPL (Artikel 38–40) braucht eine Django-App, die die personenbezogene Information von Festland-Nutzern in eine Offshore-Datenbank schreibt, Mitteilung, eine gesonderte Einwilligung und einen Transfermechanismus; ein Betreiber kritischer Informationsinfrastruktur oder Verarbeiter großer Mengen muss diese Daten im Festland halten (Cybersicherheitsgesetz Art. 39 (vormals Art. 37)). | 21YunBox — Cross-border data transfers under PIPL (Articles 38–40), abgerufen 2026-10-14 |
Quellen vom 21YunBox Compliance-Team am 14. Oktober 2026 geprüft.
Für ein Festlandchina-Publikum ist das Erste, was zu Django zu klären ist, dass die Frage nicht ist, ob es lädt, und eigentlich gar nicht Django betrifft. Django ist ein quelloffenes Python-Web-Framework — Sie installieren es aus einem Paketindex und betreiben es innerhalb Ihrer eigenen Anwendung, auf welchem Server auch immer Sie deployen. Für sich ist es residenz-neutraler Code: Es hält keine eigenen Daten und funkt nichts nach Hause. Es läuft in einem Pekinger Rechenzentrum und einem Frankfurter identisch. „Funktioniert Django in China“ löst sich also in eine andere Frage auf — eine Deployment-und-Daten-Frage: Wo läuft die App, wo lebt ihre Datenbank, und überquert die personenbezogene Information, die sie von China-Nutzern erhebt, die Grenze, um Infrastruktur zu erreichen, die im Ausland sitzt? Dieser Grenzübertritt ist das Compliance-Ereignis — nicht die Umlaufzeit und nicht das Framework.
Django in China auf einen Blick
| Was es entscheidet | In Djangos eigenen Worten — und Chinas Recht |
|---|---|
| Wo die App tatsächlich läuft | Django ist quelloffener Code, den Sie auf Ihrem eigenen Server deployen; es gibt keinen gehosteten Django-„Dienst“ mit einer Region zur Auswahl, das Framework selbst ist also residenz-neutral und läuft im Inland einwandfrei. Was nicht neutral ist, ist der Host, auf den Sie deployen: Eine App, die Festland-Nutzer bedient, sollte auf einer Hosting-Ressource mit einer ICP-Beian (备案) sitzen, und das System trägt MLPS-(等级保护-)Pflichten als Betreiber. |
| Die Datenbank, an die Sie es verdrahten | Djangos Dokumentation sagt, es „officially supports the following databases: PostgreSQL, MariaDB, MySQL, Oracle, SQLite.“ Das ORM und Ihre Modelle formen die Daten; die Datenbank-Engine und der Server, auf dem sie sitzt, sind Deployment-Wahlen, die Sie treffen — was genau dort ist, wo Residenz entschieden wird, nicht durch Django. |
| Die personenbezogenen Daten, die es hält | Django ist „batteries-included“: Es liefert ein Nutzer-Authentifizierungs-System und eine eingebaute Admin-Site, standardmäßig speichert die App also Nutzerkonten, gehashte Passwörter, Sitzungen und was auch immer Ihre Modelle erheben. Das ist personenbezogene Information unter PIPL — und sensible personenbezogene Information nach Artikel 28, wo behördliche Ausweise, Finanz- oder Gesundheitsdaten auftauchen. Die Admin-Konsole ist ein direktes Fenster auf all das. |
| Daten, die die Grenze zu einer Offshore-Datenbank überqueren | Wenn die personenbezogene Information eines Festland-Nutzers in eine im Ausland gehostete Datenbank geschrieben wird, ist das ein Grenztransfer unter PIPL (Artikel 38–40): Mitteilung, eine gesonderte Einwilligung und ein Transfermechanismus — eine CAC-Sicherheitsbewertung, der CAC-Standardvertrag oder eine Zertifizierung. Ein Betreiber kritischer Informationsinfrastruktur oder Verarbeiter großer Mengen muss personenbezogene China-Information im Festland speichern (Cybersicherheitsgesetz Art. 39 (vormals Art. 37)). |
| Ausgehende Abhängigkeiten | Django und seine Pakete installieren von PyPI mit pip, und ein Festland-Build, der requirements.txt auflöst, erreicht diesen Index standardmäßig offshore. Absturz- und Performance-Telemetrie und jede Drittanbieter-API, die die App zur Laufzeit aufruft, können ebenfalls ins Ausland leiten — ein Lieferketten- und Residenz-Belang, der mit der Runtime einhergeht. |
| Erreichbarkeit ist nicht die Achse | Dass pip install gelingt und die Seite rendert, sagt Ihnen nichts darüber, ob das Deployment und seine Daten dort sitzen durften, wo sie sitzen. Die Entscheidung hängt von der Residenz ab — wo die App und ihre Datenbank zur Ruhe kommen und auf welcher rechtlichen Grundlage die personenbezogenen Daten sich bewegen. Diese Seite veröffentlicht keine erstmalige Latenzzahl; Geschwindigkeit ist die falsche Achse. |
Das Framework läuft, wo Sie es betreiben — das Deployment entscheidet also die Residenz
Beginnen Sie bei dem, wo Django läuft, denn die ganze Frage ruht darauf. Django ist ein Framework, das Sie zu Ihrer eigenen Codebasis hinzufügen: Seine Homepage nennt es „a high-level Python web framework that encourages rapid development“ und merkt an, dass „It’s free and open source.“ Es gibt kein gehostetes Django, zu dem man sich verbinden könnte, und keine inländische Region zur Auswahl — das Framework wird innerhalb welcher Anwendung auch immer Sie deployen ausgeführt, die ebenso leicht auf einem Festland-Server sitzen kann wie irgendwo sonst. In diesem Sinne ist Django aus China erreichbar und nutzbar auf eine Weise, wie es ein blockierter Verbraucherdienst nicht ist, und es kann vollständig im Inland laufen.
Was das auch bedeutet, ist, dass Django niemals Ihre Residenz-Haltung setzt — Ihr Deployment tut es. Zwei Wahlen tragen das Gewicht. Die erste ist der Host. Eine App, die Nutzer im Festland bedient, sollte auf einer Hosting-Ressource laufen, die eine ICP-Beian (备案) trägt, und das System schuldet MLPS-(等级保护-)Pflichten als Betreiber eines inländischen Informationssystems. Eine Offshore-VM, auf die Festland-Nutzer treffen, ist die eigentliche Exponierung — und das ist eine Deployment-Entscheidung, keine Eigenschaft von Django. Die zweite Wahl ist die Datenbank, die dort ist, wo die Daten tatsächlich leben.
Die Datenbank und die Admin halten die personenbezogenen Daten
Eine Django-Anfrage ist kein neutraler Text, denn Django ist „batteries-included“ by design. Von Haus aus liefert es ein Nutzer-Authentifizierungs-System und eine eingebaute administrative Schnittstelle, sobald Sie also eine App aufstellen, speichert sie Nutzerkonten, gehashte Passwörter, Sitzungs-Datensätze und welche Felder auch immer Ihre Modelle definieren. Djangos eigene Dokumentation ist explizit, dass es „officially supports the following databases: PostgreSQL, MariaDB, MySQL, Oracle, SQLite“ — das ORM gibt Ihnen eine datenbank-agnostische Art, Ihre Daten zu beschreiben, aber Sie wählen die Engine und, entscheidend, den Server, auf dem sie läuft. Das Framework formt die Daten; es entscheidet nicht, wo die Daten leben.
Das ist wichtig, weil die Datenbank und die Django-Admin dort sind, wo sich die personenbezogene Information konzentriert. Die Admin-Site an der Admin-URL der App ist eine direkte Konsole auf jeden Datensatz — Nutzerkonten, Kontaktdaten, Bestellungen, was auch immer die Modelle halten. In dem Moment, in dem ein Nutzer in China personenbezogene Information übermittelt und Ihre App sie in eine außerhalb des Festlands gehostete Datenbank schreibt, ist dieser Schreibvorgang ein Grenztransfer unter Chinas Gesetz zum Schutz personenbezogener Daten. PIPL legt die Pflicht auf den Verarbeiter — Sie: Artikel 38–40 erfordern Mitteilung, eine gesonderte Einwilligung und einen Transfermechanismus (eine CAC-Sicherheitsbewertung, den CAC-Standardvertrag oder eine Zertifizierung), und Artikel 28 fügt erhöhte Pflichten hinzu, wo die Daten sensibel sind — behördliche Ausweise, Finanz-, Gesundheits-, biometrische oder Minderjährigen-Information. Und wenn Ihre Organisation kritische Informationsinfrastruktur betreibt oder personenbezogene Information in großem Umfang handhabt, fügt das Cybersicherheitsgesetz eine Datenlokalisierungs-Pflicht hinzu — Art. 39 (vormals Art. 37; umnummeriert durch die Änderung von 2025, in Kraft am 1. Januar 2026, Substanz unverändert) verlangt, dass von solchen Betreibern im Inland erhobene und erzeugte personenbezogene Information im Inland gespeichert wird, mit einer Sicherheitsbewertung vor jedem Export.
Abhängigkeiten und Telemetrie erreichen standardmäßig das Ausland
Es gibt einen dritten Strang, den eine Framework-Seite unverblümt benennen sollte. Ein Django-Deployment ist nicht nur Ihr Code — es ist Ihr Code plus ein Baum von Drittanbieter-Paketen, von PyPI durch pip aufgelöst, wenn Sie bauen. Eine Build- oder Deployment-Pipeline, die im Festland läuft, erreicht diesen Index bei jeder Auflösung offshore, Ihre Lieferkette überquert die Grenze also routinemäßig, und ein privates Paket, das Zugangsdaten oder Tokens einbettet, überquert mit. Darüber hinaus senden die Absturz-Meldungs- und Performance-Telemetrie-Agenten, die üblicherweise in eine Django-App verdrahtet sind, und jede Drittanbieter-API, die die App zur Laufzeit aufruft, ihre Payloads dorthin, wo diese Dienste gehostet werden — häufig ins Ausland. Nichts davon ist ein Grund, Django nicht zu nutzen; es ist schlicht eine zweite Oberfläche, jenseits der Nutzer-Datenbank, an der Daten und Abhängigkeiten das Land verlassen, es sei denn, Sie halten die Pipeline und diese Aufrufe bewusst im Inland.
Warum eine Erreichbarkeits-Prüfung dies verfehlt
Ein Erreichbarkeits- oder Latenz-Test pingt einen Endpunkt an und meldet, ob er antwortet und wie schnell. Für Django beantwortet dieser Test die falsche Frage. Erstens gibt es keinen „Django-Endpunkt“ zum Anpingen — das Framework läuft innerhalb Ihrer App, ein grünes Licht bei pip install oder eine schnell rendernde Seite sagt Ihnen also nichts darüber, wo die App und ihre Datenbank enden. Zweitens ist das, was Compliance tatsächlich entscheidet, für eine Sonde unsichtbar: ob der Host eine ICP-Beian trägt und seine MLPS-Pflichten erfüllt, ob die Datenbank im Festland sitzt, ob die personenbezogene Information, die zu ihr überquert, sensibel oder „wichtige Daten“ ist und ob Ihre Abhängigkeits-Abrufe und Telemetrie ins Ausland leiten. Das sind Deployment- und Rechts-Fakten, keine Netz-Fakten. Das ist die Hälfte, die eine reine Geschwindigkeits- oder Erreichbarkeits-Sicht nicht liefern kann — und die Hälfte, mit der wir führen.
Der rechtmäßige Weg — kartieren, lokalisieren, ausliefern
Für ein quelloffenes Framework ist 21YunBox’ Rolle fokussiert, und wir sagen es unverblümt: Es gibt kein „inländisches Django“, das wir Ihnen verkaufen könnten — das Framework gehört bereits Ihnen zum Betreiben, auch im Inland. Unser Wert liegt in drei Zügen.
Zuerst kartieren wir die Exponierung: wo Ihre Django-App tatsächlich deployt ist, wo ihre Datenbank lebt, welche personenbezogene Information ihre Modelle und Admin halten (und ob irgendetwas davon sensibel oder „wichtige Daten“ ist) und welche Abhängigkeits-Abrufe, Telemetrie-Agenten und Drittanbieter-APIs offshore leiten — all das gesetzt gegen die ICP-/MLPS-Pflichten auf dem Host und PIPLs Grenzregeln, Artikel 28 und das Cybersicherheitsgesetz, sodass Sie und Ihr Rechtsbeistand die Leitplanken setzen können. Zweitens helfen wir Ihnen, zu lokalisieren, was nicht rechtmäßig im Ausland sitzen kann: die Django-App im Inland auf ICP-gemeldeter, MLPS-geeigneter Infrastruktur betreiben, die personenbezogene Information von China-Nutzern in einer Festland-ansässigen Datenbank halten und Abhängigkeiten von einem inländischen Index auflösen, statt bei jedem Build offshore zu greifen. Das ist eine China-rechtmäßige Grundlage, niemals ein Weg um die Regeln herum. Drittens liefern wir Ihre auf China ausgerichtete Oberfläche aus — die App- und API-Edge, auf die Ihre Festland-Nutzer treffen — über ICP-gemeldete, inländische Infrastruktur (der 21YunBox Optimizer), vor dem Stack, den Sie bereits betreiben, ohne Neuaufbau und ohne zweite Codebasis.
21YunBox ist ein rechtskonformer Overlay, keine Migration, und ein Partner der Werkzeuge, die Sie nutzen, kein Konkurrent zu ihnen. 21YunBox nutzt oder empfiehlt niemals irgendeine Form von Umgehung. Das Ergebnis ist ein Setup, das legal und rechtskonform für Ihre Nutzer in China läuft.
Compliance-Einschätzung anfordern →
Weiterführende Lektüre:
- Wie man eine ICP-Beian für China erhält
- Grenzüberschreitende Datentransfers unter PIPL
- Chinas Gesetz zum Schutz personenbezogener Daten
- Chinas Cybersicherheitsgesetz (Datenlokalisierung, Artikel 39)
Häufige Fragen
Muss Django selbst für China „rechtskonform gemacht“ werden?
Nein — Django ist quelloffener Python-Code, und das Framework läuft auf einem Festland-Server oder einem Offshore-Server identisch. Es gibt keinen Django-Dienst mit einer Region zur Auswahl, Compliance wird also durch Ihr Deployment entschieden, nicht durch das Framework: wo Sie die App hosten, wo ihre Datenbank sitzt und welche personenbezogenen Daten sie von China-Nutzern erhebt. Betreiben Sie es im Inland mit ansässigen Daten, und das Framework ist kein Thema.
Wo schafft eine Django-App tatsächlich China-Datenresidenz-Exponierung?
An zwei Stellen, die Sie wählen, nicht in Django. Erstens der Host: Eine App, die Festland-Nutzer bedient, sollte auf einer ICP-gemeldeten (备案) Festland-Hosting-Ressource sitzen und trägt MLPS-(等级保护-)Pflichten als Betreiber. Zweitens die Datenbank und die Django-Admin, die Nutzerkonten, Sitzungen und was auch immer Ihre Modelle erheben halten — personenbezogene Information unter PIPL. Wenn diese Datenbank offshore sitzt, betreiben Sie einen Grenztransfer (Artikel 38–40). Paket-Registries wie PyPI und Absturz-/Analytik-Telemetrie fügen einen ausgehenden Lieferketten-Winkel obendrauf hinzu.
Was ist der rechtskonforme Weg, Django für China zu betreiben?
Halten Sie das Deployment und die Daten im Inland: Betreiben Sie die Django-App auf ICP-gemeldeter, MLPS-geeigneter Infrastruktur, halten Sie die personenbezogene Information von China-Nutzern in einer Festland-ansässigen Datenbank und lösen Sie Abhängigkeiten von einem inländischen Index auf, statt bei jedem Build offshore zu greifen. 21YunBox kartiert diese Exponierung, lokalisiert, was ansässig bleiben muss, und liefert die auf China ausgerichtete Oberfläche über den 21YunBox Optimizer vor der App aus, die Sie bereits betreiben — ohne Neuaufbau, ohne zweite Codebasis und niemals ein Weg um die Regeln herum.
