Warum Hugo das perfekte Framework für CI/CD ist – und damit auch für KI-Pipelines
Ich will eine einfache, moderne Webseite. Kein Schnick-Schnack. Kein Cookie-Banner, kein Tracking, kein Kontaktformular, das nur Spam sammelt. Einfach schreiben, veröffentlichen, fertig.
WordPress war lange die erste Antwort. Aber WordPress heißt: zwanzig Plugins, tausend Themes, ständige Updates. Für eine Webseite, die nur Inhalte ausliefern soll, ist das zu viel.
Grav war einen Versuch wert. Aber das Template-System hat mich aufgehalten. Eine halbe Stunde nur, um das Menü zu verschieben. Für Leute ohne PHP-Kenntnisse ist Grav eine Sackgasse.
KI-Website-Bauer klingen verlockend. Dem Modell sagen, was man will, und es baut. In der Praxis halluziniert es Komponenten, die es nicht gibt. Ich muss den Output jedes Mal reviewen. Das ist kein Workflow, das ist Korrekturlesen.
Dann kam Hugo.
Ein Programm. Kein PHP, kein Node, keine Datenbank. Content in einfachem Text, Ausgabe als fertige HTML-Seiten. Hugo ist kein Framework im klassischen Sinne. Es ist ein Binary, das einmal läuft und fertig ist. Deshalb eignet es sich perfekt für Pipelines. Auch für KI-Workflows.
Der Status quo
Die meisten Web-Frameworks brauchen heute npm, Node.js oder einen Runtime-Wechsler wie nvm. Lokal ist das okay. In einer Pipeline wird es zum Problem: Der Docker-Container installiert erst alle Abhängigkeiten. Der Cache muss warm sein. Die Node-Version muss exakt passen.
Ein Next.js-Build braucht erst npm ci, dann Build, dann Export. Zwanzig Sekunden nur für npm ci. Bei Hugo: Binary laden, ausführen, fertig.
In KI-Pipelines wird das noch wichtiger. Ich lasse Sprachmodelle Inhalte generieren und direkt in den Bauprozess einspeisen. Jeder Schritt zwischen Modell und Ausgabe ist eine Fehlerquelle. Ein node_modules, das zur CI-Umgebung nicht passt, stoppt die ganze Pipeline.
Drei Argumente für Hugo
Erstens: Speed. Hugo baut meine Website in etwa fünf Sekunden. Astro oder Next.js brauchen dreißig bis sechzig Sekunden – mit warmem Cache. Der Unterschied: Hugo muss keinen JavaScript-Bundel erstellen, kein SSR rendern, keine Datenbank abfragen. Es nimmt Markdown und spuckt HTML aus. In CI/CD summiert sich das über alle Umgebungen. Und wenn ich in einem KI-Workflow zehn Iterationen fahre, sind das schnell Minuten Unterschied.
Zweitens: Eine Dependency. Hugo hat genau eine Abhängigkeit – Hugo. Kein node_modules, kein npm install, kein nvm use, kein npx. Deployment bedeutet: Binary runterladen, ausführen, fertig. Ich kann den Build in einen Docker-Scratch-Container legen oder direkt auf dem Host laufen lassen. In KI-Pipelines heißt das: deterministischer Build. Das Modell bekommt immer dieselbe Umgebung. Keine “works on my machine”-Probleme. Die Reproducibility, die Machine Learning eigentlich auszeichnet, gilt dann auch für den Output-Kanal.
Drittens: Statischer Output. Hugo produziert HTML-Dateien. Kein Server-Side Rendering, keine Edge-Runtime, keine Datenbank-Connection, die im Build-Prozess leben muss. Ein Ordner mit HTML-Dateien auf der Platte. Das ist der einzige Output, den CI/CD braucht – und der einzige, den KI-Modelle zuverlässig generieren können. Ich kann LLM-Output als Markdown-Datei ablegen, Hugo liest sie beim nächsten Build, und fertig. Kein Parser, kein Renderer, keine API dazwischen.
Die andere Seite
“Aber Hugo kann keine dynamischen Inhalte.” Stimmt. Kommentare, Suche, Login? Alles Drittanbieter. Aber das ist kein Nachteil – es ist eine kluge Trennung. Jeder Dienst macht genau eine Sache. Die Pipeline bleibt einfach. Ich habe gelernt: Je klarer die Grenzen, desto stabiler das System. Hugo erzwingt diese Klarheit.
Fazit
Das beste Framework für Pipelines ist das, das du nicht installieren musst. Hugo ist dieses Framework. Und je komplexer deine Pipeline wird – ob CI/CD oder KI – desto wertvoller wird diese Eigenschaft.
Wer seinen nächsten Blog mit Next.js startet, sollte wissen: Es geht auch ohne node_modules. Vielleicht sogar besser.