Statamic CMS – Erfahrungen aus zwei Projekten

Ich habe Statamic inzwischen in zwei Kundenprojekten eingesetzt: einer Konferenz-Website mit Programm, Referenten und Ausstellern sowie der Seite eines Netzwerks mit Veranstaltungen, Orten und Artikeln. Beide laufen mit Statamic 6 auf Laravel 13. Zeit für ein ehrliches Zwischenfazit.

Was ist Statamic?

Statamic ist ein Content-Management-System auf Basis von Laravel. Der Kern ist ein sogenanntes Flat-File-CMS: Inhalte landen nicht in einer Datenbank, sondern als Markdown- und YAML-Dateien direkt im Projektverzeichnis. Dazu kommt ein Control Panel (das Backend), in dem Redakteure Inhalte pflegen, ohne mit Dateien in Berührung zu kommen.

Das Frontend wird mit der Template-Sprache Antlers oder mit Blade gebaut. Statamic kann aber auch headless betrieben werden.

Vorteile

Git-Integration

Da alle Inhalte Dateien sind, lässt sich das gesamte Projekt in Git versionieren – Code, Templates, Feld-Definitionen und Inhalte. Das ist ein echter Unterschied zu WordPress & Co., wo der Inhalt in der Datenbank liegt und zwischen lokaler Umgebung und Server mühsam synchronisiert werden muss.

In der Pro-Version kann Statamic Änderungen aus dem Backend sogar automatisch committen und pushen. Eine Redakteurin speichert einen Eintrag, und kurz darauf steht der Commit im Repository. Jede Änderung ist nachvollziehbar und lässt sich bei Bedarf zurückdrehen.

Moderne Oberfläche

Das Control Panel ist seit Version 6 komplett überarbeitet und fühlt sich sehr modern an: schnell, aufgeräumt, mit Dark Mode, Live Preview und einer globalen Suche (Strg + K). Felder werden in Blueprints definiert und in Tabs und Sektionen gegliedert. Dadurch sieht das Backend für jeden Inhaltstyp genau so aus, wie es das Projekt braucht – nicht mehr und nicht weniger.

Für Kunden war das ein großer Pluspunkt. Die Einarbeitung war deutlich kürzer, als ich es von anderen Systemen kenne.

Anpassungsfähigkeit

Statamic zwingt dir keine Struktur auf. Du baust deine Inhaltsmodelle selbst:

• Collections für Seiten, News, Veranstaltungen, Referenten …
• Blueprints und Fieldsets für die Felder, inklusive Replicator/Bard für flexible Seitenbausteine
• Taxonomien, Globals und Navigationen
• Rollen und Rechte, zum Beispiel „Content Editor“ und „Site Manager“ mit genau definierten Berechtigungen

Weil es Laravel ist, kann man alles erweitern: eigene Controller, Commands, Scheduler (bei uns für den Import externer API-Daten), Queues und Addons. Fehlt etwas, schreibt man es einfach in PHP.

Flat-File-CMS

Keine Datenbank bedeutet: kein Datenbank-Server, keine Dumps, kein Migrationsproblem zwischen Staging und Produktion. Ein Eintrag sieht so aus:

---
id: 6f0c4a1e-0000-0000-0000-000000000000
title: Eröffnungsvortrag
published: true
start: '2026-10-09 10:00'
---
Hier steht der Inhalt als ganz normales **Markdown**.

Das ist leicht lesbar, leicht zu sichern und leicht zu verschieben. Ein Projekt zu klonen heißt git clone, composer install – fertig. Auch Benutzer und Rollen liegen als Dateien im Projekt. Nur für Laravel-Interna braucht es bei Bedarf eine Datenbank – bei uns reicht dafür eine kleine SQLite-Datei.

KI-Kompatibilität

Weil bei Statamic wirklich alles in Dateien liegt, kann ein KI-Assistent im Editor das gesamte Projekt lesen und verstehen: Templates, Blueprints, Inhalte, Konfiguration. Er kann neue Collections anlegen, Felder ergänzen, Einträge anpassen oder Templates refactoren, ohne dass man ihm erst Zugriff auf eine Datenbank oder eine API geben muss. Alles ist außerdem im Git-Diff sichtbar und damit gut zu prüfen.

Nachteile

Preis

Statamic Core ist kostenlos, hat aber Einschränkungen, vor allem nur einen Benutzer-Account. Sobald es mehrere Redakteure, Rollen, Revisionen, mehrere Sprachen/Sites oder die Git-Integration braucht, ist Pro nötig. Und das kostet seit Mai 2026 349 $ pro Site (einmalig, ein Jahr Updates inklusive), danach 99 $ pro Jahr für Updates und Support. Vorher waren es 275 $ und 65 $.

