Site fără bază de date: când alegi un CMS bazat pe Git

Un site fără bază de date stochează conținutul ca fișiere într-un repository Git, iar un CMS bazat pe Git le editează printr-un panou de administrare. Fiecare salvare devine un commit făcut prin API-ul GitHub, apoi hostul reconstruiește site-ul. Nu ai o bază de date de securizat, de actualizat sau de plătit, iar orice modificare poate fi anulată. Soluția se potrivește când conținutul îl schimbă câțiva editori și mai puțin când îl creează vizitatorii.

Ce este un CMS bazat pe Git?

Un CMS clasic răspunde fiecărei cereri interogând o bază de date și construind pagina. WordPress, de exemplu, recomandă PHP plus MySQL sau MariaDB. Un CMS bazat pe Git scoate baza de date din ecuație. Conținutul stă în fișiere JSON, Markdown sau YAML din repository, pasul de build transformă fișierele în pagini dinainte, iar hostul servește paginile gata făcute dintr-un CDN.

Editorii primesc în continuare o interfață obișnuită de administrare. Decap CMS este un exemplu open source. Documentația lui descrie o aplicație React care învelește fluxul Git, ține conținutul în repository și funcționează cu GitHub, GitLab sau Bitbucket. Îți poți scrie și propriul admin, iar noi am mers pe această variantă.

Cum funcționează danubelabs.net fără bază de date?

Site-ul rulează pe Next.js 16 (App Router), React 19, Tailwind 4 și TypeScript. Fiecare pagină, serviciu, proiect și articol este un fișier JSON în repository-ul Git. Programările stau în Google Calendar, așa cum arată articolul despre programări, deci nicăieri în stack nu există o bază de date.

Conținutul este JSON, cu un câmp pentru fiecare limbă

Fiecare câmp de text vizibil utilizatorului este un obiect cu cheile en și ro. Iată o intrare redusă din fișierul de servicii:

{
  "slug": "web-development",
  "title": { "en": "Web development", "ro": "Dezvoltare web" },
  "group": "build",
  "published": true
}

O funcție mică rezolvă un întreg arbore de obiecte pentru o singură limbă, în momentul în care se randează pagina. Câmpurile care nu se traduc, precum slug-urile și prețurile, sunt marcate în schemă. Formularele din admin sunt generate din aceeași schemă, deci un câmp nou nu cere cod nou de formular.

Drumul unei salvări

1. Un editor schimbă un câmp în /admin și apasă salvare.
2. Adminul apelează un strat de stocare cu două variante: discul local în dezvoltare și API-ul GitHub Contents în producție. Două variabile de mediu, un token și numele repository-ului, comută între ele.
3. Apelul API creează un commit pe ramura principală. Endpoint-ul GitHub cere un mesaj de commit, conținutul fișierului în Base64 și, la actualizare, SHA-ul fișierului înlocuit.
4. Netlify vede commitul și reconstruiește site-ul.
5. Paginile noi apar live în ambele limbi.

Ce avantaje are un site fără bază de date?

• Nicio bază de date de securizat, actualizat, salvat sau plătit. Mai puține piese în mișcare înseamnă mai puține lucruri care se strică la 3 noaptea și o suprafață de atac mai mică pe stratul de date.
• Istoric complet și revenire la o versiune anterioară. Fiecare salvare din admin este un commit cu mesaj și autor. Ca să anulezi o modificare greșită, faci revert la acel commit.
• Hosting gratuit. danubelabs.net rulează pe planul gratuit Netlify. Paginile construite dinainte cer puțină putere de calcul.
• Viteză. Paginile sunt generate dinainte și servite dintr-un CDN. Pagina principală și cea de contact obțin 100 în toate cele patru categorii Lighthouse: performanță, accesibilitate, bune practici și SEO.
• Revizuire și ramuri. Modificările de conținut pot trece prin ramuri și pull request-uri ca un cod, dacă vrei un pas de aprobare.
• Portabilitate. Conținutul tău sunt fișiere simple pe care le ai deja. Nu există pas de export și nu depinzi de un furnizor.

Și costul contează. Despre cât costă un site în România, inclusiv hosting și mentenanță, scriem în articolul despre prețul unui site în 2026.

Ce limite are un CMS bazat pe Git?

Se termină minutele de build

Planul gratuit Netlify numără build-urile într-un buget lunar. În contul nostru sunt 300 de minute de build. Fiecare salvare din admin și fiecare fișier media încărcat este un commit, iar fiecare commit este un build. În acest an minutele s-au terminat o dată. Deploy-urile s-au oprit fără niciun mesaj de eroare, iar build-urile sărite în acest interval nu au fost reluate după resetare, așa că a trebuit să declanșăm manual un build nou.

