06 / CMSHEADLESSGIT-BASED
HEADLESS CMS.GIT STORAGE.ZERO DATABASES.W MazCode content żyje w GitHub jako flat JSON — każda strona to plik, każda zmiana to commit, każda publikacja to git push triggering GitHub Actions deploy. Zero baz danych, zero serwera CMS, zero miesięcznych rachunków za SaaS. Visual admin panel z drag-and-drop slice'ów, content branches jako preview środowiska, AES-256-GCM szyfrowanie na granicy GitHub I/O. Nawet w publicznym repo content jest bezpieczny bez klucza.
[ porozmawiajmy ]→wróć do stacku50+ stron zarządzanych
~/mazcode/cms
LIVE
$ git commit -m "update content"
› Storage  github    (encrypted)
› Format   json      (flat-file)
› Version  git        ✓
› Admin    visual     ✓
$ content published in 1.2s
LIVE AUDIT•content management · git-powered

// overview
Git jako CMSWordPress wymaga MySQL, PHP runtime, serwera z dostępem FTP i regularnych aktualizacji — average WordPress install ma 12-20 aktywnych pluginów, z czego statystycznie 3-4 mają niezałatane CVE w danym momencie. Contentful kosztuje $489/miesiąc przy 20 tys. entries i osobnym środowisku staging — a każdy nowy locale dodaje kolejny tier. Strapi wymaga deploymentu backendu Node.js z własną bazą Postgres, osobnego utrzymania i własnego API layer między CMS a frontendem. Sanity, Prismic, DatoCMS — wszystkie dzielą ten sam problem: content żyje daleko od kodu, synchronizacja wymaga API round-tripu, a ceny rosną z każdym nowym edytorem lub środowiskiem.
Git-based CMS odwraca ten model fundamentalnie. W MazCode każda strona klienta to folder plików JSON w prywatnym GitHub repo. Każda zmiana treści — commit. Każda publikacja — git push, który triggeruje GitHub Actions workflow deploy na Vercel. Wersjonowanie jest natywne: pełna historia zmian, diff każdego akapitu, rollback to dowolna wersja w jednej komendzie. Content branches działają jak feature branches w kodzie — nowy branch, osobny preview URL, merge = publikacja.
Admin panel jest zbudowany wewnątrz samej aplikacji Next.js — nie jako zewnętrzny SaaS, lecz jako osobna route group `(admin)` z 22 podstronami. Edytor widzi drag-and-drop slice'ów, formularze inline, live preview w iframe. Nie wie, że zapisuje JSON do GitHub — widzi wizualny edytor z kolorowymi blokami. Ale to co ląduje w repo, to strukturalny JSON z pełnym typowaniem TypeScript po stronie renderowania. Brak API round-tripu między CMS a frontendem: content jest bundlowany statycznie na buildzie.
Szyfrowanie AES-256-GCM rozwiązuje problem, który uważano za nierozwiązywalny w git-based CMS: jak trzymać content w publicznym lub semi-publicznym repo bez ryzyka wycieku. Każdy plik content (`theme.json`, `site.json`, strony, formularze) jest szyfrowany jako plik `.mcz` z unikalnym 96-bitowym IV per plik. Klucz `CONTENT_ENCRYPTION_KEY` (hex 32B, AES-256) nigdy nie trafia do repozytorium — jest wstrzykiwany do GitHub Actions jako secret przez libsodium sealed box. Workflow deploy każdego site repo ma krok `Decrypt content` wywołujący `scripts/decrypt-content.mjs` przed buildem. Lokalnie i na Vercel runtime aplikacja operuje zawsze na plain JSON — szyfrowanie istnieje tylko na granicy GitHub I/O.
Architektura multi-site to jeden codebase obsługujący wiele klientów równolegle. `content/` jest symlinkiem do `content-sites/<aktywna-strona>/`. Każda strona ma osobne `site.json` (navbar, kontakt, social, footer, webhooks, locale) i `theme.json` (kolory, fonty, spacing, cienie, CTA style z 7 preset themes). Przełączanie między stronami: `npm run site exura-ortho`. W MazCode zarządzamy aktualnie 3 aktywnymi stronami z łącznie 100+ plikami content — jeden admin panel, jeden codebase, zero duplikacji kodu.
Biznesowo: brak miesięcznych opłat za CMS SaaS. Brak vendor lock-in — content to pliki JSON na GitHubie, nie w bazie danych zewnętrznego dostawcy. Backup = git clone. Migracja do innego buildera (jeśli kiedykolwiek) = przepisanie renderera, nie eksport z proprietary API. Dla klienta: edycja treści przez visual editor bez programisty, wersjonowanie bez IT, rollback przez CTO w 30 sekund. Typowy czas od kliknięcia "opublikuj" do pojawienia się zmian na stronie produkcyjnej: 90 sekund.
Kiedy ten model nie działa: content z relacjami many-to-many (sklep e-commerce z 50k produktów i tagami), real-time collaboration wielu edytorów jednocześnie (race conditions na gitcie), lub content wymagający zaawansowanego query language (filtrowanie, sortowanie, paginacja po stronie serwera). Dla tych przypadków rekomendujemy Sanity lub własną bazę Postgres.
quick facts
storagegithub
formatjson
versioninggit
pages50+