Für ein Kundenprojekt ist das gut zu stemmen. Für Hobbyprojekte, kleine Vereinsseiten oder wenn man viele kleine Sites betreibt, ist es ein spürbarer Posten gegenüber WordPress. Man sollte den Preis also von Anfang an im Angebot einkalkulieren. Im Gegenzug sind Formulare, Static Caching oder ein Navigations-Builder bereits enthalten, wofür man bei anderen Systemen oft Plugins kaufen muss.

Cache

Damit ein dateibasiertes System schnell bleibt, nutzt Statamic den Stache, einen Cache-Index über alle Inhalte. Dazu kommen die normalen Laravel-Caches (Config, Routes, Views) und optional Static Caching.

In der Praxis heißt das: Wenn nach einem Deployment etwas „komisch“ aussieht, ist es fast immer der Cache. Bei uns gab es zum Beispiel einen Config-Cache mit falschen absoluten Pfaden, der zu einem 500er-Fehler geführt hat. Nach jedem Deploy gehört deshalb ein cache:clear, config:clear und statamic:stache:clear fest dazu. Wer Static Caching einsetzt, muss sich außerdem Gedanken über die Invalidierung machen.

Serveranforderungen

Statamic ist eine Laravel-Anwendung und braucht entsprechende Umgebung:

• PHP 8.3+ (bei uns teils 8.4)
• Composer und idealerweise SSH-Zugang
• Schreibrechte für storage/ und bootstrap/cache
• GD oder Imagick für die Bildverarbeitung (Glide)
• Cron für den Laravel-Scheduler

Günstiges Shared Hosting mit alter PHP-Version ist damit raus. Bei einem Hoster war die Standard-PHP-Version im Account noch 7.4, sodass die PHP-Version erst explizit per .htaccess umgestellt und auf der CLI immer php84 statt php verwendet werden musste. Gegenüber einer statischen Nuxt-Seite auf Netlify oder einem simplen WordPress-Hosting ist das deutlich mehr Aufwand.

Deploy – ein bedingter Nachteil

Eigentlich ist das Deployment unproblematisch: Per GitHub Actions werden vendor/ und die Assets gebaut und auf den Server übertragen, ein paar Artisan-Befehle laufen hinterher. Das ist kein Statamic-spezifisches Problem, sondern Laravel-Alltag. Trotzdem gab es Stolpersteine:

• nginx und Glide: Bildvarianten (/img/...) gaben 404, weil die Standard-Konfiguration statische Dateiendungen wie .webp abfängt, bevor PHP sie erreicht. Es braucht eine eigene location-Regel.
• open_basedir war bei Plesk zu restriktiv eingestellt.
• Rechte und Verzeichnisse: storage/logs fehlte nach dem Deploy, weil das Verzeichnis nicht im Repository war.
• Inhalte vs. Code: Das ist der eigentliche Knackpunkt. Wenn Redakteure auf dem Server Inhalte ändern und ein Code-Deploy diese Dateien danach wieder aus dem Repository überschreibt, sind Änderungen weg. Entweder man schließt content/ vom Deploy aus oder setzt auf die Git-Integration – die dann sauber mit dem Deploy zusammenspielen muss, damit Pushes nicht an einem „non-fast-forward“ scheitern.

Hat man das einmal sauber aufgesetzt, läuft es zuverlässig. Wer neu startet, sollte diese Punkte aber von Anfang an einplanen.

Fazit

Statamic ist für mich eines der angenehmsten CMS, mit denen ich bisher gearbeitet habe. Die Kombination aus Git-Workflow, modernem Backend und voller Anpassbarkeit passt hervorragend zu Projekten, bei denen Redakteure eine komfortable Oberfläche brauchen und Entwickler trotzdem die volle Kontrolle über Code und Struktur behalten wollen. Dass alles in Dateien liegt, macht die Arbeit mit KI-Assistenten außerdem deutlich einfacher.

Die Nachteile sind überschaubar, aber real: Der Preis für Pro, ein Server mit aktuellem PHP und ein bisschen Disziplin bei Cache und Deployment. Für einfache, kleine Seiten ohne Redaktion oder mit knappem Budget gibt es andere Optionen, die evtl. besser passen. Für Kundenprojekte mit echten Anforderungen würde ich Statamic jederzeit wieder einsetzen.