Налаштування пайплайнів для статики: Hugo, Jekyll, Next.js

Статичні сайти на Hugo, Jekyll чи Next.js потребують надійного CI/CD, інакше користувачі бачать застарілий контент через кеш CDN, а збірка займає забагато часу. Ми налаштовуємо пайплайни під ключ: від конфігурації деплою до інвалідації CloudFront, з урахуванням особливостей генераторів. Наша команда бере на себе весь цикл — від аудиту до підтримки, щоб сайт оновлювався швидко та без збоїв.
Часті запитання

Налаштування пайплайнів для статики: Hugo, Jekyll, Next.js

Після деплою статичного сайту в S3 користувачі отримують 404 на Next.js маршрутах, а кеш CloudFront показує застарілий контент. Це типові наслідки невірної конфігурації CI/CD: відсутність інвалідації, неправильні Cache-Control, невраховані особливості генераторів. За роки налаштування пайплайнів для Hugo, Jekyll та Next.js Export ми виробили схеми, які гарантовано працюють: без сюрпризів з кешем, з автодеплоєм та preview-оточеннями. Один клієнт скоротив витрати на CloudFront на 35% після впровадження нашої схеми кешування — економія близько $200 на місяць. Середній час збірки Hugo на 2000 сторінок — 5 секунд, Jekyll без кешу — 3 хвилини, з кешем — 5 секунд. Наша компанія має 5 років досвіду в CI/CD для статики, реалізовано понад 50 проектів. Нижче — як ми це робимо і що входить в роботу.

Проблеми CI/CD для статики

Інвалідація CDN-кешу. Ви залили новий файл в S3, а користувачі бачать стару версію. Без create-invalidation CloudFront кешує HTML на години. Ми використовуємо двопрохідний s3 sync з різними Cache-Control: для статики — max-age=31536000, для HTML — no-cache. Це скорочує кількість інвалідацій та витрати.

Next.js Export без конфігурації. next export не підтримує getServerSideProps, API routes та Image Optimization. Якщо у вас є динамічні маршрути, потрібно або переходити на ISR, або налаштовувати output: 'export' з trailingSlash: true та unoptimized: true. Інакше збірка впаде.

Повільна збірка Jekyll. Без кешу bundle install тягне геми 2–3 хвилини. Вмикаємо bundler-cache: true — час падає до 5 секунд. Це типова помилка новачків.

Як ми проектуємо пайплайн

Для кожного проекту — свій конфіг, але загальний шаблон:

  • Збірка: фіксована версія генератора (Hugo extended, Ruby 3, Node 20).
  • Оптимізація: мініфікація, стиснення, tree-shaking, content hash в іменах.
  • Деплой: atomic deploy через S3 або пряме завантаження на Cloudflare Pages / Netlify.
  • Інвалідація: CloudFront, або автоматична на Netlify/Cloudflare.
  • Preview: для PR — тимчасова URL.