// key features
Dlaczego Headless CMS
01
Git VersioningKażda zmiana treści to commit w GitHub z autorem, datą i diff — pełna historia bez dodatkowego narzędzia. Rollback do dowolnej wersji: jedna komenda. Content branches jako izolowane preview środowiska.
∞history
02
Visual EditorAdmin panel z drag-and-drop 163 slice'ów, inline editing i live preview w iframe — redaktor edytuje treści bez wiedzy technicznej, a zapisywany output to strukturalny JSON z pełnym TypeScript typowaniem.
163slices
03
Multi-SiteJeden codebase Next.js obsługuje wiele stron klientów przez symlink `content/` i per-site `theme.json` — przełączanie kontekstu jedną komendą, zero duplikacji kodu, shared components dla wszystkich stron.
3+sites
04
AES-256 EncryptionContent szyfrowany AES-256-GCM z unikalnym IV per plik — pliki `.mcz` są nieczytelne bez `CONTENT_ENCRYPTION_KEY`, nawet w publicznym repo. Klucz wstrzykiwany przez libsodium sealed box jako GitHub Actions secret.
256-bitencryption

CHCESZ STRONĘ Z CMS?Git jako baza danych, JSON jako format, AES-256-GCM jako ochrona — bez miesięcznych opłat SaaS, bez vendor lock-in, bez serwera CMS do utrzymania. Od edycji treści do wersji live: 90 sekund.
[ zamów projekt ]→zobacz cennikedycja treści w < 1 min

Git jako CMS

WordPress wymaga MySQL, PHP runtime, serwera z dostępem FTP i regularnych aktualizacji — average WordPress install ma 12-20 aktywnych pluginów, z czego statystycznie 3-4 mają niezałatane CVE w danym momencie. Contentful kosztuje $489/miesiąc przy 20 tys. entries i osobnym środowisku staging — a każdy nowy locale dodaje kolejny tier. Strapi wymaga deploymentu backendu Node.js z własną bazą Postgres, osobnego utrzymania i własnego API layer między CMS a frontendem. Sanity, Prismic, DatoCMS — wszystkie dzielą ten sam problem: content żyje daleko od kodu, synchronizacja wymaga API round-tripu, a ceny rosną z każdym nowym edytorem lub środowiskiem.

Git-based CMS odwraca ten model fundamentalnie. W MazCode każda strona klienta to folder plików JSON w prywatnym GitHub repo. Każda zmiana treści — commit. Każda publikacja — git push, który triggeruje GitHub Actions workflow deploy na Vercel. Wersjonowanie jest natywne: pełna historia zmian, diff każdego akapitu, rollback to dowolna wersja w jednej komendzie. Content branches działają jak feature branches w kodzie — nowy branch, osobny preview URL, merge = publikacja.

Admin panel jest zbudowany wewnątrz samej aplikacji Next.js — nie jako zewnętrzny SaaS, lecz jako osobna route group `(admin)` z 22 podstronami. Edytor widzi drag-and-drop slice'ów, formularze inline, live preview w iframe. Nie wie, że zapisuje JSON do GitHub — widzi wizualny edytor z kolorowymi blokami. Ale to co ląduje w repo, to strukturalny JSON z pełnym typowaniem TypeScript po stronie renderowania. Brak API round-tripu między CMS a frontendem: content jest bundlowany statycznie na buildzie.

Szyfrowanie AES-256-GCM rozwiązuje problem, który uważano za nierozwiązywalny w git-based CMS: jak trzymać content w publicznym lub semi-publicznym repo bez ryzyka wycieku. Każdy plik content (`theme.json`, `site.json`, strony, formularze) jest szyfrowany jako plik `.mcz` z unikalnym 96-bitowym IV per plik. Klucz `CONTENT_ENCRYPTION_KEY` (hex 32B, AES-256) nigdy nie trafia do repozytorium — jest wstrzykiwany do GitHub Actions jako secret przez libsodium sealed box. Workflow deploy każdego site repo ma krok `Decrypt content` wywołujący `scripts/decrypt-content.mjs` przed buildem. Lokalnie i na Vercel runtime aplikacja operuje zawsze na plain JSON — szyfrowanie istnieje tylko na granicy GitHub I/O.

Architektura multi-site to jeden codebase obsługujący wiele klientów równolegle. `content/` jest symlinkiem do `content-sites/<aktywna-strona>/`. Każda strona ma osobne `site.json` (navbar, kontakt, social, footer, webhooks, locale) i `theme.json` (kolory, fonty, spacing, cienie, CTA style z 7 preset themes). Przełączanie między stronami: `npm run site exura-ortho`. W MazCode zarządzamy aktualnie 3 aktywnymi stronami z łącznie 100+ plikami content — jeden admin panel, jeden codebase, zero duplikacji kodu.

Biznesowo: brak miesięcznych opłat za CMS SaaS. Brak vendor lock-in — content to pliki JSON na GitHubie, nie w bazie danych zewnętrznego dostawcy. Backup = git clone. Migracja do innego buildera (jeśli kiedykolwiek) = przepisanie renderera, nie eksport z proprietary API. Dla klienta: edycja treści przez visual editor bez programisty, wersjonowanie bez IT, rollback przez CTO w 30 sekund. Typowy czas od kliknięcia "opublikuj" do pojawienia się zmian na stronie produkcyjnej: 90 sekund.

Kiedy ten model nie działa: content z relacjami many-to-many (sklep e-commerce z 50k produktów i tagami), real-time collaboration wielu edytorów jednocześnie (race conditions na gitcie), lub content wymagający zaawansowanego query language (filtrowanie, sortowanie, paginacja po stronie serwera). Dla tych przypadków rekomendujemy Sanity lub własną bazę Postgres.