Conturile Netlify mai noi folosesc credite. Potrivit documentației de billing Netlify, planul Free are o limită fermă de 300 de credite pe lună, iar un deploy de producție costă 15 credite, adică cel mult 20 de deploy-uri de producție pe lună. Verifică ce model folosește contul tău.

Soluția este să nu construiești când nu s-a schimbat nimic vizibil. Netlify sare peste un deploy când mesajul de commit conține [skip ci] sau [skip netlify]:

git commit -m "Update internal notes [skip ci]"

Următorul commit fără marcaj construiește totul, inclusiv modificările sărite. Folosim marcajul pe commit-urile cu notițe, iar trimiterile din formularul de contact îl poartă deja. Încărcările media sunt următorul loc unde îl aplicăm, pentru că o imagine nu schimbă site-ul randat până când o pagină nu o referă.

Scrierile nu sunt instantanee

O salvare apare live abia după ce se termină commitul, build-ul și deploy-ul. Timpul de build depinde de site, așa că măsoară propriile deploy-uri. Dacă editorii trebuie să vadă o schimbare în câteva secunde, un CMS cu bază de date sau un CMS headless SaaS se potrivește mai bine.

Fără conținut generat de utilizatori la scară mare

Comentariile, recenziile, conturile de utilizator, forumurile și coșurile de cumpărături produc date toată ziua. Fiecare scriere ar fi un commit și un build. Ține aceste date într-o bază de date sau într-un serviciu făcut pentru ele.

Editări simultane și fișiere mari

O actualizare trebuie să citeze SHA-ul versiunii pe care o înlocuiește, deci două persoane care salvează același fișier în același moment creează un conflict pe care trebuie să îl gestionezi. Git nu îl ascunde. Endpoint-ul de contents al GitHub acceptă toate funcțiile doar pentru fișiere de până la 1 MB, acceptă tipuri media raw între 1 și 100 MB și refuză tot ce e mai mare. Ține imaginile mici și scoate-le din fișierele de conținut.

Magazine cu stoc live

Stocurile, prețurile și comenzile se schimbă din minut în minut și prin acțiunea vizitatorilor. Asta este treabă pentru o bază de date. Un CMS bazat pe Git poate ține descrierile produselor, iar un serviciu de magazin sau o bază de date trebuie să țină tot ce se schimbă la finalizarea comenzii.

CMS bazat pe Git, WordPress sau CMS headless SaaS: cum se compară?

Pentru cine este potrivit un CMS bazat pe Git?

Se potrivește pentru site-uri de companie și de marketing, portofolii, documentație, bloguri cu puțini editori și site-uri de prezentare bilingve. Aceste site-uri se schimbă de câteva ori pe săptămână, prin oameni pe care îi cunoști, și câștigă cel mai mult din viteză, istoric și hosting gratuit.

Se potrivește prost pentru piețe online, site-uri cu abonamente, forumuri, magazine cu stoc live și orice site cu sute de editori sau cu conținut care trebuie să apară în câteva secunde. Dacă ești nehotărât, notează cine creează conținut și cât de des se schimbă. Când răspunsul este vizitatorii, sau la fiecare câteva secunde, alege o bază de date.

Cum construiești un site ca acesta?

1. Alege un framework care construiește paginile dinainte, de exemplu Next.js.
2. Modelează conținutul ca JSON sau Markdown, cu o schemă, un fișier pentru fiecare pagină sau element și un câmp pentru fiecare limbă dacă site-ul e bilingv.
3. Adaugă un admin. Decap CMS îți dă unul gata făcut, iar un admin propriu îți dă control deplin asupra formularelor și permisiunilor.
4. Conectează repository-ul la un host care face deploy la fiecare commit.
5. Stabilește regulile de commit: ce salvări trebuie să construiască și care trebuie să poarte [skip ci].

Dacă adminul poate sta în altă parte, de exemplu Decap CMS cu autentificarea editorilor prin furnizorul lor Git, site-ul în sine poate rămâne un export static pur. În Next.js asta este o singură setare:

// next.config.js
const nextConfig = {
  output: 'export',
}
module.exports = nextConfig

Documentația Next.js listează ce nu poate folosi un export static: Incremental Static Regeneration, Server Actions, Proxy și loader-ul implicit de imagini nu sunt disponibile. Adminul nostru are rute de server care țin tokenul GitHub și scriu commit-uri, așa că danubelabs.net rulează pe runtime-ul Next.js al Netlify.

Vrei un site ca acesta?

Danube Labs construiește site-uri bilingve, fără bază de date, cu un admin pe care îl poate folosi echipa ta, găzduite în repository-ul și contul tău de hosting. Poți vedea rezultatul în studiul de caz danubelabs.net, poți citi ce construim pe pagina de dezvoltare web sau poți programa un apel introductiv gratuit ca să verificăm dacă un CMS bazat pe Git se potrivește site-ului tău.