Saubere Daten. Dein Stack. Kein Kompromiss.

Nein. Inhaltstypen und Felder definierst du pro Projekt selbst — es gibt kein vorgegebenes Schema für «Seite», «Beitrag» oder «Produkt», an das du dich halten müsstest.

Zur Verfügung stehen dafür eigene Feldtypen für Text, Rich Text, Bilder, Dateien, Datum und Zeitraum, Koordinaten, Farben, Auswahllisten sowie Verknüpfungen zu anderen Inhalten. Ein Inhaltstyp «Veranstaltung» bekommt damit genau die Felder, die dein Projekt braucht, und nicht die, die der Anbieter vorgesehen hat.

Portabel bleibt das Ganze durch die OpenAPI-Spezifikation: Weil die Struktur maschinenlesbar beschrieben ist, lassen sich Inhalte vollständig exportieren und in ein anderes System überführen, ohne sie aus einem proprietären Format zurückzugewinnen.

Flyo ist um die Content Delivery API herum gebaut, und der Nachweis dafür ist die Redaktionsoberfläche selbst: Sie ist ein Client derselben öffentlichen API, die auch dein Frontend nutzt. Es gibt keinen internen Sonderweg und keinen Endpunkt, der nur intern erreichbar wäre.

Daraus folgen zwei überprüfbare Konsequenzen. Erstens: Alles, was im Editor sichtbar ist, lässt sich über die API abrufen — nicht nur Inhalte, sondern auch Navigationsstrukturen, Komponentenzusammensetzungen und Medienvarianten. Zweitens: Die Live-Vorschau im Editor läuft über denselben Auslieferungsweg wie die produktive Website, weshalb Vorschau und Ergebnis technisch nicht auseinanderlaufen können.

Bei nachträglich ergänzten APIs zeigt sich das Gegenteil meist schnell: Dort fehlen einzelne Felder, Navigationen sind nicht abrufbar, und die Vorschau funktioniert nur im System selbst.

Ja. Die Content Delivery API ist nicht auf Web-Frontends beschränkt — jedes System, das HTTP-Anfragen stellen kann, ruft Inhalte aus Flyo ab. In der Praxis betrifft das vor allem drei Fälle. Native und hybride Apps binden Flyo als Content-Backend an; für React Native ist der Betrieb dokumentiert. Digital-Signage-Systeme beziehen Inhalte direkt, sodass Screens ohne separate Signage-Redaktion auskommen. Und Drittsysteme wie Kassen-, CRM- oder Veranstaltungsplattformen greifen über die API auf dieselben Daten zu. Weil das Bildhandling über einen Image Proxy mit URL-Parametern läuft, muss ein App-Frontend keine eigenen Bildvarianten vorhalten — es fordert die benötigte Grösse zur Laufzeit an.

Headless-Architektur ist die Voraussetzung dafür, dass KI-Systeme Inhalte zuverlässig auslesen und zitieren können. Der Grund liegt in der Datenhaltung: In klassischen Systemen sind Inhalt und Darstellung vermischt, und ein Veranstaltungsdatum steht als Zeichenkette irgendwo im HTML. In einem Headless CMS liegt dasselbe Datum als Datumsfeld in einem strukturierten Datensatz — maschinell eindeutig interpretierbar.

Flyo setzt dabei auf einen Entity-First-Ansatz: Personen, Produkte, Orte und Events werden als eigenständige Einheiten mit definierten Feldern erfasst, nicht als Fliesstext auf einer Seite. Aus diesen Strukturen lassen sich Schema.org-Auszeichnungen wie Organization, Event oder Person automatisch erzeugen, die von Google AI Overviews, ChatGPT und Perplexity als Grundlage für Antworten verwendet werden.

Der zweite Effekt betrifft die Zugänglichkeit: Weil die Inhalte über eine API serverseitig ausgeliefert werden, sind sie auch für KI-Crawler lesbar, die kein JavaScript ausführen — anders als bei rein clientseitig gerenderten Websites.

Flyos API-first-Ansatz und die offene OpenAPI-Spezifikation machen einen Wechsel deutlich einfacher als bei Systemen mit proprietärem Datenmodell. Inhalte liegen strukturiert vor und sind vollständig über die API abrufbar — inklusive Feldstrukturen, Verknüpfungen und Mediendateien. Es gibt keinen Bestand, der nur über die Oberfläche zugänglich wäre.

Praktisch heisst das: Ein Export lässt sich als Script über die API fahren, und die Zielstruktur ist aus der Spezifikation ableitbar, statt durch Reverse Engineering rekonstruiert werden zu müssen. Eine architektonische Bindung an Flyo entsteht nicht.

Aufwand bleibt trotzdem — jede Migration bedeutet Mapping-Arbeit auf das Zielsystem. Der Unterschied liegt darin, ob dieser Aufwand kalkulierbar ist oder ob zuerst ein undokumentiertes Format entschlüsselt werden muss.

