Jak zbudowałem ten blog?

Kiedy postanowiłem odpalić własnego bloga, stanąłem przed klasycznym dylematem: WordPress, Ghost, Hugo, a może coś własnego? Wybrałem stworzenie własnego rozwiązania, które finalnie generuje statyczną stronę HTML. Dlaczego? Bo wyznaje zasadę: im prościej coś jest zrobione, tym łatwiej mi to utrzymać.

TL;DR

Dlaczego statyczne strony?

Prostota przede wszystkim. Statyczne strony to:

1. Zero backendu - nie ma co się zepsuć
2. Błyskawiczne ładowanie - serwer wysyła gotowy HTML
3. Tani hosting - wystarczy nginx serwujący pliki

W odcinku Patoarchitektów #155 o "biedahostingu" padł cytat, który dobrze podsumowuje moje podejście:

Są w życiu rzeczy, które warto i są takie, które się opłaca. Nie zawsze to co warto się opłaca, nie zawsze to co się opłaca warto.

Jak to działa?

Używam paczki StaticContentGeneratorBundle autorstwa Norberta Orzechowicza. Realne przykłady wykorzystania znajdziesz w repo norbert.tech (strona autora) oraz na przykładzie dokumentacji Flow PHP.

Działa to tak:

1. Piszę kod jak normalną aplikację Symfony - kontrolery, Twig, routing
2. Odpalamy build - bundle przechodzi po wszystkich routach i zapisuje wyrenderowany HTML
3. Output to folder ze statycznymi plikami - gotowy do wrzucenia na dowolny serwer

# Cały proces budowania
composer build

Pod spodem dzieje się magia:

# Czyścimy cache
APP_ENV=prod bin/console cache:clear

# Budujemy assety (Tailwind, JS)
APP_ENV=prod bin/console tailwind:build --minify
APP_ENV=prod bin/console asset-map:compile

# Generujemy statyczne HTML
APP_ENV=prod bin/console static-content-generator:generate:routes

# Sitemap dla SEO
APP_ENV=prod bin/console presta:sitemaps:dump

# Kopiujemy assety do outputu
APP_ENV=prod bin/console static-content-generator:copy:assets

Struktura contentu

Artykuły trzymam jako pliki Markdown z frontmatterem:

content/
├── static-site-symfony/
│   ├── pl.md          # Polska wersja
│   └── en.md          # Angielska wersja
└── helm-vs-kustomize/
    ├── pl.md
    └── en.md

Każdy artykuł to zwykły Markdown z YAML-owym nagłówkiem. Przetwarzam go przez league/commonmark z dodatkami jak GFM, tabele czy automatyczne anchory do nagłówków.

Hosting i deploy

Całość hostuję na Mikrusie - polskim VPS za grosze. Sam korzystam z Mikrus 3.5 (4 GB RAM, 40 GB dysku), bo oprócz bloga trzymam tam kilka innych aplikacji i stronę firmową.

Do samego bloga wystarczy znacznie mniej - Mikrus 1.0 albo nawet darmowy Frog spokojnie obsłuży statyczne pliki.

Szukasz taniego VPS-a pod własne projekty? Polecam - link z refem.

Deploy? Push do main odpala GitHub Actions, który buduje stronę i rsync'uje na serwer:

name: Deploy

on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Build static site
        run: composer build

      - name: Deploy to server
        run: rsync -avz output/ user@server:/var/www/blog/

Migracja? 30 minut

To jest moja ulubiona część. Chcę przenieść bloga na inny serwer? Oto cały proces:

1. Postawić nginx na nowym serwerze (~5 min)
2. Wygenerować klucze SSH i zmienić sekrety w GitHub Actions (~5 min)
3. Uruchomić akcję deployującą na nowy serwer (~1 min)
4. Przepiąć DNS (~20 min na propagację)

Nie ma bazy do migracji. Nie ma środowiska PHP do konfiguracji. Nie ma zależności od konkretnego hostingu.

Gdybym używał WordPressa, migracja to: eksport bazy, import bazy, konfiguracja wp-config, testowanie czy wszystko działa, modlenie się żeby pluginy nie zrobiły problemów...

Dlaczego Symfony, a nie Hugo/Jekyll?

Mógłbym użyć dedykowanego generatora statycznych stron. Ale:

1. Znam Symfony - nie muszę się uczyć nowego toola
2. Pełna kontrola - mogę dodać dowolną logikę w PHP
3. Reużywalność - te same komponenty co w komercyjnych projektach
4. Twig - potężny system szablonów, który znam na pamięć

Wady?

Żeby być fair:

• Brak komentarzy out-of-the-box - musiałbym dodać Disqus lub coś podobnego
• Brak CMS-a - piszę w Markdownie w edytorze kodu

Dla mnie te kompromisy są akceptowalne. Wolę pisać w IDE niż utrzymywać WordPressa.

Podsumowanie

Nudne rozwiązania to inwestycja w spokój. Statyczny HTML może nie jest sexy, ale w perspektywie miesięcy i lat zwraca się z nawiązką – działa stabilnie, utrzymuje się sam, przeniosę go gdziekolwiek w 30 minut.

Jeśli budujesz bloga i znasz PHP - rozważ to podejście. Nie potrzebujesz Kubernetesa, bazy danych ani skomplikowanej infrastruktury. Czasem nginx serwujący pliki HTML to wszystko, czego potrzebujesz.

Masz pytania? Napisz na LinkedIn.