Warum wir Osprey gebaut haben, unser Headless-CMS

Die meisten Headless-CMS zwingen zu einer Entscheidung: ein Tool mit visuellem Editor, das das Schema wie einen einmal generierten Datenbank-Blob behandelt, oder eine selbstgebaute Lösung, bei der jeder Seitenaufruf das CMS live anspricht. Osprey, das eigene Headless-CMS, wurde gebaut, um diese Entscheidung überflüssig zu machen: ein Content-Schema, das wie Code versioniert wird, und eine Website, die als statische Dateien ausgeliefert wird. Im Folgenden geht es darum, was der Code tatsächlich tut — nicht nur, was das Marketing verspricht.

Schemas sind Code, kein Datenbank-Blob

In Osprey wird eine Collection in TypeScript definiert und liegt im selben Repository wie der Rest der Anwendung. Damit gelten dieselbe Versionskontrolle, dasselbe Code-Review und dieselben durchgängigen Typen, die ein Team bereits auf den Anwendungscode anwendet, auch für das Content-Modell. Die Admin-Oberfläche ist eine Komfortfunktion zum Bearbeiten von Einträgen; sie ist nie die Quelle der Wahrheit für das Schema selbst.

Inhalte werden zur Build-Zeit ausgeliefert, nicht bei jeder Anfrage

Der Loader @osprey/astro holt veröffentlichte Einträge während des Builds vom öffentlichen REST-Endpunkt von Osprey und übergibt sie an Astros Content Collections, ohne dass für diesen öffentlichen Lesezugriff ein API-Key nötig ist. Die ausgelieferte Website besteht aus reinem statischem HTML: Osprey ist eine Build-Zeit-Abhängigkeit, keine Laufzeit-Abhängigkeit. Läuft ein Build, während das CMS langsam oder nicht erreichbar ist, behält der Loader die zuvor zwischengespeicherten Einträge, statt den Build fehlschlagen zu lassen.

Standardmäßig privat, bei Ablehnung unsichtbar

Eine Collection wird über die öffentliche API nur dann bereitgestellt, wenn ihre eigene access.read-Regel einen anonymen Aufrufer ausdrücklich zulässt; alles andere bleibt privat. Eine Anfrage an eine private Collection oder an ein unveröffentlichtes Dokument liefert einen 404 statt eines Berechtigungsfehlers zurück, sodass die API niemals bestätigt, dass eine private Collection überhaupt existiert.

SEO-Metadaten reisen mit jedem Eintrag

Jeder Eintrag, den die öffentliche API zurückgibt, trägt ein zusammengeführtes SEO-Objekt: Titel, Beschreibung, Open-Graph- und Twitter-Tags sowie die kanonische URL des Eintrags selbst haben Vorrang, workspace-weite Standardwerte füllen den Rest. Dieselbe Payload enthält die aufgelöste Robots-Direktive sowie hreflang-Links zu jeder veröffentlichten Übersetzung dieser Seite, sodass ein Frontend seine Meta-Tags rendern kann, ohne diese Logik erneut aufzubauen.

Ein Deployment, mehrere Tenants

Osprey ist mandantenfähig: Ein einzelnes Deployment kann mehr als eine Website bedienen, jede auf ihren eigenen Tenant begrenzt. Bei den öffentlichen Content-Routen wird der zu lesende Tenant anhand des Host-Headers der Anfrage selbst aufgelöst und nicht anhand eines vom Client mitgegebenen Werts, sodass eine anonyme Anfrage nicht durch eine andere Tenant-ID die Inhalte eines fremden Tenants lesen kann. Jede Datenbankabfrage der API ist intern auf den Tenant begrenzt, statt dass sich jeder Handler selbst darum kümmern müsste.

DSGVO-Mechanik statt bloßer Behauptung

Osprey enthält einen Endpunkt für das Recht auf Vergessenwerden, der personenbezogene Daten — Formulareinreichungen, Akteure im Audit-Log, Nutzerkonten — zu einer angegebenen E-Mail-Adresse oder ID auf einen Tenant begrenzt schwärzt. Ein separater Export-Endpunkt erzeugt ein vollständiges Manifest der Inhalte eines Tenants für Anfragen zur Datenübertragbarkeit. Der eingebaute Cookie-Consent-Manager behandelt nur technisch notwendige Cookies als dauerhaft aktiv und setzt jede andere Kategorie standardmäßig auf abgelehnt, bis eine Einwilligung erfolgt, wobei „Alle ablehnen“ optisch gleich gewichtet ist wie „Alle akzeptieren“. Da Osprey selbst gehostet wird, kann ein Team es auch vollständig auf EU-Infrastruktur betreiben; dedizierte Garantien zur Datenresidenz in der EU sind Teil des Enterprise-Plans des Produkts und nicht Standard jeder Installation.

Headless mit Absicht

Osprey speichert Inhalte und liefert sie als JSON aus; es hat keine Meinung dazu, wie eine Website aussieht. Ein Team kann das Frontend in Astro, Next.js oder jedem statischen Site-Generator bauen, der eine REST-API aufrufen kann, und Osprey rein als Content-Schicht dahinter nutzen. Die aktuellen Pläne, einschließlich der selbstgehosteten und der Enterprise-Stufe, stehen auf der Osprey-Produktseite.

Was zu tun ist

• Das Content-Modell als TypeScript-Collections definieren und zusammen mit dem Anwendungscode versionieren.
• Für jede Collection, die über die öffentliche API bereitgestellt werden soll, eine explizite access.read-Regel setzen; ohne Regel bleibt die Collection privat.
• Den Loader @osprey/astro einbinden oder die REST-API direkt aufrufen, damit Inhalte zur Build-Zeit geladen werden statt bei jeder Anfrage.
• SEO-Felder pro Eintrag nur dort setzen, wo sie von den websiteweiten Standardwerten abweichen sollen, und den Rest den Standardwerten überlassen.
• Die eingebauten Export- und Recht-auf-Vergessenwerden-Endpunkte für Anfragen zu Datenübertragbarkeit und Löschung nutzen, statt eigene zu bauen.
• Wenn reines EU-Hosting für die Compliance wichtig ist, Osprey auf EU-Infrastruktur selbst hosten oder nach den Datenresidenz-Garantien des Enterprise-Plans fragen.

Quellen: Osprey-Produktseite, getosprey.dev.