Hugo на Ubuntu 24.04: пошаговая установка

MAATRIX

Если сайт — это блог, документация или лендинг без личного кабинета и форм с логикой на сервере, держать под него WordPress с базой данных и PHP-FPM избыточно: лишние процессы, лишние точки отказа, лишний повод для взлома через устаревший плагин. Hugo решает это иначе — генерирует чистый HTML заранее, а сервер только раздаёт готовые файлы. Ниже — как поставить Hugo на Ubuntu 24.04 без граблей, собрать первый сайт и подключить его к Nginx с автообновлением по git push.

Почему Hugo, а не Jekyll или WordPress

Hugo написан на Go и компилируется в один бинарник без зависимостей — не нужен ни Ruby (как для Jekyll), ни Node.js (как для большинства JS-генераторов), ни PHP с MySQL. Сборка сайта — это разбор Markdown-файлов и рендер шаблонов в HTML, и делает это Hugo заметно быстрее конкурентов на схожем железе: для сайта из нескольких сотен страниц пересборка обычно укладывается в единицы секунд, а не в минуты, но точные цифры сильно зависят от тем, шаблонов и объёма контента — не ориентируйтесь на чужие бенчмарки, проверяйте на своём проекте.

Из этого вытекает практический плюс для сервера: готовый сайт — это просто папка со статикой. Её может раздавать Nginx на минимальном VPS без базы данных, PHP-воркеров и очередей на обновления безопасности движка. Требования к ресурсам падают на порядок по сравнению с тем же WordPress, а поверхность атаки резко сужается — взломать нечего, кроме самого веб-сервера.

Минус тоже есть, и его стоит проговорить честно: всё динамическое (комментарии, формы, поиск по контенту, личный кабинет) на Hugo нужно прикручивать внешними сервисами или JS-виджетами — сам генератор для этого не предназначен.

Подготовка сервера Ubuntu 24.04

Дальше всё выполняется на чистом VPS с Ubuntu 24.04 LTS. Подключаемся по SSH и обновляем систему:

sudo apt update && sudo apt upgrade -y
sudo apt install -y wget git tar

Если вы ещё не настроили доступ по SSH-ключу и базовый файрвол — сделайте это до того, как выставите сайт наружу, это отдельная тема, разобранная в статье про подключение по SSH-ключу на Ubuntu 24.04. Заодно откройте нужные порты в ufw:

sudo ufw allow OpenSSH
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable

Ресурсы под сам Hugo нужны скромные: 1 vCPU и 1 ГБ RAM с запасом хватает даже на сборку сайта в несколько тысяч страниц, а раздача готовой статики через Nginx почти не нагружает процессор — под это разумно взять младший тариф VPS, а не переплачивать за мощности, которые статике не пригодятся.

Установка Hugo: правильный способ

Здесь есть грабля, о которую спотыкается большинство новичков. В репозиториях Ubuntu 24.04 лежит Hugo через apt, но версия там почти всегда заметно отстаёт от актуальной, а snap-пакет хоть и свежее, тянет за собой демон snapd и работает медленнее из-за confinement. Плюс обеим формам часто не хватает Sass/SCSS-транспилятора, который требуют многие темы — так называемая «extended»-сборка.

Правильный путь — скачать актуальный .deb-пакет extended-версии прямо со страницы релизов на GitHub:

cd /tmp
wget https://github.com/gohugoio/hugo/releases/download/v0.140.0/hugo_extended_0.140.0_linux-amd64.deb
sudo dpkg -i hugo_extended_0.140.0_linux-amd64.deb

Номер версии в ссылке нужно свериться с актуальным релизом на странице github.com/gohugoio/hugo/releases на момент установки — конкретная версия здесь для примера, не вставляйте её вслепую. Проверяем, что всё встало и это именно extended-сборка:

hugo version

В выводе должна быть пометка extended — без неё темы с встроенной обработкой Sass/SCSS не соберутся, и вы получите непонятную ошибку про отсутствующий transpiler уже на этапе сборки сайта.

Альтернатива без прав root — просто распаковать бинарник в $HOME/bin и добавить его в PATH:

mkdir -p ~/bin
tar -xzf hugo_extended_0.140.0_linux-amd64.tar.gz -C ~/bin hugo
echo 'export PATH=$HOME/bin:$PATH' >> ~/.bashrc
source ~/.bashrc

Создание сайта и структура проекта

Создаём новый проект и сразу инициализируем git — он пригодится и для темы, и для деплоя дальше:

hugo new site mysite
cd mysite
git init

Структура каталогов получается такая:

mysite/
├── archetypes/   # шаблоны для новых страниц
├── content/      # весь контент в Markdown
├── layouts/      # HTML-шаблоны (переопределяют тему)
├── static/       # картинки, шрифты, файлы как есть
├── themes/       # темы оформления
├── hugo.toml     # главный конфиг
└── public/       # сюда попадёт итоговая сборка (появится после build)

Ставим тему — большинство современных тем ставится как git submodule, это удобно для обновлений:

git submodule add https://github.com/adityatelange/hugo-PaperMod.git themes/PaperMod

Дальше открываем hugo.toml и указываем базовые параметры:

baseURL = 'https://example.com/'
languageCode = 'ru-ru'
title = 'Мой сайт на Hugo'
theme = 'PaperMod'

[params]
  defaultTheme = 'auto'
  ShowReadingTime = true
  ShowShareButtons = false

baseURL замените на реальный домен — от него зависят абсолютные ссылки в готовой сборке. Если домен ещё не привязан к серверу, сначала разберитесь с этим — есть отдельная статья про настройку домена и DNS на Ubuntu 24.04.

Первый локальный запуск и добавление контента

Создаём первую страницу через архетип:

hugo new content posts/pervyj-post.md

По умолчанию новые страницы помечаются как черновики (draft: true в front matter) — уберите эту строку или замените на false, когда контент готов к публикации, иначе Hugo не включит страницу в финальную сборку.

Запускаем встроенный dev-сервер с live reload:

hugo server -D

По умолчанию сервер слушает 127.0.0.1:1313 — на локальной машине этого достаточно. Если вы работаете прямо на VPS и хотите посмотреть черновик из браузера, не открывайте порт 1313 наружу через файрвол — это лишняя дыра ради удобства. Правильнее пробросить порт через SSH-туннель:

ssh -L 1313:127.0.0.1:1313 user@your-server-ip

и открыть http://127.0.0.1:1313 у себя в браузере — трафик пойдёт через зашифрованный туннель, а порт на сервере наружу светить не придётся.

Сборка и публикация через Nginx с HTTPS

Когда контент готов, собираем статику:

hugo --minify

Команда положит готовый сайт в public/ — HTML, CSS и JS уже минифицированы. Эту папку и нужно скормить веб-серверу. Переносим на боевой путь и настраиваем Nginx:

sudo mkdir -p /var/www/mysite
sudo cp -r public/* /var/www/mysite/
sudo chown -R www-data:www-data /var/www/mysite

Конфиг Nginx для статики простой:

server {
    listen 80;
    server_name example.com www.example.com;
    root /var/www/mysite;
    index index.html;

    location / {
        try_files $uri $uri/ =404;
    }

    location = /404.html {
        internal;
    }
}

sudo ln -s /etc/nginx/sites-available/mysite /etc/nginx/sites-enabled/
sudo nginx -t && sudo systemctl reload nginx

Подробный разбор настройки Nginx как есть — со всеми флагами и типичными опечатками в конфиге — в статье про установку статического сайта на VPS. Для HTTPS проще всего Certbot:

sudo apt install -y certbot python3-certbot-nginx
sudo certbot --nginx -d example.com -d www.example.com

Если вместо Nginx вам ближе Caddy с автоматическим SSL «из коробки» без отдельного шага с Certbot — это тоже рабочий вариант, разобранный в статье про Caddy с авто-SSL на Ubuntu 24.04.

Автообновление сайта при git push

Копировать public/ руками после каждой правки быстро надоедает. Рабочая схема без внешних CI — bare-репозиторий на сервере с post-receive хуком, который сам собирает и выкладывает сайт при пуше.

На сервере:

sudo mkdir -p /var/repo/mysite.git
cd /var/repo/mysite.git
sudo git init --bare

Создаём хук /var/repo/mysite.git/hooks/post-receive:

#!/bin/bash
WORKDIR=/tmp/mysite-deploy
TARGET=/var/www/mysite

rm -rf $WORKDIR
git clone /var/repo/mysite.git $WORKDIR
cd $WORKDIR
git submodule update --init --recursive
hugo --minify

rsync -a --delete public/ $TARGET/
echo "Сайт обновлён: $(date)"

sudo chmod +x /var/repo/mysite.git/hooks/post-receive
sudo chown -R $(whoami):$(whoami) /var/repo/mysite.git

У себя на машине добавляем сервер как remote и пушим:

git remote add prod ssh://user@your-server-ip/var/repo/mysite.git
git push prod main

Каждый пуш в main теперь сам разворачивает свежую версию сайта на сервере — без ручного копирования и без сторонних сервисов CI. Если проект растёт и хочется полноценный pipeline с тестами перед деплоем, посмотрите в сторону self-hosted Gitea Actions или Drone — но для блога на Hugo такой хук обычно избыточности не требует.

Частые вопросы