Wybór technologii do bloga, strony firmowej w 2026

23-08-2026Web DevelopmentAstro, Cloudflare Workers, AI Agents

Warstwy Markdown, Astro, Workers i OpenTofu wdrażane na globalny edge

W skrócie: Astro + Cloudflare.

W 2026 roku blog nie potrzebuje rozbudowanego CMS-a, serwera aplikacyjnego i bazy danych. Jeżeli zależy nam na szybkości, prostocie, niskich kosztach oraz dobrej współpracy z agentami AI, warto rozważyć Astro, Cloudflare Workers i treści przechowywane bezpośrednio w Git.

Astro jako podstawa — historia zatacza koło

Astro dobrze pasuje do stron, na których większość treści jest statyczna: blogów, stron firmowych, ofert i landing pages. Domyślnym wynikiem buildu Astro jest statyczna strona: gotowe pliki HTML, CSS, JavaScript, obrazy i inne assets, które można umieścić bezpośrednio na edge. Zamiast wykonywać aplikację przy każdym wejściu użytkownika, większość pracy wykonujemy raz podczas astro build.

Praca z takim stosem przypomina mi początki tworzenia stron WWW sprzed około 20 lat. Zaczynałem od prostego HTML, później dochodziły CSS, JavaScript, PHP, Python i w końcu generyczne CMS-y oraz coraz większe frameworki. Każda kolejna warstwa rozwiązywała konkretne problemy, ale jednocześnie zwiększała złożoność.

Dzięki agentom AI historia częściowo zatacza koło. Możemy wrócić do korzeni — prostych dokumentów, semantycznego HTML i plików — nie rezygnując z automatyzacji, komponentów, SEO czy szybkiego deploymentu. Agent może przejąć dużą część pracy, dla której wcześniej potrzebowaliśmy rozbudowanego panelu administracyjnego i wielu abstrakcji.

Najprostszy podział to:

Markdown (.md) – artykuły i proste treści,
MDX (.mdx) – treści wymagające komponentów,
Astro (.astro) – strony ofertowe, landing pages i bardziej dynamiczne widoki.

Nie warto używać bardziej złożonego formatu, jeśli prostszy wystarcza.

Powrót do semantycznego HTML

Idąc tym torem, można ograniczyć także ilość technicznego szumu w samym HTML. Element nie musi mieć kilku czy kilkunastu klas tylko po to, aby wyglądał jak nagłówek, formularz, przycisk albo sekcja.

Dobrym przykładem jest Pico CSS, którego filozofia opiera się na semantic HTML i stylowaniu natywnych elementów. Pico oferuje nawet class-less CSS, gdzie zwykłe <header>, <main>, <section>, <form> czy <button> otrzymują sensowne style bez dokładania klas do każdego elementu. Autorzy Pico opisują tę ideę jako powrót do prostoty HTML i ograniczenie zbędnych wrapperów oraz klas.

<main>
  <article>
    <h1>Wybór technologii do bloga</h1>
    <p>Treść strony.</p>
    <button>Czytaj dalej</button>
  </article>
</main>

Taki kod jest czytelniejszy zarówno dla człowieka, jak i dla agenta AI. Mniej klas, wrapperów i boilerplate’u to również mniej tokenów potrzebnych do zrozumienia i modyfikacji strony. Nie chodzi o całkowitą rezygnację z klas — przy bardziej złożonym UI nadal są potrzebne — lecz o zasadę: najpierw semantyczny HTML, dodatkowa abstrakcja dopiero wtedy, gdy rzeczywiście daje wartość.

Markdown jest dobry również dla AI

Markdown ma jeszcze jedną zaletę: jest oszczędny tekstowo. W porównaniu z rozbudowanym HTML-em lub strukturami generowanymi przez page buildery zawiera mniej powtarzalnego kodu i mniej elementów, które agent AI musi analizować.

To może oznaczać:

mniejsze zużycie tokenów,
szybszą pracę agentów,
prostsze modyfikacje,
czytelniejsze diffy w Git,
łatwiejsze automatyczne generowanie i aktualizowanie treści.

