Öffentlicher Datenexport

DiGeKo veröffentlicht einen importierbaren Ausgangsdatenstand für neue CMS-Instanzen. Er besteht aus einem Strapi-Export mit Inhalten, Dateien und Schemas sowie einer SHA-256-Prüfsumme.

Das Prinzip von latest.json

latest.json enthält nicht selbst die Kategorien und Stories. Die Datei ist eine stabile Adresse, die auf das jeweils aktuelle, unveränderliche Releaseverzeichnis zeigt:

latest.json
  ├── manifest → releases/<version>/manifest.json
  ├── file ─────→ releases/<version>/digeko-cms-data.tar.gz
  ├── checksum ─→ releases/<version>/digeko-cms-data.tar.gz.sha256
  └── status ────→ status.json

Ein typischer Zeiger enthält:

{
  "version": "2026-07-17T10-30-00Z",
  "self": "https://…/data/latest.json",
  "manifest": "https://…/data/releases/…/manifest.json",
  "file": "https://…/data/releases/…/digeko-cms-data.tar.gz",
  "checksum": "https://…/digeko-cms-data.tar.gz.sha256",
  "sha256": "<64-stelliger-Hash>",
  "schemaFingerprint": "<64-stelliger-Hash>",
  "contentFingerprint": "<64-stelliger-Hash>",
  "sourceFingerprint": "<64-stelliger-Hash>",
  "status": "https://…/data/status.json"
}

Das Manifest ergänzt unter anderem Erzeugungszeitpunkt, Quelle, Format, Verschlüsselungsstatus, Filter, Zählwerte, Größenlimits, Dateigröße und Hash.

Enthaltener Datenumfang

Der öffentliche Export enthält nur:

• veröffentlichte Kategorien und Stories;
• deren Komponenten, Relationen und tatsächlich referenzierte Medien;
• ausschließlich abgeschlossene TTS-Jobs und die zugehörigen Audios;
• Locales sowie die minimalen öffentlichen Leserechte;
• die für Strapis Kompatibilitätsprüfung benötigten Schemas.

Entwürfe, Benutzerkonten, nichtöffentliche Rollen und Rechte, Tokens, interne Konfiguration, TTS-Fehlerdetails, unfertige TTS-Jobs und unreferenzierte Medien werden nicht exportiert.

Zeitstempel und interne Datenbank- oder Komponenten-IDs lösen allein keinen neuen Release aus. Ändern sich weder der öffentliche Inhalt noch die Schemas, bleibt latest.json unverändert.

Aktuellen Datenstand importieren

Setzen Sie in der .env des CMS:

DIGEKO_DATA_LATEST_URL=https://digeko-public-data.s3.eu-central-1.amazonaws.com/data/latest.json

Starten Sie dann in einer neuen oder bewusst vorbereiteten CMS-Instanz:

npm run data:import

Das Script lädt latest.json, anschließend Archiv und Prüfsummendatei, prüft SHA-256 und startet erst dann strapi import. Der Strapi-Import überschreibt den Zielbestand.

latest.json gehört zum aktuell empfohlenen CMS-Stand und ist keine Kompatibilitätszusage für ältere CMS-Versionen. Für einen veröffentlichten CMS-Tag verwenden Sie den Compatibility-Datenstand, der im zugehörigen GitLab Release verlinkt ist.

Einen bestimmten Rolling-Stand importieren

Für Diagnose und Tests kann statt des beweglichen Zeigers ein bestimmtes Rolling-Archiv importiert werden:

npm run data:import -- \
  --url https://digeko-public-data.s3.eu-central-1.amazonaws.com/data/releases/<version>/digeko-cms-data.tar.gz \
  --checksum-url https://digeko-public-data.s3.eu-central-1.amazonaws.com/data/releases/<version>/digeko-cms-data.tar.gz.sha256

Damit bleibt die Installation auch dann auf demselben Inhaltsstand, wenn latest.json später auf ein neueres Release verweist. Rolling-Stände werden jedoch nicht dauerhaft aufbewahrt und sind nicht automatisch mit jedem CMS-Tag kompatibel. Für eine langfristig reproduzierbare Installation ist deshalb der Compatibility-Datenstand des jeweiligen CMS-Releases maßgeblich.

Versionen und Compatibility-Datenstände →