fastsite ist eine Publishing-Engine, kein CMS. Sie senden Inhalte, es produziert vollständig statisches HTML, committet es pro Website und lässt Ihr CDN es ausliefern. Hier ist das gesamte Modell, von Anfang bis Ende.

1. Sie senden Inhalte, keine Seiten

Inhalte sind body-only-HTML. Sie erstellen nie eine vollständige Seite — die Shell besitzt das Chrome, und die Engine umhüllt jeden Body beim Build damit. Es gibt vier Eingabewege, und sie alle landen am selben Ort:

  • REST — POST /api/v1/sites/{site}/content mit einem API-Schlüssel.
  • MCP — die Werkzeuge create_post und create_page, unter OAuth-Zustimmung.
  • Webhooks — ein HMAC-signiertes Payload von einem vorgelagerten System, das einem Beitrag, einer Seite, einem Medienimport oder einer Komponente zugeordnet wird.
  • Das Dashboard — für den Fall, dass Sie es lieber selbst eintippen möchten.

Jeder dieser Wege durchläuft denselben Sanitizer: eine feste Tag-Allowlist, entfernte Inline-Styles, entfernte Scripts und iframes. Probleme werden als Warnungen an den Datensatz angehängt — sie werden normalisiert und veröffentlicht, nie in eine fehlgeschlagene Anfrage umgewandelt. Ein fehlerhaftes Einfügen sollte Ihre Pipeline nicht blockieren können.

2. Die Shell besitzt alles andere

Die Shell ist ein kleiner Baum aus Twig-Templates, einem tokens.css-Designsystem und lokalisierten UI-Strings. Sie ist das gesamte Design der Website, und sie ist das, was ein KI-Agent über die API oder MCP liest und neu schreibt.

Ändern Sie einen Token, und die gesamte Website wird beim nächsten Build neu gestaltet. Da das Design an einem einzigen Ort liegt und Inhalt stets nur ein Body ist, gibt es keinen Template-Drift zwischen Seiten und nichts zu migrieren, wenn sich das Design ändert.

Shell-Schreibvorgänge sind geschützt — Pfad-Containment, eine Erweiterungs-Allowlist, eine Größenbeschränkung — und ein Template, das beim Audit einen Fehler auslösen würde, wird beim Speichern abgelehnt, nicht wenn der Build läuft. Erstellen Sie vor einer riskanten Änderung einen Snapshot; die Wiederherstellung erstellt zuerst einen eigenen Snapshot, sodass das Rückgängigmachen selbst rückgängig gemacht werden kann.

3. Die Engine erstellt statisches HTML

Bei jedem Build führt die Engine Folgendes aus:

  • Expandiert <img data-media-id> in responsives <picture>-Markup — AVIF und WebP in fünf Breiten, ein Fallback im Originalformat, explizite Abmessungen und Lazy-Loading überall außer beim Featured Image, das stattdessen vorgeladen wird.
  • Rendert Komponenten zu statischem Markup. React-Komponenten werden zum Build-Zeitpunkt serverseitig gerendert und das Ergebnis ist HTML — das Framework erreicht den Browser nie.
  • Bindet minifiziertes CSS mit Tokens an erster Stelle ein und liefert überhaupt kein JavaScript aus.
  • Schreibt einen vollständigen Head: Titel, Beschreibung, Canonical, Open Graph und JSON-LD.
  • Generiert sitemap.xml, robots.txt, llms.txt, Cache-Header und Weiterleitungen — einschließlich einer Weiterleitung, die automatisch angehängt wird, wenn sich ein Slug ändert, sodass alte Links weiterhin funktionieren.

Builds sind inkrementell. Ein Manifest verfolgt den Hash jeder Ausgabedatei, sodass nur das tatsächlich Geänderte geschrieben wird, und Dateien, deren Quelle verschwunden ist, werden gelöscht statt verwaist zurückgelassen.

4. Das Audit entscheidet, was ausgeliefert werden darf