Ein klassisches CMS koppelt Inhaltspflege und Darstellung: Die Inhalte liegen in derselben Anwendung, die auch das HTML rendert, meist gebunden an ein Theme oder Template-System. Ein Headless CMS trennt beides — Inhalte werden strukturiert gespeichert und über eine Schnittstelle ausgeliefert, das Frontend ist ein beliebiger Abnehmer.

• Darstellung: Klassisch liegt das Template im CMS. Headless entscheidet das Frontend, was mit den Feldern passiert — statisch generiert, serverseitig gerendert oder als Single-Page-Application.
• Anzahl Abnehmer: Klassisch ist ein Inhalt eine Seite. Headless ist ein Inhalt ein Datensatz, den Website, App, Newsletter, Screen und Portal gleichzeitig beziehen.
• Framework-Wechsel: Klassisch bedeutet ein Technologiewechsel eine Inhaltsmigration. Headless betrifft er nur das Frontend; die Inhalte bleiben, wo sie sind.

Flyo liefert dafür strukturiertes JSON über eine dokumentierte REST-API mit vollständiger OpenAPI-Spezifikation. Ausführlicher Vergleich:

→ Vergleich Wordpress vs Flyo

Flyo pflegt offizielle SDK-Clients für PHP, JavaScript und Vue sowie dedizierte Integrationen für Laravel und Nuxt. Diese werden im eigenen Haus entwickelt und mit der API zusammen versioniert — es handelt sich nicht um Community-Beiträge.

Getestet und dokumentiert ist der Betrieb ausserdem mit Next.js, Astro und React Native. Da Flyo strukturiertes JSON über eine standardisierte REST-API ausliefert, funktioniert grundsätzlich jedes Framework, das HTTP-Anfragen stellen kann.

Für Sprachen ohne offiziellen Client — etwa Java, Python oder Go — generierst du dir den Adapter aus der vollständigen OpenAPI-Spezifikation. Der Vorteil gegenüber einem handgeschriebenen Client: Er bleibt automatisch synchron zur API, weil er aus deren Beschreibung entsteht.

Über Discord erreichst du das Flyo-Entwicklungsteam direkt — dieselben Personen, die das Produkt bauen. Es gibt kein Ticketsystem und keinen First-Level-Support dazwischen. Zusätzlich steht der Support-Chat direkt in der Flyo-Oberfläche zur Verfügung.

Feature-Wünsche und Bug-Meldungen laufen über denselben Weg; Releases erscheinen laufend und sind im öffentlichen Changelog nachvollziehbar. Entwickelt wird Flyo in Aarau, der Support kommt entsprechend aus derselben Zeitzone.

Flyo liefert Bilder über einen Image Proxy aus, bei dem Grösse und Format direkt als URL-Parameter angegeben werden. Du definierst keine Bildvarianten im CMS — das Frontend fordert die Auflösung an, die es gerade braucht, und Flyo erzeugt sie zur Laufzeit.

Für Entwicklungsteams entfallen damit zwei wiederkehrende Aufgaben: das Pflegen von Bildgrössen-Konfigurationen im Backend und das Nachgenerieren aller Varianten nach einem Layout-Wechsel. Ein neues Breakpoint-Set bedeutet lediglich andere URL-Parameter.

Die Assets liegen bei AWS in der Schweiz, ausgeliefert wird über Cloudflare als Edge-Layer.

Flyo ist eine 100%ige Eigenentwicklung der Heartbeat GmbH und kombiniert verschiedene Technologien in einer Mikroservice-Architektur. Flyo läuft in einem Managed Kubernetes Cluster in Münchenstein (managed by Mironet im IWB-Datenzentrum).

Services wie Edge Layer Caching (Varnish Cache), oder On the Fly Image Processing sorgen für eine hohe Performance und Entwicklerfreundlichkeit.

Die Daten werden in Zürich auf einem AWS-RDS-Aurora-Cluster gehostet, die Assets unserer Kunden — Bilder, PDFs und weitere Dateien — ebenfalls bei AWS in der Schweiz. Cloudflare dient als Edge-Security-Layer.

Asynchrone Prozesse, interne Caching-Algorithmen und ein Persistenzlayer sorgen für die sofortige Verarbeitung von Dateninputs über alle Publikationskanäle hinweg.

Für die kontinuierliche Gewährleistung der technischen Sicherheit arbeiten wir mit Compass Security zusammen, setzen auf kontinuierliches Uptime- und Error-Monitoring. Häufige Releases sorgen für regelmässig Updates und lassen sich im Changelog transparent nachvollziehen. DevOps-Engineering und umfangreiche Testing-Routinen gewährleisten eine hohe Uptime.

Belegbar sind diese Werte: Über das Jahr 2025 beantwortete die Content Delivery API 132 Millionen Requests bei einer Verfügbarkeit von 99,980 %. Im Tagesdurchschnitt sind es rund 850'000 Server-Requests.