Strapi 5 — die Open-Source-Konsolidierung im Headless-Markt 2026

Strapi hat im September 2024 das fünfte Major-Release als stable Version ausgeliefert. Knapp zwanzig Monate später ist 5.x die produktiv vorherrschende Linie, die 4.x-Wartung läuft als Maintenance-Modus aus, die ersten ernsthaften DACH-Mittelstandsprojekte sind seit Frühjahr 2025 auf 5.x in Produktion. Es ist der Moment, an dem sich seriös bilanzieren lässt, wie weit die Open-Source-Headless-Konsolidierung getragen hat — und an welchen Stellen Strapi 5 weiterhin Grenzen zeigt, die in der Produktionsplanung 2026 zu berücksichtigen sind.

Die kurze Antwort: Strapi 5 ist erwachsen geworden. Es ist nicht das CMS, das jeden anderen schlägt, aber es ist das CMS, das die Open-Source-Lücke im Headless-Segment glaubwürdig füllt. Die Document Service API ist eine substantielle Verbesserung gegenüber dem Entity-Service-Modell der 4.x-Linie, die TypeScript-First-Architektur ist konsequent umgesetzt, das Plugin-Ökosystem hat die kritische Masse erreicht. Wer 2026 ein Headless-Projekt im DACH-Mittelstand plant und Open-Source als Bedingung setzt, kommt an Strapi 5 kaum vorbei.

Document Service API als Architektur-Neuerung

Die zentrale technische Neuerung der 5.x-Linie ist die Document Service API. Sie ersetzt die Entity Service API der 4.x-Linie und bringt einen architektonischen Paradigmenwechsel: Content wird nicht mehr als flacher Entity-Datensatz mit einer ID verstanden, sondern als Dokument mit einer langlebigen documentId, das in mehreren Locales und mehreren Status-Varianten (Draft, Published) existieren kann.

Die Abfrage-Signatur sieht in der Praxis so aus:

import strapi from '@strapi/strapi';

const articles = await strapi.documents('api::article.article').findMany({
  filters: {
    publishedAt: { $notNull: true },
  },
  populate: {
    cover: true,
    author: { fields: ['name', 'avatar'] },
  },
  locale: 'de',
  status: 'published',
});

Der Unterschied zur 4.x-Entity-Service-API ist mehr als syntaktisch. Die documentId ist über alle Locales und Status hinweg stabil — ein deutsches Article-Dokument und seine englische Übersetzung teilen sich dieselbe documentId, was die Cross-Locale-Referenzierung erheblich vereinfacht. Die Trennung von Draft und Published auf Dokument-Ebene macht das in 4.x über publishedAt-Mechanik gefrickelte Draft-Modell zum nativen First-Class-Konzept.

Die praktische Relevanz für DACH-Projekte ist deutlich. Wer ein mehrsprachiges Content-Modell betreibt — typischer Fall bei deutschsprachigen Magazinen mit englischer Übersetzungsspur, schweizerischen Sites mit DE/FR/IT, österreichischen Konzernportalen mit DE/EN/CZ/HU — hat in 4.x mit der Locale-Konsistenz erheblichen Custom-Code geschrieben. In 5.x verschwindet ein nicht unerheblicher Teil dieses Codes, die API spricht das Modell unmittelbar.

Der Wermutstropfen: Die Migration aus 4.x ist nicht trivial. Custom-Plugins, Custom-Controller und Custom-Services, die direkt gegen die Entity-Service-API geschrieben sind, müssen auf den Document-Service portiert werden. Strapi liefert einen Codemod und einen Migrations-Leitfaden, aber das Refactoring eines gewachsenen 4.x-Projekts ist erfahrungsgemäß ein zwei- bis fünf-Personenwochen-Vorhaben, nicht ein zwei- bis fünf-Personentage-Vorhaben.

Document Versioning als Enterprise-Feature

Eng verwandt mit dem Document-Service-Konzept ist das in 5.x eingeführte Document Versioning. Jede Änderung an einem Dokument erzeugt eine Version, die im History-Browser des Admin-Panels einsehbar und auf die zurückgesetzt werden kann. Die Implementierung ist konsequent in das Document-Service-Modell eingebettet — eine Version ist ein Snapshot eines Dokuments zu einem bestimmten Zeitpunkt, mit allen Locale- und Status-Varianten.

