# Развертывание Hugo на Lizard Lizard может собрать исходный сайт Hugo с помощью `hugo --minify` и обслуживать `public/` через nginx на порту `80`. Начните с исходной директории Hugo, с конфигурацией Hugo и `content/`, а не только загружая сгенерированный HTML. Начните с [полного примера исходного кода](https://github.com/lizard-build/docs/tree/main/_examples/hugo), который включает конфигурацию и файлы, используемые в этом рецепте. ## Подготовка исходного кода Включите вашу конфигурацию Hugo, контент, макеты, ресурсы и все файлы темы, необходимые для сборки. Детектор Hugo ищет конфигурацию, такую как `hugo.toml`, `hugo.yaml` или `config/_default/`, а также директорию `content/`. | Настройка | Значение | |---|---| | Сборка | `hugo --minify` | | Вывод | `public/` | | Продакшн-сервер | nginx | | Порт сервиса | `80` | Установите `baseURL` в предполагаемый публичный URL сайта, включая завершающий слеш. Пересоберите после назначения другого хостнейма, чтобы ссылки и сгенерированные записи карты сайта использовали его. Ознакомьтесь с [руководством Hugo по сборке и выводу](https://gohugo.io/getting-started/usage/). ## Проверка зависимостей сборки Образ сборки Hugo по умолчанию — `hugomods/hugo:base`; он не закрепляет версию Hugo для вашего проекта. Если теме требуется конкретная версия Hugo, расширенное издание или инструменты Node, используйте полный Dockerfile с этими зависимостями и версией, которую вы тестировали. Конфигурация Hugo и `content/` выбирают сборщик Hugo до определения Go или Node. Проекты Hugo Modules с `go.mod` используют образ сборки с поддержкой Go. Наличие `package.json` останавливает сборку с просьбой предоставить Dockerfile: установите зависимости Node, соберите ресурсы, затем запустите `hugo --minify`. См. [порядок принятия решения о сборке](https://lizard.build/ru/docs/concepts/build-pipeline#build-decision-order). ## Локальная сборка и развертывание ```bash hugo --minify hugo server ``` Ознакомьтесь с `public/` после первой команды. Используйте локальный сервер для проверки контента и рендеринга темы; `hugo server` — это не продакшн-команда запуска. После [настройки CLI](https://lizard.build/ru/docs/framework-guides#prepare-the-project) разверните исходную директорию: ```bash lizard init --name hugo-site lizard add --service web lizard up --service web --port 80 lizard logs --build --service web --json lizard ps --json ``` Если вы используете сгенерированный хостнейм, прочитайте его после первого развертывания: ```bash lizard service show web --json ``` Установите `baseURL` в `hugo.toml` на этот хостнейм: ```toml baseURL = "https://YOUR_PUBLIC_HOST/" ``` Загрузите изменённую конфигурацию, чтобы сборка использовала публичный URL: ```bash lizard up --service web --port 80 ``` Исключите локальный сгенерированный вывод и секреты. При загрузке убедитесь, что исходные файлы темы действительно существуют в отправляемой директории; удалённая ссылка на подмодуль сама по себе не является контентом темы. ## Проверка развернутого сайта Откройте домашнюю страницу, внутреннюю статью и изображение. Проверьте сгенерированные канонические URL и `sitemap.xml`. Протестируйте HTTP-статус вымышленного пути. Новые сборки Hugo обслуживают сгенерированный HTML и возвращают HTTP 404 для отсутствующих страниц. Для простой структуры исходников из этого руководства не нужен собственный Dockerfile. Пересоберите старые образы, чтобы получить актуальные правила маршрутизации. Используйте [статические маршруты и 404](https://lizard.build/ru/docs/framework-guides/static-routing), если вам нужна собственная политика nginx. Пользовательская стадия сборки Hugo должна включать требуемую темой версию Hugo и инструменты, запустить `hugo --minify` и скопировать `public/` в образ обслуживания. Если ресурсы темы отсутствуют, изучите логи сборки, исходники темы и `baseURL`. Если запускается не тот сборщик, проверьте, что конфигурация Hugo и `content/` находятся в корне загрузки, и изучите существующие переопределения сервиса. Hugo производит статические файлы, поэтому изменения контента требуют новой сборки. См. [проверенные версии и результаты в облаке](https://lizard.build/ru/docs/framework-guides/validation) для проверок развёртывания от 9 сентября 2026 года и их ограничений.