Warto przy tym stosować DRY. Nagłówki, CTA, dane firmy, sekcje ofertowe czy elementy SEO powinny być komponentami lub wspólnymi danymi, zamiast być kopiowane do dziesiątek plików.

MD, MDX czy Astro? Ten sam case: strona „Oferta”

Najprostsza zasada:

MD — treść jest przede wszystkim tekstem,
MDX — tekst potrzebuje pojedynczych komponentów,
Astro — strona ma własny układ, logikę lub więcej elementów interfejsu.

Markdown: prosta oferta

---
title: "Audyt infrastruktury"
description: "Audyt infrastruktury i rekomendacje zmian."
---

# Audyt infrastruktury

Sprawdzamy architekturę, bezpieczeństwo i koszty.

## Zakres

- infrastruktura,
- bezpieczeństwo,
- koszty,
- rekomendacje.

[Skontaktuj się](/kontakt/)

To dobry wybór, gdy oferta jest głównie treścią. Mało składni oznacza też mało tokenów podczas pracy z agentami AI.

MDX: oferta z komponentem

---
title: "Audyt infrastruktury"
---

import Price from "../components/Price.astro";

# Audyt infrastruktury

Analiza infrastruktury, bezpieczeństwa i kosztów.

<Price from="2500 PLN" />

[Zapytaj o audyt](/kontakt/)

MDX ma sens, gdy większość strony nadal jest treścią, ale potrzebujemy np. cennika, galerii albo CTA jako komponentu.

Astro: dedykowany landing page

---
import Layout from "../layouts/Layout.astro";
import ContactForm from "../components/ContactForm.astro";

const title = "Audyt infrastruktury";
---

<Layout title={title}>
  <main>
    <h1>{title}</h1>
    <p>Analiza infrastruktury, bezpieczeństwa i kosztów.</p>

    <section>
      <h2>Zakres</h2>
      <ul>
        <li>Infrastruktura</li>
        <li>Bezpieczeństwo</li>
        <li>Koszty</li>
      </ul>
    </section>

    <ContactForm />
  </main>
</Layout>

.astro sprawdza się dla strony ofertowej lub landing page’a, gdy struktura strony jest ważniejsza niż sam tekst.

Najprostszy format, który spełnia wymagania, jest zwykle najlepszy.

Cloudflare Workers zamiast klasycznego hostingu

Gotową stronę Astro można uruchomić na Cloudflare. Dla statycznych zasobów narzut CPU może być mały — w dobrze zoptymalizowanym przypadku obsługa requestu może zajmować około ułamka milisekundy CPU. Konkretna wartość zależy jednak od konfiguracji, cache i wykonywanej logiki.

Najważniejsza jest architektura: większość pracy wykonujemy podczas builda, a nie przy każdym wejściu użytkownika.

Cloudflare daje przy tym w jednym miejscu m.in.:

CDN i cache,
DNS,
HTTPS,
redirects,
możliwość ukrycia origin IP za proxy,
Workers dla logiki wykonywanej na edge.

Jest to szczególnie wygodne przy homelabie. Publiczna strona może być dostarczana z edge, a infrastruktura domowa nie musi być bezpośrednio eksponowana tam, gdzie nie jest to potrzebne.

Infrastructure as Code przez OpenTofu

Konfigurację Cloudflare warto trzymać jako kod za pomocą OpenTofu.

DNS, redirects, reguły czy część konfiguracji Workers można wtedy odtworzyć i zmieniać podobnie jak kod aplikacji.

Daje to prosty workflow:

Markdown/Astro → Git → build → Cloudflare

Agent AI może pracować zarówno nad treścią, jak i kodem oraz konfiguracją infrastruktury. Zmiany pozostają widoczne w Git i można je łatwo przejrzeć przed wdrożeniem.

GitLab: repozytorium i state

Jeżeli nad projektem pracuje kilka osób, GitLab może pełnić dwie role:

repozytorium strony,
backend dla współdzielonego state OpenTofu.

