fastsite är en publiceringsmotor, inte ett CMS. Du skickar innehåll, den producerar helt statisk HTML, committar det per sajt och låter ditt CDN serva det. Här är hela modellen, från början till slut.

1. Du skickar kroppar, inte sidor

Innehåll är body-only HTML. Du skriver aldrig en hel sida — skalet äger krom, och motorn lindar varje body i det vid byggtid. Det finns fyra sätt att komma in, och de landar alla på samma ställe:

  • REST — POST /api/v1/sites/{site}/content med en API-nyckel.
  • MCP — verktygen create_post och create_page, under OAuth-samtycke.
  • Webhooks — en HMAC-signerad payload från ett uppströms system, mappad till ett inlägg, en sida, en mediaimport eller en komponent.
  • Instrumentpanelen — för när du hellre bara vill skriva det själv.

Var och en av dessa vägar kör samma sanitizer: en fast tillåten tagglista, inline-stilar borttagna, skript och iframes borttagna. Problem blir varningar kopplade till posten — de normaliseras och publiceras, förvandlas aldrig till en misslyckad begäran. En dålig inklistring ska inte kunna sätta stopp för din pipeline.

2. Skalet äger allt annat

Skalet är ett litet träd av Twig-mallar, ett tokens.css-designsystem och gränssnittssträngarna per språk. Det är hela sajtens design, och det är vad en AI-agent läser och skriver om via API:et eller MCP.

Ändra en token och hela sajten byter tema vid nästa bygge. Eftersom designen bor på ett ställe och innehåll alltid bara är en body förekommer ingen malldrift mellan sidor och inget att migrera när designen ändras.

Skalskrivningar är bevakade — sökvägsbegränsning, en tillåten tilläggslista, en storleksgräns — och en mall som skulle kasta fel eller misslyckas i granskningen avvisas när du sparar den, inte när bygget körs. Ta en ögonblicksbild före en riskabel ändring; återställning tar sin egen ögonblicksbild först, så att ångringen i sig är ångransbar.

3. Motorn bygger statisk HTML

Vid varje bygge:

  • Expanderar motorn <img data-media-id> till responsiv <picture>-markup — AVIF och WebP i fem bredder, en originalformats-fallback, explicita dimensioner och lazy-loading överallt utom för den utvalda bilden, som istället förladdas.
  • Renderar komponenter till statisk markup. React-komponenter server-renderas vid byggtid och resultatet är HTML — ramverket når aldrig webbläsaren.
  • Infogar minifierad CSS med tokens först och skickar ingen JavaScript alls.
  • Skriver ett komplett head: titel, beskrivning, kanonisk, Open Graph och JSON-LD.
  • Genererar sitemap.xml, robots.txt, llms.txt, cache-headers och omdirigeringar — inklusive en omdirigering som automatiskt läggs till när en slug ändras, så att gamla länkar fortsätter fungera.

Byggen är inkrementella. Ett manifest spårar hashen för varje utdatafil, så att bara det som faktiskt ändrats skrivs, och filer vars källa försvunnit raderas i stället för att lämnas som föräldralösa.

4. Granskningen avgör vad som får skickas

Ett perfekt resultat är inget du jagar i efterhand — det verkställs innan något skrivs. Varje bygge kör en sidgranskning som separerar två typer av problem:

  • Fel blockerar bygget. En saknad bilddimension eller alt-attribut, en extern resurs, ett levererat <script>, en stilmall över budget — dessa är pipeline-invarianter, och ett bygge som skulle bryta mot en av dem slutförs inte.
  • Varningar blockerar aldrig det. En hoppad rubriknivå, en tung sida, en icke-apex-kanonisk, en länk som inte kan crawlas — dessa är innehållslukt. De rapporteras och sidan publiceras ändå.

Uppdelningen är poängen. Motorn vägrar att bryta sina egna garantier, och vägrar att hålla ditt innehåll som gisslan på grund av en stilåsikt.

Det hårda målet: 100/100/100/100 på Google PageSpeed för varje publicerad sida. Granskningen är det som håller det löftet ärligt.

5. Den committar och driftsätter

Publicering är ett explicit steg, inte en sidoeffekt. Att skriva innehåll lagrar det; publicering bygger sajten och pushar den. Det betyder att en agent eller ett skript kan utkasta, revidera och mellanlagra hur mycket som helst utan att något når dina besökare.

När en publicering körs committas utdata till din sajts git-repository — en commit per publicering — och pushas. Din statiska värd bygger vid push. Cloudflare Pages är vad den här sajten använder; allt som bevakar ett repo fungerar på samma sätt.

Byggen och publiceringar körs i en kö, så anropet som triggar ett returnerar omedelbart och du pollar efter resultatet. Misslyckanden görs om med backoff i stället för att försvinna, och en burstig redigering samlas ihop till ett enda bygge snarare än ett per ändring.

Eftersom varje publicering är en commit är din driftsättningshistorik också en återställningsmekanism. Inget dynamiskt driftsätts: ingen runtime vid kanten, ingen databas nåbar från internet och inget ursprung som kan falla under belastning.

Mer än ett språk

Lägg till ett språk och motorn översätter publicerat innehåll och skalets gränssnittssträngar till det, och bygger sedan om. Det primära språket finns vid roten och varje ytterligare ett får sitt eget underträd, med hreflang-alternativ och x-default uppkopplade över hela klustret och en webbplatskarta per språk.

Översättningar spåras per rad mot hashen av sin källa, så att redigering av ett stycke återöversätter den sidan och inget annat. Allt du markerar som manuellt översatt skrivs aldrig över. En sida som ännu inte har en översättning är helt enkelt frånvarande på det språket — besökare serveras aldrig en sida som tyst faller tillbaka till fel en.

Snabbstart

  1. Skapa en sajt och designa dess skal, eller börja från standardställningen.
  2. Skapa en API-nyckel, eller anslut en agent via MCP.
  3. Skicka ett inlägg och publicera sedan. Se en statisk sida visas, committad och live.
  4. Förhandsgranska när som helst utan att driftsätta — förhandsgranskningsbygget är fristående och behöver ingen server.
  5. Lägg till ett språk och låt motorn översätta och återge trädet.

Redo för detaljer? Läs REST API-referensen, MCP-referensen eller webhooks-genomgången. Om du sätter upp en egen motor, börja med installation.