fastsite er en publiceringsmotor, ikke et CMS. Du sender indhold, den producerer fuldt statisk HTML, committer det per site og lader dit CDN servere det. Her er hele modellen, fra start til slut.

1. Du sender indhold, ikke sider

Indhold er body-only HTML. Du forfatter aldrig en hel side — skallen ejer kromstylingen, og motoren pakker hvert body-element ind i den ved byggetid. Der er fire måder at komme ind på, og de lander alle samme sted:

  • REST — POST /api/v1/sites/{site}/content med en API-nøgle.
  • MCP — værktøjerne create_post og create_page, under OAuth-samtykke.
  • Webhooks — en HMAC-signeret payload fra et opstrømssystem, mappet til et indlæg, en side, medieimport eller komponent.
  • Dashboardet — til når du hellere bare vil skrive det selv.

Hver af disse stier kører den samme sanitizer: en fast tilladte-tag-liste, inline-styles fjernes, scripts og iframes slettes. Problemer bliver til advarsler knyttet til posten — de normaliseres og publiceres, og bliver aldrig til en fejlet forespørgsel. Et fejlagtigt indsæt bør ikke kunne blokere din pipeline.

2. Skallen ejer alt andet

Skallen er et lille træ af Twig-skabeloner, et tokens.css-designsystem og per-locale UI-strenge. Det er hele sitets design, og det er det, en AI-agent læser og omskriver via API eller MCP.

Skift et token, og hele sitet skifter udseende ved næste build. Fordi designet lever ét sted, og indhold altid kun er et body-element, opstår der ingen skabelonafvigelse mellem sider, og der er intet at migrere, når designet ændres.

Skrive-operationer til skallen er beskyttede — stiindeslutning, en tilladte-udvidelser-liste, en størrelsesgrænse — og en skabelon, der ville kaste en fejl eller ikke bestå auditten, afvises når du gemmer den, ikke når bygget kører. Tag et snapshot før en risikabel ændring; gendannelse tager sit eget snapshot først, så fortrydelsen i sig selv kan fortrydes.

3. Motoren bygger statisk HTML

Ved hvert build gør motoren følgende:

  • Udvider <img data-media-id> til responsivt <picture>-markup — AVIF og WebP i fem bredder, et fallback i originalformat, eksplicitte dimensioner og lazy-loading overalt undtagen på det fremhævede billede, som i stedet forudindlæses.
  • Renderer komponenter til statisk markup. React-komponenter server-renderes ved byggetid, og resultatet er HTML — frameworket når aldrig browseren.
  • Inliner minificeret CSS med tokens først og sender slet ingen JavaScript.
  • Skriver et komplet head: title, description, canonical, Open Graph og JSON-LD.
  • Genererer sitemap.xml, robots.txt, llms.txt, cache-headere og redirects — herunder en redirect der automatisk tilføjes når en slug ændres, så gamle links fortsat virker.

Builds er inkrementelle. Et manifest sporer hash-værdien for hver outputfil, så kun det, der rent faktisk er ændret, skrives, og filer hvis kilde er forsvundet slettes i stedet for at blive efterladt forældreløse.

4. Auditten afgør, hvad der må sendes live

En perfekt score er ikke noget, du jagter bagefter — den håndhæves, inden noget skrives. Hvert build kører en sideaudit, der adskiller to slags problemer:

  • Fejl blokerer bygget. En manglende billeddimension eller alt-attribut, en ekstern ressource, et medsendt <script>, et stylesheet over budget — disse er pipeline-invarianter, og et build der ville bryde én af dem, fuldføres ikke.
  • Advarsler blokerer aldrig. Et sprunget overskriftsniveau, en tung side, en ikke-apex canonical, et link der ikke er crawlbart — disse er indholdsmæssige lugtesager. De rapporteres, og siden publiceres alligevel.

Adskillelsen er pointen. Motoren nægter at bryde sine egne garantier og nægter at holde dit indhold som gidsel på grund af en stilmæssig holdning.

Det hårde mål: 100/100/100/100 på Google PageSpeed for hver publiceret side. Auditten er det, der holder det løfte ærligt.

5. Den committer og deployer

Publicering er et eksplicit trin, ikke en sideeffekt. At skrive indhold gemmer det; publicering bygger sitet og pusher det. Det betyder, at en agent eller et script kan udkaste, revidere og stage så meget som ønsket, uden at noget når dine besøgende.

Når en publicering køres, committes outputtet til dit sites git-repository — ét commit per publicering — og pushes. Din statiske vært bygger ved push. Cloudflare Pages er hvad dette site bruger; alt der overvåger et repo fungerer på samme måde.

Builds og publiceringer kører i en kø, så det kald der udløser én returnerer øjeblikkeligt, og du poller for resultatet. Fejl forsøges igen med backoff i stedet for at forsvinde, og en serie af redigeringer samles til ét enkelt build i stedet for ét per ændring.

Fordi hvert publish er et commit, er din deployment-historik også en rollback-mekanisme. Intet dynamisk deployes: ingen runtime på kanten, ingen database tilgængelig fra internettet og ingen oprindelse der kan falde under belastning.

Mere end ét sprog

Tilføj en locale, og motoren oversætter publiceret indhold og shellens UI-strenge til den og genopbygger. Den primære locale sidder i roden, og hver yderligere får sit eget undertræ med hreflang-alternativer og x-default koblet op på tværs af hele clusteret samt et sitemap per sprog.

Oversættelser spores per række mod hash-værdien af deres kilde, så redigering af ét afsnit gen-oversætter den pågældende side og intet andet. Alt du markerer som manuelt oversat overskrives aldrig. En side der endnu ikke har en oversættelse er simpelthen fraværende på det pågældende sprog — besøgende præsenteres aldrig for en side, der stille og roligt falder tilbage til den forkerte.

Hurtigstart

  1. Opret et site og design dets skal, eller start fra standardstilladset.
  2. Opret en API-nøgle, eller tilslut en agent via MCP.
  3. Send et indlæg, og publicér det. Se en statisk side opstå, committet og live.
  4. Forhåndsvis til enhver tid uden at deploye — preview-bygget er selvstændigt og kræver ingen server.
  5. Tilføj en locale og lad motoren oversætte og gen-emittere træet.

Klar til det specifikke? Læs REST API-referencen, MCP-referencen eller webhooks-gennemgangen. Hvis du selv sætter en motor op, så start med installation.