Hugo auf Lizard bereitstellen

Lizard kann eine Hugo-Quellseite mit hugo --minify bauen und public/ über nginx auf Port 80 ausliefern. Starte im Hugo-Quellverzeichnis mit einer Hugo-Konfiguration und content/, statt nur das generierte HTML hochzuladen.

Beginne mit dem vollständigen Quellbeispiel, das die Konfiguration und Dateien enthält, die in dieser Anleitung verwendet werden.

Quelle vorbereiten

Füge deine Hugo-Konfiguration, Inhalte, Layouts, Assets und alle Theme-Dateien ein, die der Build benötigt. Die Hugo-Erkennung sucht nach einer Konfiguration wie hugo.toml, hugo.yaml oder config/_default/ sowie nach einem Verzeichnis content/.

EinstellungWert
Buildhugo --minify
Outputpublic/
Produktionsservernginx
Service-Port80

Setze baseURL auf die vorgesehene öffentliche Website-URL einschließlich des abschließenden Schrägstrichs. Baue nach der Zuweisung eines anderen Hostnamens neu, damit Links und generierte Sitemap-Einträge ihn verwenden. Siehe Hugos Anleitung zu Build und Output.

Build-Abhängigkeiten prüfen

Das Standard-Build-Image für Hugo ist hugomods/hugo:base; es legt für dein Projekt keine Hugo-Version fest. Wenn ein Theme eine bestimmte Hugo-Version, die Extended Edition oder Node-Tooling benötigt, verwende ein vollständiges Dockerfile mit diesen Abhängigkeiten und der Version, die du getestet hast.

Eine Hugo-Konfiguration und content/ wählen den Hugo-Builder vor der Erkennung von Go oder Node aus. Projekte mit Hugo Modules und go.mod verwenden ein Build-Image mit Go-Unterstützung. Eine package.json beendet den Build mit der Aufforderung, ein Dockerfile bereitzustellen: Installiere die Node-Abhängigkeiten, baue die Assets und führe dann hugo --minify aus. Siehe Reihenfolge der Build-Entscheidung.

Lokal bauen und bereitstellen

hugo --minify
hugo server

Prüfe public/ nach dem ersten Befehl. Nutze den lokalen Server, um Inhalte und Theme-Rendering zu prüfen; hugo server ist nicht der Produktions-Startbefehl.

Stelle nach dem CLI-Setup das Quellverzeichnis bereit:

lizard init --name hugo-site
lizard add --service web
lizard up --service web --port 80
lizard logs --build --service web --json
lizard ps --json

Wenn du den generierten Hostnamen verwendest, lies ihn nach dem ersten Bereitstellen aus:

lizard service show web --json

Setze baseURL in hugo.toml auf diesen Hostnamen:

baseURL = "https://YOUR_PUBLIC_HOST/"

Lade die geänderte Konfiguration hoch, damit der Build die öffentliche URL verwendet:

lizard up --service web --port 80

Schließe lokal generierten Output und Secrets aus. Stelle bei einem Upload sicher, dass die Theme-Quelldateien tatsächlich in dem Verzeichnis vorhanden sind, das du sendest; ein entfernter Submodule-Verweis allein ist nicht der Theme-Inhalt.

Die bereitgestellte Website prüfen

Öffne die Live-Startseite, einen internen Artikel und ein Bild. Prüfe die generierten kanonischen URLs und sitemap.xml. Teste den HTTP-Status eines erfundenen Pfads. Neue Hugo-Builds liefern das generierte HTML aus und geben für fehlende Seiten HTTP 404 zurück. Für das einfache Quelllayout in dieser Anleitung ist kein eigenes Dockerfile erforderlich. Baue ältere Images neu, um die aktuellen Routing-Regeln zu übernehmen.

Verwende statische Routen und 404er, wenn du eine benutzerdefinierte nginx-Richtlinie benötigst. Eine benutzerdefinierte Hugo-Build-Stage muss die vom Theme benötigte Hugo-Version und Tools enthalten, hugo --minify ausführen und public/ in das ausliefernde Image kopieren.

Wenn Theme-Assets fehlen, prüfe die Build-Logs, die Theme-Quelle und baseURL. Wenn der falsche Builder startet, prüfe, ob die Hugo-Konfiguration und content/ im Upload-Root liegen, und überprüfe vorhandene Service-Overrides. Hugo erzeugt statische Dateien, daher erfordern Inhaltsänderungen einen neuen Build.

Siehe getestete Versionen und Cloud-Ergebnisse für die Bereitstellen-Prüfungen vom 9. September 2026 und ihre Grenzen.