Der passende Plan für dein Projekt

Nein. Flyo kauft keine zusätzlichen Credits automatisch. Wenn dein monatliches Credit-Kontingent aufgebraucht ist, entstehen dadurch nicht automatisch zusätzliche Kosten.

Du entscheidest selbst, ob und wann du weiteres Prepaid-Guthaben kaufst.

Zusätzliche Credits können jederzeit über die Flyo-Oberfläche per Kreditkarte gekauft werden. Sie kosten CHF 10 pro 100 Credits und verfallen im Gegensatz zu den im Abo enthaltenen Credits nicht am Monatsende.

Das schützt dich vor ungeplanten oder automatisch ausgelösten Usage-Kosten.

Flyo rechnet nicht ausschliesslich nach Seitenaufrufen ab, weil Seitenaufrufe die tatsächlich benötigte Serverleistung einer Website nicht zuverlässig abbilden.

Zwei Websites mit derselben Anzahl Seitenaufrufe können sehr unterschiedliche Anforderungen an die Infrastruktur stellen. Eine einfache Website benötigt beispielsweise deutlich weniger Serverleistung als eine komplexe Headless-CMS-Anwendung mit API-Abfragen, Suchfunktionen, dynamischen Inhalten und Integrationen.

Das Flyo-Credit-Modell berücksichtigt deshalb sowohl:

• die Anzahl der Server-Requests
• als auch die benötigte Serverleistung

Dadurch wird nicht einfach der Traffic, sondern die tatsächliche Nutzung der Flyo-Infrastruktur berücksichtigt.

Als Headless Content Hub können neben Websites auch weitere Kanäle wie Signage Screens, Newsletter, usw. gesteuert werden. Diese Verbindungen können nicht in Seitenaufrufen gemessen werden, fallen normalerweise im Vergleich zu Websites aber viel weniger stark ins Gewicht.

Ein Server-Request ist eine Anfrage einer Website, Anwendung oder API an einen Flyo-Server. Beispielsweise kann eine Website einen Request an Flyo senden, um Inhalte aus dem Headless CMS abzurufen.

Ein einzelner Seitenaufruf kann mehrere Server-Requests auslösen. Beispielsweise können beim Laden einer Seite Inhalte, Navigationen, Suchresultate oder weitere dynamische Daten über die Flyo API angefragt werden.

Flyo berechnet 0.05 Credits pro Server-Request.

Die Anzahl der Server-Requests hängt deshalb nicht nur vom Traffic ab, sondern auch davon, wie eine Website technisch aufgebaut ist und welche Funktionen sie verwendet.

Eine Server-Minute misst die Zeit, während der Flyo Serverleistung für die Verarbeitung deiner Anfragen und Anwendungen benötigt. Sie bildet damit den tatsächlichen Rechenaufwand ab und ergänzt die reine Anzahl der Server-Requests.

Flyo berechnet 30 Credits pro genutzter Server-Minute.

Dadurch berücksichtigt das Preismodell nicht nur, wie viele Anfragen verarbeitet werden, sondern auch, wie viel Rechenleistung für diese Verarbeitung erforderlich ist.

Das ist insbesondere bei komplexen Headless-CMS-Projekten, APIs und datenintensiven Anwendungen relevant.

Wenn dein monatliches Credit-Kontingent aufgebraucht ist, wird die flyo-Oberfläche für das Hinzufügen und Bearbeiten von Inhalten, Social-Media-Posts und Integrationen blockiert. Bestehende Integrationen laufen jedoch weiterhin. Deine Website und deine Integrationen werden nicht offline geschaltet. Sie können lediglich nicht mehr bearbeitet werden, und es können keine neuen Inhalte oder Integrationen hinzugefügt werden.

Wenn dein monatliches Credit-Kontingent aufgebraucht ist, kannst du zusätzliche Credits als Prepaid-Guthaben kaufen. Flyo kauft zusätzliche Credits nicht automatisch.

Zusätzliche Credits kosten aktuell (Stand: August 2026)