In der Standard-Open-Source-Edition ist das Versioning auf eine eingeschränkte Funktionalität reduziert. Die volle Versionierung mit unbegrenzter History, Diff-Ansichten zwischen Versionen, Rollback-Workflows und Audit-Trails ist Teil der Enterprise-Edition. Diese Unterscheidung ist 2026 ein zentrales Differenzierungsmerkmal — und der Punkt, an dem die Open-Source-Strapi-Diskussion in DACH-Projekten am häufigsten an die Lizenz-Frage stößt.

Die Enterprise-Edition liefert über das Versioning hinaus weitere Bausteine, die für produktive Mehrbenutzer-Redaktionen 2026 zum erwarteten Funktionsumfang gehören: Rollen- und Berechtigungs-Management auf Feld-Ebene, Single Sign-On via SAML und OIDC, Review-Workflows mit Approval-Stufen, ein granulares Audit-Logging und der Strapi-Cloud-Service als verwaltetes Hosting-Angebot.

Die wirtschaftliche Logik ist klar: Open-Source-Edition kostet nichts, Enterprise-Edition kostet je nach Größenklasse fünf- bis sechsstellig pro Jahr. Wer im DACH-Mittelstand mit einer kleinen Redaktion und überschaubarem Content-Modell startet, kommt mit der Open-Source-Variante weit. Wer eine Konzern-Redaktion mit vier- bis fünfstelliger Editor-Zahl, komplexer Berechtigungslogik und regulatorischen Audit-Anforderungen aufsetzt, landet wirtschaftlich oft bei der Enterprise-Variante.

TypeScript-First — endlich konsequent

Die TypeScript-Unterstützung war in 4.x eine teilweise Geschichte. Die generierten Typen waren vorhanden, aber inkonsistent, die Strapi-eigenen Typings hatten Lücken, Plugin-Entwicklung war in TypeScript möglich, aber mit nicht zu unterschätzendem Reibungsverlust. Strapi 5 hat den Schalter umgelegt: TypeScript ist die First-Class-Sprache, die JavaScript-Pfade laufen mit, sind aber nicht mehr der Goldstandard.

Die Auswirkung in der Entwicklungspraxis ist spürbar. Custom-Controller, Custom-Services, Custom-Plugins werden in TypeScript geschrieben, die Strapi-eigenen API-Surfaces sind typisiert, die Auto-Completion in modernen Editoren wie VS Code oder JetBrains-IDEs funktioniert über die gesamte Strapi-Surface hinweg. Die generierten Content-Type-Typen werden aus dem Schema abgeleitet und in src/types/generated/contentTypes.d.ts abgelegt — der Workflow „Schema-Änderung, Type-Generation, type-safe Code” ist ohne Reibung.

import type { Schema, Struct } from '@strapi/strapi';

export interface ApiArticleArticle extends Struct.CollectionTypeSchema {
  collectionName: 'articles';
  info: {
    singularName: 'article';
    pluralName: 'articles';
    displayName: 'Article';
  };
  attributes: {
    title: Schema.Attribute.String & Schema.Attribute.Required;
    slug: Schema.Attribute.UID<'title'>;
    body: Schema.Attribute.RichText;
    cover: Schema.Attribute.Media<'images'>;
    publishedAt: Schema.Attribute.DateTime;
  };
}

Die Konsequenz für Frontend-Entwicklung ist erheblich. Wer Strapi 5 mit einem TypeScript-Frontend konsumiert — Next.js 15, Nuxt 4, Astro 5 oder SvelteKit 2 — kann die Strapi-Typen direkt in das Frontend ziehen und end-to-end-typsicher arbeiten. Die Frage „was kommt da eigentlich aus der API zurück” verschwindet aus dem Frontend-Code; die API-Antwort ist das, was die generierten Types beschreiben.

Plugin-Ökosystem — die Reife-Frage

Das Strapi-Plugin-Ökosystem ist 2026 erwachsen genug, um die meisten Standard-Anforderungen abzudecken, und groß genug, um die Qualitäts-Heterogenität als reales Problem zu erzeugen. Im offiziellen Strapi Marketplace finden sich Mitte 2026 rund 400 öffentlich gelistete Plugins, die Mehrheit ist auf 5.x portiert, ein nennenswerter Teil bleibt 4.x-only und wird voraussichtlich nicht mehr migriert.