Кейс: Hugo + S3 + CloudFront. Hugo extended збирає сторінки в 5 разів швидше, ніж Jekyll без кешу. Використовуємо peaceiris/actions-hugo з extended режимом для SCSS. Збірка — 5 секунд на 2000 сторінок. Деплой двома aws s3 sync — для статики та HTML окремо. Після — інвалідація кореня (/*). Для preview — окремий префікс s3://bucket/previews/PR-42/.

---
- uses: peaceiris/actions-hugo@v3
  with:
    hugo-version: '0.124.0'
    extended: true
- name: Build
  run: hugo --minify
- name: Deploy to S3
  run: |
    aws s3 sync public/ s3://my-bucket/ \
      --delete \
      --cache-control "public, max-age=31536000" \
      --exclude "*.html" \
      --exclude "*.xml"
    aws s3 sync public/ s3://my-bucket/ \
      --delete \
      --cache-control "no-cache" \
      --include "*.html" \
      --include "*.xml"
- name: Invalidate CloudFront
  run: |
    aws cloudfront create-invalidation \
      --distribution-id ${{ secrets.CLOUDFRONT_DISTRIBUTION_ID }} \
      --paths "/*"

Jekyll на GitHub Pages. Використовуємо офіційний workflow через actions/deploy-pages — не потрібно пушити в gh-pages гілку. Кешуємо геми.

---
- uses: ruby/setup-ruby@v1
  with:
    ruby-version: '3.3'
    bundler-cache: true
- name: Build Jekyll
  run: bundle exec jekyll build --destination _site
- name: Deploy to GitHub Pages
  uses: actions/deploy-pages@v4

Next.js Export на Cloudflare Pages. Cloudflare Pages автоматично розгортає npm ci && npm run build, але для експорту важлива конфігурація. Ми додаємо next.config.js з output: 'export' та відключаємо оптимізацію зображень.

module.exports = { output: 'export', trailingSlash: true, images: { unoptimized: true } } 
---
- uses: actions/setup-node@v4
  with:
    node-version: '20'
    cache: 'npm'
- run: npm ci
- run: npm run build
- name: Deploy to Cloudflare Pages
  uses: cloudflare/wrangler-action@v3
  with:
    apiToken: ${{ secrets.CLOUDFLARE_API_TOKEN }}
    command: pages deploy out/ --project-name=my-site

Як вибрати платформу для хостингу?

При виборі платформи враховуйте вартість, продуктивність та вбудовані функції. S3 + CloudFront дає повний контроль над кешем та CDN, але потребує ручного налаштування інвалідації та preview. Cloudflare Pages дешевший при великих обсягах (безкоштовно до 500 збірок на місяць — у 2 рази дешевше за Netlify) та надає preview з коробки. Netlify зручний для команд, але дорожчий. Для більшості проектів рекомендуємо Cloudflare Pages через баланс ціни та функціональності. Зв'яжіться з нами для вибору оптимальної платформи під ваш проект.

Платформа Інвалідація кешу Preview environments Ціна
S3 + CloudFront Ручна (API) Ручна конфігурація Плата за трафік + запити
Cloudflare Pages Автоматична Вбудована Безкоштовно до 500 збірок/міс
Netlify Автоматична Вбудована Безкоштовно до 300 збірок/міс

Чому важлива інвалідація CDN-кешу?

Без інвалідації користувачі побачать стару версію до закінчення TTL — від хвилин до діб. Ми використовуємо стратегію: статика (CSS/JS/images) — довгий кеш з content hash, HTML — без кешу. Це знижує навантаження на CDN та гарантує свіжість контенту. Згідно з документацією CloudFront, необхідно виконувати інвалідацію після кожного деплою. Правильна стратегія кешування дозволяє деяким клієнтам економити до $500 на місяць на витратах CDN.

Коли потрібні preview environments?

Зазначимо: коли в проекті кілька розробників. Preview дозволяє побачити зміни в ізоляції до вливання в main. Netlify та Cloudflare Pages дають це з коробки. Для S3+CloudFront ми створюємо префікси за номером PR.

---
- name: Deploy preview
  if: github.event_name == 'pull_request'
  run: |
    aws s3 sync public/ s3://my-bucket/previews/pr-${{ github.event.number }}/

Процес роботи

  1. Аналітика — розбираємо поточний пайплайн, репозиторій, хостинг.
  2. Проєктування — вибираємо стек: S3+CloudFront, Cloudflare Pages або Netlify.
  3. Реалізація — налаштовуємо CI/CD, кеші, preview.
  4. Тестування — перевіряємо збірку, деплой, інвалідацію.
  5. Деплой — вкочуємо на продакшен.

Що входить у роботу

  • Конфігурація CI/CD (GitHub Actions / GitLab CI)
  • Налаштування хостингу та CDN
  • Інтеграція preview environments
  • Документація по пайплайну
  • Навчання команди
  • Підтримка 1 місяць після запуску

Замовте налаштування пайплайну — і забудьте про проблеми з деплоєм.

Орієнтири за термінами

Завдання Термін
Hugo/Next.js → GitHub Pages / Netlify 0.5 дня
S3 + CloudFront + інвалідація кешу 1 день
Preview environments для PR +0.5 дня
Jekyll з кешем + custom domain 1 день

Ціни розраховуємо індивідуально після аналізу вашого проекту. Зв'яжіться з нами — оцінимо задачу за вашими вимогами. Отримайте консультацію з налаштування CI/CD: стабільний деплой, гарантована робота кешу та інтуїтивні preview. Наш досвід — безліч успішних проектів.

Наші компетенції:

Останні роботи

  • Розробка сайту компанії B2B ADVANCE
    Розробка сайту компанії B2B ADVANCE
    1542
  • Розробка веб-додатків для компанії FEEDME
    Розробка веб-додатків для компанії FEEDME
    1394
  • Розробка веб-сайту для компанії БЕЛФІНГРУП
    Розробка веб-сайту для компанії БЕЛФІНГРУП
    1081
  • Розробка інтернет магазину для компанії FURNORO
    Розробка інтернет магазину для компанії FURNORO
    1369
  • Розробка логотипу компанії B2B Advance
    Розробка логотипу компанії B2B Advance
    816
  • Розробка веб-додатків для компанії Enviok
    Розробка веб-додатків для компанії Enviok
    1142