Dzięki temu kod strony i infrastruktury mogą przechodzić przez ten sam proces review i deploymentu.

Przy jednoosobowym, małym projekcie można zacząć jeszcze prościej: repozytorium Git oraz lokalny state OpenTofu. Trzeba tylko pamiętać o jego backupie i nie publikować state zawierającego dane wrażliwe.

GitLab jako backend state OpenTofu

Przy pracy zespołowej state można trzymać zdalnie w GitLabie przez backend HTTP. Lokalny .terraform/terraform.tfstate zawiera konfigurację backendu, a właściwy state znajduje się po stronie zdalnej.

Po tofu init lokalny plik może zawierać m.in.:

{
  "version": 3,
  "backend": {
    "type": "http",
    "config": {
      "address": "https://gitlab.com/api/v4/projects/project/terraform/state/cloudflare",
      "lock_address": "https://gitlab.com/api/v4/projects/project/terraform/state/cloudflare/lock",
      "unlock_address": "https://gitlab.com/api/v4/projects/project/terraform/state/cloudflare/lock",
      "username": "user"
    }
  }
}

.terraform/ jest katalogiem roboczym i nie powinien trafiać do Git. Credentials lepiej przekazywać przez zmienne środowiskowe. Przy pracy jednoosobowej można zacząć od lokalnego state i backupu. Remote state daje większą wartość przy pracy zespołowej i CI/CD.

SEO, GEO i agenci AI

Przy takim stacku agent AI pracuje na prostych plikach tekstowych zamiast na danych ukrytych w panelu CMS. Może szybko analizować i poprawiać:

title i description,
strukturę nagłówków,
linkowanie wewnętrzne,
dane strukturalne,
canonical URLs,
sitemapę,
treść pod klasyczne SEO,
strukturę i jednoznaczność informacji przydatną dla wyszukiwarek oraz systemów generatywnych (GEO).

Nie oznacza to automatycznie dobrego SEO lub GEO. Przewagą jest to, że cała strona ma przewidywalną strukturę, którą łatwo analizować, testować i zmieniać automatycznie.

Szybki deployment

Brak klasycznej bazy danych i panelu CMS upraszcza deployment.

Zmiana artykułu może wyglądać tak:

edycja pliku .md,
commit,
build,
deployment do Cloudflare.

Przy małych zmianach agent może przygotować gotowy commit obejmujący treść, metadata, linkowanie i wymagane zmiany w kodzie.

Koszt

Dla małego bloga koszt infrastruktury pozostaje bliski zeru. W praktyce podstawowym kosztem może pozostać domena oraz używane narzędzia AI.

Cloudflare ma limity i płatne plany zależne od wykorzystania, dlatego nie należy zakładać, że każda konfiguracja będzie zawsze bezpłatna. Przy statycznym blogu i dobrym cache wymagania są jednak niewielkie.

Koszt AI również można ograniczyć przez architekturę:

Markdown zamiast rozbudowanego HTML,
DRY zamiast kopiowania treści,
małe, precyzyjne pliki,
wspólne komponenty,
przekazywanie agentowi tylko potrzebnego kontekstu.

Mniej kodu i mniej powtórzeń oznacza mniej rzeczy do utrzymania, mniej tokenów do przetworzenia i mniej miejsc, w których może pojawić się błąd.

Podsumowanie

Astro + Markdown + Cloudflare + OpenTofu to ciekawy stack dla bloga w 2026 roku, ponieważ przenosi ciężar z utrzymywania CMS-a i serwera na prosty kod, statyczne treści, cache oraz automatyzację.

Nie jest to rozwiązanie dla każdego projektu. Jeśli redaktorzy potrzebują rozbudowanego panelu CMS, workflow akceptacji lub intensywnie dynamicznych funkcji, dodatkowa warstwa może być uzasadniona.

Dla bloga prowadzonego przez developera lub mały zespół prostota jest jednak dużą przewagą: treść jest kodem, infrastruktura jest kodem, a AI może pracować bezpośrednio na obu.