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, mit der Standard-Fehlerseite von nginx statt deines 404.html-Layouts. 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 oder eine eigene 404-Seite 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.

Aktualisiert