Die produktionsrelevanten Plugin-Kategorien:

SEO und Metadaten: strapi-plugin-seo und seine Forks decken Open-Graph-Tags, Twitter-Cards, strukturiertes Schema.org-JSON-LD und Canonical-URL-Logik ab. In der Standard-Konfiguration produktionstauglich, in komplexeren Multi-Locale-Szenarien typischerweise mit Anpassungen.

Suchindex-Integration: Algolia, Meilisearch und Elasticsearch haben offizielle oder community-getragene Plugins, die Strapi-Events in Index-Updates übersetzen. In der DACH-Praxis dominiert Meilisearch für selbstgehostete Setups, Algolia für gemanagte Setups.

Mediathek-Erweiterungen: Cloudinary, S3, DigitalOcean Spaces, Bunny CDN — alle gängigen Object-Storage-Backends sind als Upload-Provider verfügbar. Die Standard-Lokale-Strapi-Mediathek auf Disk reicht für kleine Projekte, für jedes Produktionsprojekt mit mehr als ein paar Dutzend MB Assets ist ein Cloud-Storage Provider die richtige Wahl.

Internationalisierung: Das @strapi/plugin-i18n-Kern-Plugin ist mit 5.x deutlich integrierter als in 4.x. Die Document-Service-API arbeitet nativ mit Locales, was vieles vereinfacht, das in 4.x noch Workaround war.

E-Mail-Versand: SMTP, SendGrid, AWS SES, Mailgun, Postmark — die Standard-Provider sind abgedeckt. In DACH-Projekten dominieren SendGrid und Postmark für transaktionale E-Mails, eigene SMTP-Anbindungen sind im Mittelstand häufig.

Authentication-Erweiterungen: Auth0, Keycloak, eigene SAML-Provider — die Provider-Plugins sind verfügbar, ihre Reife schwankt. Wer SSO in Enterprise-Setups braucht, prüft die Plugin-Pflege seriös vor der Investitionsentscheidung.

Die kritische Diagnose: Das Ökosystem hat die Breite, aber die Tiefe ist heterogen. Ein Plugin, das im README produktionstauglich aussieht, kann beim Stress-Test mit hoher Load oder bei komplexer Edge-Case-Logik durchfallen. Die seriöse Strapi-Praxis 2026 ist die der zurückhaltenden Plugin-Wahl mit gründlicher Vorbewertung — viele DACH-Agenturen pflegen interne Plugin-Whitelists, die nur Plugins mit nachgewiesener Produktionsreife enthalten.

Performance- und Skalierungs-Profil

Strapi 5 läuft auf Node.js (mindestens 18.x, empfohlen 20.x LTS oder neuer) und Koa als HTTP-Server. Die Performance-Bilanz ist die typische einer Node-basierten CMS-Anwendung: solide für mittlere Last, gut zu horizontal skalieren, mit klaren Engpässen bei spezifischen Workloads.

Die produktionsrelevanten Performance-Hebel:

Datenbank-Wahl: Strapi 5 unterstützt PostgreSQL, MySQL und SQLite. PostgreSQL ist die Produktions-Empfehlung; MySQL ist zulässig, hat aber bei komplexen relationalen Abfragen im 5.x-Modell einige Eigenheiten; SQLite ist Dev-only.

GraphQL versus REST: Die GraphQL-Schicht hat in 5.x deutliche Verbesserungen erfahren, der Query-Cost-Analyzer ist nativ verfügbar, N+1-Probleme werden durch DataLoader-Integration entschärft. In der Produktion ist die REST-API typischerweise die performantere Wahl, wenn die Frontend-Anforderungen keine GraphQL-spezifischen Features brauchen.

Caching-Schicht: Strapi liefert keine integrierte Response-Cache-Schicht. Wer Caching braucht — und in der Produktion will man Caching — baut die Schicht typischerweise mit Redis vor Strapi auf, oft im Verbund mit einem Reverse-Proxy wie Varnish oder einem CDN wie Cloudflare. Die Plugin-Community hat Caching-Plugins (etwa strapi-plugin-rest-cache), die für viele Use-Cases ausreichen.

