Zum Hauptinhalt springen
Zurück zum Blog
Bereitstellung
14. Mai 2026 · 5 Min. LesezeitGinko Docs Team Ginko Docs Team

Statische oder serverbasierte Docs bereitstellen

Entscheide anhand des benötigten Laufzeitverhaltens zwischen generierten Dateien und einem Nitro-Server.

Eine Dokumentations-Site eignet sich oft für statisches Hosting. „Die Seiten bestehen hauptsächlich aus Markdown“ reicht als Entscheidungskriterium jedoch nicht aus. Entscheidend ist, welches Verhalten nach dem Build noch auf eingehende Requests reagieren muss.

Ginko Docs unterstützt beide Modelle. Optisch unterscheiden sie sich nicht: Generierte und servergerenderte Sites verwenden dieselben Routen, dieselbe Navigation, Suche und dieselben Content-Komponenten. Der Unterschied liegt bei den Antworten, die einen laufenden Nitro-Server benötigen.

Was ein statischer Build enthält

Eine generierte Site enthält die Teile, die Leser am häufigsten verwenden:

  • vorgerenderte Dokumentations-, Blog- und Startseiten;
  • Nuxt-Payloads für clientseitige Navigation;
  • die MiniSearch-Daten für die Befehlszentrale;
  • /raw/**.md-Kopien öffentlicher Seiten;
  • die Kataloge llms.txt und llms-full.txt;
  • Sitemap, Robots-Datei und generierte PNG-Social-Cards.

Browserfunktionen laufen auch nach der Bereitstellung. Suche, Bildvergrößerung, Sprachumschalter, Banner, Plausible Analytics und die Feedback-Oberfläche benötigen keinen Node-Server.

Statische Ausgabe ist deshalb ein guter Standard für öffentliche Dokumentation, deren Inhalte über einen Build veröffentlicht werden.

Was ein Nitro-Server ergänzt

Einige Funktionen hängen vom eingehenden HTTP-Request ab. Eine Nitro-Bereitstellung kann einen Accept: text/markdown-Header auswerten und für die normale Seiten-URL Markdown zurückgeben. Sie kann außerdem Link-Header setzen und den schreibgeschützten MCP-Endpunkt unter /mcp bereitstellen.

Ein Datei-Host kann dieses Verhalten nicht allein aus dem generierten Verzeichnis nachbilden. Er kann die expliziten Raw-Dateien und LLM-Kataloge ausliefern, aber weder eine Darstellung für dieselbe URL aushandeln noch MCP-Tools ausführen.

Verwende eine Server-Bereitstellung, wenn diese Request-Schnittstellen Teil des Produkts und nicht nur eine optionale Ergänzung sind.

Triff die Entscheidung ausdrücklich

AnforderungStatische AusgabeNitro-Server
Gerenderte Docs- und BlogseitenJaJa
Clientseitige SucheJaJa
Raw Markdown und LLM-KatalogeJaJa
Markdown Content NegotiationNeinJa
Link-Header zur LaufzeitNeinJa
MCP-EndpunktNeinJa

Bewirb /mcp nicht auf einer Site, die nur statische Dateien ausliefert. Die Einstellungen für Seitenaktionen können den Menüeintrag ausblenden, ändern aber nicht die Fähigkeiten des Hosting-Ziels.

Der Leitfaden zur Bereitstellung enthält die Befehle und Ausgabekontrollen für beide Ziele. Teste das bereitgestellte Artefakt; ein funktionierender Entwicklungsserver beweist das Verhalten des gewählten Hostings nicht.

War dieser Artikel hilfreich?