Warum eine Feature-Tabelle hier nicht weiterhilft
Beide Systeme haben eine Medienbibliothek, ein Rollenmodell und eine REST- oder GraphQL-API. Eine Gegenüberstellung von Häkchen bringt deshalb wenig, weil beide praktisch alle davon setzen können. Die Frage, die tatsächlich über die Entscheidung entscheidet, ist eine andere: Wem gehören am Ende Datenbank und Daten, was bedeutet Self-Hosting in der EU in der Praxis, und wie viel von deiner eigenen Geschäftslogik kannst du direkt im CMS unterbringen, bevor du einen zweiten Service brauchst.
Wem gehören Datenbank und Daten
Beide sind Open Source und lassen sich vollständig selbst hosten, mit eigener PostgreSQL-Datenbank statt einem Konto bei einem Anbieter. Sobald du selbst hostest, gehören dir Datenbank und Inhalte in beiden Fällen ohne Einschränkung. Der Unterschied zeigt sich erst beim Betrieb: Payload ist als Next.js-Anwendung konzipiert, das Content-Modell wird als Code im selben Repository wie deine restliche Anwendung gepflegt und versioniert. Strapi läuft als eigenständiger Dienst mit eigenem Admin-Panel, dein Frontend spricht ihn über die API an, unabhängig davon, in welchem Framework das Frontend gebaut ist. Beides bedeutet Datenhoheit, nur die Architektur, in der diese Daten entstehen, ist verschieden.
Was Self-Hosting in der EU praktisch bedeutet
Self-Hosting heißt nicht automatisch DSGVO-konform, es heißt nur, dass du selbst entscheidest, wo die Daten liegen. In der Praxis läuft das bei beiden Systemen auf dasselbe Muster hinaus: ein Docker-Container für die Anwendung, eine PostgreSQL-Instanz bei einem Anbieter mit Serverstandort in der EU, keine Weiterleitung von Redaktionsdaten an ein SaaS-Backend eines Drittanbieters. Beide Hersteller bieten daneben auch eine gehostete Cloud-Variante an, die diese Entscheidung wieder abgibt. Wer selbst hostet, umgeht das bei Payload wie bei Strapi gleichermaßen.
Wie viel Geschäftslogik passt ins CMS
Hier liegt der eigentliche Unterschied. Payload ist kein CMS mit angeflanschter Anwendung, sondern ein Next.js-Anwendungsframework, das die Redaktion gleich mitbringt. Eigene API-Routen, Zugriffslogik, Hooks und Hintergrund-Jobs leben in derselben Codebasis und im selben Deploy wie der Rest deiner Anwendung. Damit lässt sich deutlich mehr Geschäftslogik im CMS selbst unterbringen, bevor ein zweiter Service nötig wird. Der kommt erst dann, wenn eine Aufgabe eine andere Skalierung braucht als der Rest der Anwendung oder so lange läuft, dass sie nicht mehr in einen Request passt. Strapi ist architektonisch von Anfang an ein getrennter Dienst: Deine Anwendungslogik läuft nicht im CMS, sondern dahinter, jeder Zugriff geht über einen Netzwerkaufruf. Lifecycle-Hooks und eigene Endpunkte sind in Strapi möglich, bewegen sich aber innerhalb von dessen Plugin-System, nicht als freier Anwendungscode.
Wie sich Lizenz und Cloud-Modell auf die Abhängigkeit auswirken
Payload ist im Kern vollständig MIT-lizenziert, auch selbst gehostet stehen alle Funktionen offen, ohne dass Teile hinter einer bezahlten Enterprise-Stufe liegen. Strapi trennt zwischen einer MIT-lizenzierten Community Edition und einer kostenpflichtigen Enterprise Edition mit zusätzlichen Funktionen. Das beeinflusst die Abhängigkeit direkt: Bei Payload bleibt der volle Funktionsumfang beim Selbst-Hosten erhalten, bei Strapi hängt es davon ab, welche Funktionen du tatsächlich brauchst und ob sie in der freien oder in der kostenpflichtigen Stufe liegen.
Wann Strapi die bessere Wahl ist
Wenn deine Inhalte an mehrere, technisch unabhängige Frontends ausgespielt werden sollen, etwa eine Website in einem Framework, eine mobile App und eine Drittintegration gleichzeitig, und keines davon auf Next.js aufbaut, ist die klare Trennung von Strapi ein Vorteil statt eine Einschränkung. Auch wenn dein Team bewusst CMS und Anwendung als zwei getrennte Deploys mit eigenen Release-Zyklen betreiben will, passt das eher zu Strapis Architektur. Und da Strapi als eigenständiges CMS-Produkt länger am Markt ist, ist sein Plugin-Ökosystem für reine Redaktionsfunktionen wie Internationalisierung oder Medienverwaltung breiter ausgebaut. Für ein Projekt, bei dem die Website selbst die Anwendung ist, mit eigener Logik statt nur Inhalten, ist dagegen Payload die tragfähigere Basis.