100 Credits = CHF 10

Gekaufte Credits werden deinem Prepaid-Guthaben gutgeschrieben und verfallen nicht am Monatsende.

Damit kannst du auch bei vorübergehend höherem Traffic oder einer unerwartet hohen Servernutzung zusätzliche Kapazität bereitstellen, ohne dein bestehendes Abo wechseln zu müssen.

Flyo berechnet Credits anhand der Anzahl Server-Requests und der dafür benötigten Serverleistung.

Die aktuelle Berechnung erfolgt nach zwei Komponenten:

• 0.05 Credits pro Server-Request
• 30 Credits pro genutzter Server-Minute

Die beiden Werte bilden zusammen die tatsächliche Nutzung der Flyo-Server ab. Ein Seitenaufruf entspricht deshalb nicht automatisch einem bestimmten Credit-Verbrauch, da ein Seitenaufruf je nach Website und technischer Implementierung unterschiedlich viele Server-Requests und unterschiedlich viel Serverleistung verursachen kann.

Jedes Abo enthält ein monatliches Credit-Kontingent.

Credits werden für die tatsächliche Nutzung der Flyo-Server verbraucht, insbesondere für Server-Requests und die dafür benötigte Serverleistung. Die reine Anzahl von Benutzern, Redakteuren oder Inhalten bestimmt den Credit-Verbrauch nicht.

Typischerweise relevant für den Credit-Verbrauch sind:

• API-Anfragen an Flyo
• Server-Requests beim Abrufen von Inhalten
• serverseitige Verarbeitung
• benötigte Serverleistung und Rechenzeit
• dynamische Funktionen und Anwendungen, die Flyo-Serverleistung benötigen

Nicht direkt nach einer fixen Menge berechnet werden beispielsweise:

• Anzahl Benutzer
• Anzahl Redakteure
• Anzahl Inhalte
• Anzahl Websites
• Anzahl Seiten im CMS

Entscheidend ist immer die tatsächliche Nutzung der Flyo-Infrastruktur.

Ein wichtiger Unterschied ist dabei: Mehr Inhalte bedeuten nicht automatisch mehr Credits. Eine Website kann sehr viele Inhalte enthalten und trotzdem wenig Serverleistung benötigen. Umgekehrt kann eine Website mit relativ wenigen Inhalten bei hohem Traffic oder aufwendiger Verarbeitung einen höheren Credit-Verbrauch haben.

Datenbank (AWS Zürich)

• Sicherung: Kontinuierliche Transaktionsprotokollierung ergänzt durch ein tägliches Vollbackup. Dadurch ist eine Wiederherstellung auf einen frei wählbaren Zeitpunkt möglich, nicht nur auf den letzten Tagesstand.
• Aufbewahrung: 20 Tage, ältere Sicherungen werden automatisch gelöscht. Vor grösseren Releases werden zusätzlich manuelle Sicherungspunkte erstellt.
• Redundanz: Die Daten werden synchron über drei getrennte Verfügbarkeitszonen repliziert. Der Ausfall einer Zone führt zu keinem Datenverlust.
• RPO: maximal 5 Minuten.
• RTO: Wiederherstellung aus Backup innerhalb von 4 Stunden während der Servicezeiten. Beim Ausfall einer einzelnen Verfügbarkeitszone erfolgt die Umschaltung automatisch ohne Datenverlust.

Assets (AWS Zürich)

• Versionierung: Jede Änderung und Löschung an einer Datei wird als eigene Version gespeichert. Versehentlich gelöschte oder überschriebene Assets sind wiederherstellbar.
• Aufbewahrung: Unbefristet. Es ist keine automatische Löschung konfiguriert, alle früheren Versionen bleiben dauerhaft erhalten.
• RPO: 0 bei versehentlicher Löschung oder Überschreibung, da jede Version unmittelbar erhalten bleibt.

Unabhängiger Datenexport (AWS Zürich)