Horizontale Skalierung: Strapi ist als stateless-Service skalierbar, mehrere Instanzen können hinter einem Load-Balancer parallel laufen. Die Datenbank wird typischerweise der Engpass; PostgreSQL-Read-Replicas helfen, sind aber in Strapi nicht out-of-the-box konfiguriert.

In DACH-Mittelstandsprojekten ist Strapi typischerweise mit zwei bis vier Container-Instanzen produktiv, einer Read-Replica der Datenbank und einem CDN für statische Assets ausreichend dimensioniert. Wer in den hohen sechsstelligen oder siebenstelligen monatlichen Page-Impression-Bereich kommt, plant ernsthafter — und prüft, ob Strapi noch der richtige Stack ist oder ob ein dedizierteres Enterprise-CMS oder ein anderes Architektur-Muster passender wäre.

Internationale Marktposition

Strapi ist seit Jahren der führende Open-Source-Headless-CMS-Vertreter, aber nicht ohne Konkurrenz. Im internationalen Vergleich gibt es vier Pole, die das Feld 2026 strukturieren:

Strapi selbst, mit dem Self-Hosting-Schwerpunkt und der Cloud-Variante als ergänzendem Angebot. Adressiert vor allem Entwickler-Teams, die Open-Source-Kontrolle und volle Datenhoheit wollen.

Payload CMS, das mit Version 3 (Anfang 2025) auf eine vollständige Next.js-Integration umgestellt hat und damit eine eigene Nische besetzt: Headless-CMS mit nativer React-Server-Components-Integration, ohne Trennung zwischen CMS und Frontend-Codebase.

Directus, mit dem Schwerpunkt auf der Datenmodellierungs-Flexibilität und der Datenbank-First-Architektur. Adressiert Use-Cases, die jenseits klassischer Content-Modelle liegen — IoT-Daten, ERP-nahe Anwendungen, Datenverwaltungs-Backends.

Sanity, Contentful, Storyblok, Hygraph als die SaaS-First-Konkurrenten. Sie adressieren primär Teams, die Hosting und Wartung outsourcen wollen und für die Lizenzkosten kein Engpass sind.

In DACH-Projekten ist die Verteilung typisch: Strapi für Mittelstands-Projekte mit Open-Source-Präferenz und eigener Infrastruktur; Storyblok als SaaS-Wahl im Mittelstand, oft wegen der visuellen Editing-Komponente; Sanity für Editor-zentrierte Marken- und Magazin-Projekte; Contentful für Konzern-Projekte mit hohen Compliance-Anforderungen; Hygraph (vormals GraphCMS) als GraphQL-Native-Variante für Tech-First-Teams.

Bilanz Mai 2026

Strapi 5 ist 2026 das, was die Community sich für die 5.x-Linie versprochen hat: ein erwachsenes, produktionstaugliches Open-Source-Headless-CMS, das die strukturellen Schwächen der 4.x-Linie hinter sich gelassen hat. Die Document Service API ist die richtige Architektur-Antwort auf die Schwächen des Entity-Service-Modells, die TypeScript-First-Linie ist konsequent, das Plugin-Ökosystem hat die kritische Masse erreicht, die Enterprise-Differenzierung ist sauber kommuniziert.

Was offen bleibt: Die Migrationen aus 4.x werden noch in das Jahr 2027 reichen, das Plugin-Ökosystem braucht weitere Konsolidierung an den Qualitäts-Rändern, die Caching-Schicht bleibt ein Punkt, der in der Architektur-Planung eigens zu adressieren ist. Diese Punkte sind keine Verhinderer; sie sind die normalen Begleiterscheinungen einer erwachsen werdenden Open-Source-Plattform.

Wer im Mai 2026 ein Headless-CMS für ein DACH-Mittelstandsprojekt evaluiert, sollte Strapi 5 ernsthaft in die engere Wahl nehmen. Wer 4.x produktiv betreibt, sollte die Migration auf 5.x für 2026 oder spätestens 2027 planen — die Wartung von 4.x läuft aus, und die 5.x-Vorteile sind die Investition wert.