Ein perfektes Ergebnis ist nichts, was Sie nachträglich anstreben — es wird durchgesetzt, bevor irgendetwas geschrieben wird. Jeder Build führt ein Seiten-Audit durch, das zwei Arten von Problemen trennt:

  • Fehler blockieren den Build. Eine fehlende Bildgröße oder ein fehlendes Alt-Attribut, eine externe Ressource, ein ausgeliefertes <script>, ein Stylesheet über Budget — das sind Pipeline-Invarianten, und ein Build, der eine davon verletzen würde, wird nicht abgeschlossen.
  • Warnungen blockieren ihn nie. Eine übersprungene Überschriftenebene, eine schwere Seite, ein Nicht-Apex-Canonical, ein nicht crawlbarer Link — das sind inhaltliche Auffälligkeiten. Sie werden gemeldet und die Seite wird trotzdem veröffentlicht.

Die Trennung ist der springende Punkt. Die Engine weigert sich, ihre eigenen Garantien zu brechen, und weigert sich, Ihre Inhalte wegen einer Stilmeinung als Geisel zu halten.

Das hohe Ziel: 100/100/100/100 auf Google PageSpeed für jede veröffentlichte Seite. Das Audit hält dieses Versprechen ehrlich.

5. Es committet und deployed

Veröffentlichen ist ein expliziter Schritt, kein Nebeneffekt. Das Schreiben von Inhalten speichert sie; das Veröffentlichen baut die Website und pusht sie. Das bedeutet, dass ein Agent oder ein Skript beliebig viel entwerfen, überarbeiten und bereitstellen kann, ohne dass irgendetwas Ihre Besucher erreicht.

Wenn ein Publish-Vorgang ausgeführt wird, wird die Ausgabe in das Git-Repository Ihrer Website committet — ein Commit pro Publish — und gepusht. Ihr statischer Hoster baut beim Push. Cloudflare Pages ist das, was diese Website verwendet; alles, was ein Repository überwacht, funktioniert genauso.

Builds und Publishes laufen in einer Queue, sodass der Aufruf, der einen auslöst, sofort zurückkehrt und Sie das Ergebnis abfragen. Fehler werden mit Backoff wiederholt, anstatt zu verschwinden, und eine Reihe von Bearbeitungen wird zu einem einzigen Build zusammengefasst, statt einem pro Änderung.

Da jeder Publish ein Commit ist, ist Ihr Deployment-Verlauf auch ein Rollback-Mechanismus. Es wird nichts Dynamisches deployed: kein Runtime am Edge, keine aus dem Internet erreichbare Datenbank und kein Origin, der unter Last ausfallen kann.

Mehr als eine Sprache

Fügen Sie eine Locale hinzu, und die Engine übersetzt veröffentlichte Inhalte und die UI-Strings der Shell in diese, und baut dann neu. Die primäre Locale sitzt im Root und jede weitere erhält ihren eigenen Teilbaum, mit hreflang-Alternates und x-default, die über den gesamten Cluster verdrahtet sind, sowie einer Sitemap pro Sprache.

Übersetzungen werden pro Zeile gegen den Hash ihrer Quelle nachverfolgt, sodass das Bearbeiten eines Absatzes diese Seite neu übersetzt und nichts anderes. Alles, was Sie als manuell übersetzt markieren, wird nie überschrieben. Eine Seite, für die noch keine Übersetzung vorliegt, ist in dieser Sprache einfach nicht vorhanden — Besuchern wird nie eine Seite angezeigt, die stillschweigend auf die falsche zurückfällt.

Schnellstart

  1. Erstellen Sie eine Website und gestalten Sie deren Shell, oder beginnen Sie mit dem Standard-Scaffold.
  2. Erstellen Sie einen API-Schlüssel oder verbinden Sie einen Agenten über MCP.
  3. Senden Sie einen Beitrag und veröffentlichen Sie ihn. Beobachten Sie, wie eine statische Seite erscheint, committet und live.
  4. Erstellen Sie jederzeit eine Vorschau ohne Deployment — der Vorschau-Build ist in sich geschlossen und benötigt keinen Server.
  5. Fügen Sie eine Locale hinzu und lassen Sie die Engine den Baum übersetzen und neu ausgeben.

Bereit für Details? Lesen Sie die REST-API-Referenz, die MCP-Referenz oder die Webhooks-Anleitung. Wenn Sie Ihre eigene Engine einrichten, beginnen Sie mit Installation.