• Erstellung: Automatisiert, mit einem garantierten Höchstintervall von 14 Tagen. Erstellt wird jeweils ein vollständiger, in sich abgeschlossener Stand der Inhalte einer Organisation: strukturierte Inhalte, das heisst alle Schemas mit sämtlichen Datensätzen, als JSON sowie alle Assets als unveränderte Originaldateien.
• Aufbewahrung: Die zwei jüngsten Stände in einem separaten AWS-Bucket in Zürich (eu-central-2) ausserhalb der produktiven Infrastruktur, mit eigenen Zugangsdaten und ausschliesslich lesendem Zugriff auf die Originaldaten. Ältere Stände werden automatisch überschrieben.
• Zweck: Letzte Rückfallebene, falls alle anderen Sicherungsebenen ausfallen, sowie Grundlage für die Herausgabe eines vollständigen Datenexports auf Anfrage. Vom Prinzip her vergleichbar mit Google Takeout, jedoch nicht als Self-Service-Download.
• Nicht enthalten: Benutzer- und Rollenverwaltung, Integrationen und Verbindungen sowie Organisationseinstellungen.

Applikation (Kubernetes Cluster)

• Storage-Snapshots: Erstellung alle 15 Minuten, mit Wiederherstellungspunkten für bis zu 5 Tage.
• Backups: Zusätzlich werden die Systeme zweimal täglich gesichert. Die regulären Backups werden 2 Wochen aufbewahrt; zusätzliche Wochen- und Monatsstände ermöglichen Wiederherstellungen über einen längeren Zeitraum von bis zu 90 Tagen.
• Georedundanz: Die Backups werden zusätzlich in ein zweites, räumlich getrenntes Rechenzentrum repliziert. Damit ist eine Wiederherstellung auch beim vollständigen Ausfall eines Standorts möglich.
• RPO: Im regulären Restore-Fall beträgt der maximale Datenverlust aufgrund der 15-minütigen Snapshot-Intervalle 15 Minuten. Bei einem vollständigen Disaster-Recovery-Szenario mit Verlust eines Rechenzentrums beträgt der RPO maximal 12 Stunden.
• RTO: Die Wiederherstellungszeit hängt von Umfang und Art des Ausfalls ab. Einzelne Systeme können in der Regel innerhalb weniger Stunden wiederhergestellt werden; bei grösseren Disaster-Recovery-Szenarien erfolgt die Wiederherstellung priorisiert nach Kritikalität der Systeme.

Hinweis

Bei einer Wiederherstellung mehrerer Systeme gilt der jeweils höchste RPO der beteiligten Komponenten.

Standard Support: Du erreichst uns via support@flyo.cloud und erhältst von uns während den Geschäftszeiten (Montag bis Freitag, 9-17 Uhr) innert 2 Arbeitstagen eine Antwort.

Premium Support: Du erreichst uns via Ticket-Tool direkt über die Flyo-Oberfläche und erhältst von uns innert weniger Stunden einen Lösungsvorschlag.

Account Manager: Du hast eine dedizierte Ansprechperson aus dem Flyo-Team und stehst via privatem Discord-Channel im Austausch mit dem Support-Team.

SLA: Auf Wunsch bieten wir individuelle SLA-Vereinbarungen an.

Flyo rechnet nicht direkt nach Seitenaufrufen ab, deshalb gibt es keine fixe Anzahl von Seitenaufrufen pro Abo.Entscheidend ist die tatsächliche Servernutzung.

Zwei Websites mit beispielsweise 100'000 Seitenaufrufen können einen unterschiedlichen Credit-Verbrauch haben. Eine einfache Website kann einen Seitenaufruf mit sehr wenig Serverleistung bedienen, während eine komplexe Website mehrere API-Anfragen und zusätzliche serverseitige Verarbeitung benötigt.

Die enthaltenen Credits sind deshalb besser als Nutzungskontingent für die gesamte Flyo-Infrastruktur zu verstehen und nicht als fixe Anzahl Seitenaufrufe.

Der Verbrauch hängt von der technischen Umsetzung, dem Traffic, Caching und den verwendeten Funktionen ab.