Payload CMS: Warum wir unsere Website-Plattform darauf bauen
Seit September bauen wir Rocketsite, unsere eigene Plattform auf Payload CMS und Next.js. Warum, was Kunden davon haben und wann Storyblok trotzdem die bessere Wahl ist.
)
Bisher hatte fast jede Website, die wir betreuen, ihren eigenen technischen Unterbau. Die meisten liefen auf WordPress, einzelne auf Laravel, andere mit Storyblok. Das funktioniert, macht aber jede Sicherheitslücke zu einer Einzelaufgabe: Wir müssen sie Website für Website schließen. Seit September bauen wir deshalb an Rocketsite, einer eigenen Plattform, auf der künftig unsere Kundenwebsites laufen. Die Grundlage dafür ist Payload CMS.
Was wir lösen wollten
Bei WordPress sehen wir vor allem ein Problem: Angriffe kommen meist über Erweiterungen, die irgendwer irgendwann installiert hat. Jede Website hat eine andere Mischung davon. Jede braucht eigene Updates und eigene Kontrolle.
Unser Ziel war ein gemeinsamer Kern für alle Websites. Darin stecken die Dinge, die jede Website braucht und die wir nicht für jedes Projekt neu bauen wollen: Inhaltsbausteine, Benutzer und Rollen, Formulare mit Spamschutz ohne Cookies, Suchmaschinen-Grundlagen, Backups und Datenschutz. Was den Kunden unterscheidet, kommt obendrauf: das Design, die Auswahl an Bausteinen, bei Bedarf eigene Inhaltstypen.
Warum Payload
Payload ist ein Content-Management-System, das direkt in Next.js läuft. Next.js ist das Framework, mit dem wir auch die Websites selbst bauen. Verwaltung und Website sind damit ein Projekt, keine zwei Systeme, die miteinander reden müssen. Den Ausschlag haben vier Punkte gegeben.
Open Source. Payload steht unter der MIT-Lizenz. Sie zahlen keine Lizenz, wir hängen an keinem Preismodell. Seit 2025 gehört das Team hinter Payload zu Figma. Der Quellcode steht weiterhin unter MIT-Lizenz. Selbst wenn sich daran etwas ändern sollte: Die Version, die wir betreiben, bleibt nutzbar.
Selbst betrieben in der EU. Wir betreiben Payload auf eigenen Servern bei Hetzner in Deutschland, jeden Kunden in einem eigenen Container. Es gibt keinen Dienst eines Dritten, über den Ihre Inhalte laufen.
Ihre Daten in Ihrer Datenbank. Jeder Kunde bekommt eine eigene Datenbank. Ihre Inhalte liegen nicht in einem großen Topf mit denen anderer Kunden. Wer geht, nimmt seine Datenbank mit.
Typisierte Inhaltsmodelle. Bei Payload beschreiben wir jeden Inhaltstyp im Code: welche Felder es gibt, welche Pflicht sind, was wohin verweist. Daraus entstehen automatisch Typen. Das System weiß also genau, wie zum Beispiel ein Angebot aussieht. Fehler, etwa ein falsch benanntes Feld, fallen schon beim Bauen auf und nicht erst, wenn ein Besucher eine kaputte Seite sieht.
Ein Kern, viele Websites
Der gemeinsame Kern ist ein Softwarepaket mit Versionsnummer. Jede Kundenwebsite hat ihr eigenes Projekt, in dem nur Design, Einstellungen und Inhalte liegen. Bringen wir eine neue Version des Kerns heraus, bekommt jede Website automatisch einen Änderungsvorschlag.
Bevor er übernommen wird, laufen automatische Prüfungen. Die Änderungen an der Datenbank werden auf einer leeren Datenbank durchgespielt, die Website wird gebaut, wichtige Seiten werden aufgerufen. Erst danach schauen wir uns die Änderung an und geben sie frei. Beim Ausrollen startet die neue Version neben der alten. Der Besucherverkehr wechselt erst, wenn sie sauber antwortet. Geht etwas schief, bleibt die alte Version online.
Für Sie heißt das: Ein Sicherheitsupdate, das wir einmal in den Kern einbauen, erreicht alle Websites auf demselben Weg. Niemand muss sich an Ihre Seite erinnern.
Wichtig ist uns dabei, was der Kern nicht ist: ein Baukasten mit freiem Layout. Redakteurinnen und Redakteure kombinieren vorbereitete Bausteine. Das Datenmodell der Bausteine ist für alle gleich, ihr Aussehen gestalten wir für jeden Kunden neu. Zwei Websites auf Rocketsite müssen sich also nicht ähnlich sehen.
Zwei Projekte, an denen wir das gerade erproben
P·S·P GmbH und MediSafe. Beide Websites gehören zusammen. Die Website der P·S·P GmbH lief bisher mit Storyblok, MediSafe auf Laravel. In Rocketsite laufen beide in einer gemeinsamen Instanz. Das Team meldet sich einmal an, wählt die Website aus und pflegt sie im selben System. Jede Seite hat ihr eigenes Design und ihre eigene Auswahl an Bausteinen. Die Inhalte haben wir per Skript übernommen, die Adressen der Seiten bleiben gleich. Derzeit prüft der Kunde beide Seiten auf unserer Testumgebung.
Dr. Sabine Wölbl, Leadership Performance. Hier reichen Seiten mit Bausteinen nicht. Die Website arbeitet mit Angeboten, Ausgangssituationen, Spannungsfeldern, Praxisbeispielen und Fachbeiträgen, die aufeinander verweisen. Wer eine Situation liest, die zu seinem Unternehmen passt, landet bei den passenden Angeboten und Beiträgen. Dafür haben wir eigene Inhaltstypen angelegt. Entwürfe, Vorschau, Suchmaschinen-Einstellungen und Sitemap bringt der Kern für jeden davon mit. Der Wunsch der Kundin war eine Website, die sie über Jahre erweitern kann, ohne sie jedes Mal neu programmieren zu lassen. Die Seite ist derzeit im Aufbau.
Wann Storyblok die bessere Wahl bleibt
Wir sind weiterhin zertifizierter Storyblok-Partner. Rocketsite ersetzt Storyblok nicht in jedem Fall.
Storyblok ist ein Dienst im Internet. Um Server und Betrieb müssen sich weder Sie noch wir kümmern. Der Visual Editor ist außerdem näher an der fertigen Seite: Sie klicken in der Vorschau auf eine Überschrift und bearbeiten sie dort. Payload hat auch eine Live-Vorschau, gearbeitet wird aber in einem Formular daneben.
Storyblok empfehlen wir deshalb weiterhin, wenn ein großes Redaktionsteam viel am Seitenaufbau arbeitet und dabei möglichst direkt auf der Seite bleiben will. Ebenso, wenn Sie Ihr CMS bewusst unabhängig von unserem Hosting betreiben wollen. Was wir in Storyblok-Projekten gelernt haben, steht in unserem Beitrag Storyblok in der Praxis.
Ehrlich gesagt ist Rocketsite auch noch jung. Die ersten Kundenwebsites sind noch in der Abnahme. Wer heute eine bewährte Lösung mit langer Geschichte will, bekommt bei Storyblok mehr Erfahrungswerte.
Fazit
Payload gibt uns, was wir für einen gemeinsamen Kern brauchen: offenen Code, Betrieb auf eigenen Servern in der EU, eine eigene Datenbank pro Kunde und Inhaltstypen, die genau zu einem Betrieb passen. Für Sie bedeutet das weniger Wildwuchs, schnellere Sicherheitsupdates und eine Website, die Ihnen gehört.
Wenn Ihre Website mehr können soll als Seiten anzeigen, lesen Sie unter Individuelle Web-Lösungen, wie wir solche Projekte umsetzen.
Häufige Fragen
Kurz beantwortet
Kann ich meine Inhalte mitnehmen, wenn ich nicht mehr bei Ihnen hosten will?
Ja. Jede Website hat ihre eigene Datenbank, die wir Ihnen vollständig übergeben können. Payload ist Open Source. Ihre Website läuft also auch bei einem anderen Anbieter weiter, ohne dass Sie eine Lizenz von uns brauchen.
Fallen für Payload Lizenzgebühren an?
Nein. Payload steht unter der MIT-Lizenz und darf frei verwendet werden. Laufende Kosten entstehen nur für Hosting und Betreuung, nicht für die Software selbst.
Kann ich Inhalte vorbereiten und später veröffentlichen?
Ja. Änderungen speichern Sie als Entwurf, das System sichert dabei laufend mit. In der Vorschau sehen Sie die Seite, bevor sie online geht. Wenn Sie wollen, legen Sie einen Zeitpunkt fest, zu dem der Inhalt automatisch erscheint.
Weiterlesen
4. September 2026 · 4 Min. LesezeitHosting und Betreuung: Was nach dem Go-live passiert und was Ihnen gehört
3. August 2026 · 3 Min. LesezeitFörderungen für Digitalisierungsprojekte: Was gefördert wird und was nicht
2. Juli 2026 · 4 Min. LesezeitVom Erstgespräch zum Go-live: Ein Relaunch Schritt für Schritt, ohne Ranking-Verlust