Vælg mellem database-CMS, Git-CMS og intet CMS

I mange år har jeg fået variationer af det samme spørgsmål: Hvilket CMS skal jeg vælge?

WordPress er næsten altid med i samtalen. Nogle gange handler den om Drupal, et headless CMS, et Git-baseret CMS eller den platform, der tilfældigvis får meget opmærksomhed lige nu.

Efter mange år med udvikling og vedligeholdelse af hjemmesider synes jeg i stigende grad, at samtalen starter det forkerte sted. Det første spørgsmål er ikke, hvilket CMS kunden har brug for. Det er:

Hvad skal kunden faktisk kunne oprette, styre og ændre?

Et fagmedie, der udgiver flere artikler om dagen, har andre behov end en mindre virksomhed, der ændrer sine ydelsessider to gange om året. En webshop eller bookingplatform med lager, priser og live-tilgængelighed har helt andre krav igen. Det giver ikke meget mening at starte alle tre projekter med at vælge CMS.

På mange hjemmesider, jeg bygger i dag, kan det redaktionelle indhold ligge direkte i Git. Det er versionsstyret, kan reviewes og bliver deployed sammen med sitet. Hvis kunden har brug for en visuel brugerflade, kan jeg lægge et Git-baseret CMS foran filerne. Hvis ingen har brug for den brugerflade, foretrækker jeg ofte slet ikke at have et CMS.

I den anden ende findes projekter, hvor et databasedrevet CMS uden tvivl er den rigtige løsning: mange redaktører, komplekse relationer, brugerkonti, lager, bookinger eller information, der ændrer sig hele tiden.

Den nyttige beslutning handler derfor ikke om min foretrukne platform. Den handler om at vælge den enkleste arkitektur, der passer til det reelle indhold og virksomhedens arbejdsproces.

Database-CMS vs Git-CMS vs intet CMS

Her er den korte sammenligning.

	Databasedrevet CMS	Git-baseret CMS	Git uden CMS
Primær kilde til redaktionelt indhold	Database	Filer i et Git-repository	Filer i et Git-repository
Typiske eksempler	WordPress, Drupal, EmDash	TinaCMS, Decap CMS	Astro med Markdown eller MDX
Visuel editor	Ja	Ja	Ingen separat CMS-brugerflade
Versionshistorik	CMS og database	Git	Git
Vedligeholdelse af CMS	Ja	Ja	Intet CMS at vedligeholde
Backup af indholdsdatabase	Nødvendig	Filerne ligger i Git; støttesystemer kan stadig kræve backup	Ingen indholdsdatabase
Relationelle eller transaktionelle data	Stærkt	Begrænset	Begrænset
Statisk levering af det offentlige site	Muligt	Naturligt	Naturligt
Redaktørrettigheder	Som regel modent	Afhænger af produkt og workflow	Styres gennem repository og reviewproces
CMS-relateret angrebsflade på det offentlige site	Typisk større	Kan adskilles fra det offentlige site	Ingen, men sitet kan stadig have andre dynamiske services
AI-assisteret repository-workflow	Muligt	Stærkt	Meget direkte

Ingen af kolonnerne vinder automatisk. Et database-CMS kan være den bedst tænkelige løsning for én virksomhed og en unødig driftsomkostning for en anden.

Start med arbejdsprocessen, ikke platformen

Før jeg vælger teknologi, vil jeg have svar på nogle konkrete spørgsmål:

• Hvad skal redigeres: sider, artikler, produkter, priser, tilgængelighed, konti eller transaktioner?
• Hvem foretager ændringerne, og er de trygge ved at arbejde sammen med en udvikler?
• Hvor tit ændrer informationen sig?
• Skal ændringen være synlig med det samme, eller er et reviewet deployment acceptabelt?
• Er der flere redaktører, godkendelsestrin, planlagt udgivelse eller detaljerede rettigheder?
• Er informationen redaktionel, relationel eller transaktionel?
• Skal det samme indhold bruges på flere hjemmesider, i apps eller andre kanaler?
• Hvem ejer platform, backups, adgang og deployment efter lancering?

De svar betyder mere end, om et CMS bliver markedsført som traditionelt, headless, composable eller moderne.

Guiden supplerer den bredere forklaring af webudvikling-stacks. Et CMS er kun én del af arkitekturen. Hosting, applikationskode, databaser, API’er, caching og deployment kræver stadig selvstændige beslutninger.

Databasedrevet CMS

Hvad jeg mener med et databasedrevet CMS

Et databasedrevet CMS gemmer det redaktionelle indhold og konfigurationen i en persistent database.

WordPress er det velkendte eksempel. En normal installation kører på PHP med MySQL eller MariaDB, som beskrevet i de aktuelle WordPress-krav. Drupal følger samme grundmodel og understøtter aktuelt MariaDB, MySQL, PostgreSQL og SQLite med versionsspecifikke krav dokumenteret af Drupal.

Nyere software kan bruge samme arkitektoniske idé. EmDash er et Astro-native TypeScript-CMS, der gemmer indhold i SQLite, libSQL, Cloudflare D1 eller PostgreSQL og medier i S3-kompatibel storage. Det ser meget anderledes ud end WordPress, men det kanoniske indhold ligger stadig i et persistent datalag frem for Git-baserede Markdown-filer.

At beholde WordPress som editor, men flytte det offentlige frontendlag til en anden løsning, er endnu en variant. Den smallere beslutning er gennemgået i guiden til headless WordPress.

Databasedrevet betyder ikke gammelt, og Git-baseret betyder ikke automatisk moderne. De løser forskellige problemer.

PHP kræver ikke en database

PHP dukker ofte op i diskussionen, fordi WordPress og Drupal er skrevet i PHP. PHP kræver ikke i sig selv en database. Et PHP-site kan læse filer, kalde API’er eller rendere templates uden at forbinde til MySQL. Det samme gælder JavaScript, TypeScript, Python, Ruby, Java og C#.

Databasen findes, fordi et CMS eller en applikation skal gemme sider, brugere, rettigheder, revisionshistorik, relationer, indstillinger og operationel tilstand.

Browser
   ↓
Webserver
   ↓
PHP / Node / Python / osv.
   ↓
CMS eller applikation
   ↓
Database

Server-sproget er ikke årsagen til databasen. Persistente, dynamiske data er.

Den skelnen forhindrer falske modsætninger. Et hovedsageligt statisk site kan have et server-side booking-API. Et PHP-site kan være uden database. Et Astro-site kan bruge en database. Arkitekturen skal følge dataene, ikke sprogets navn.

Hvornår jeg ville vælge WordPress eller Drupal

Hvis en kunde har en reel redaktionel organisation, udfører CMS’et vigtigt arbejde.

Forestil dig et medie eller en større organisation, hvor flere personer opretter indhold, en anden godkender det, nogen styrer brugere, artikler planlægges, og redaktører skal søge blandt tusindvis af indlæg. Modne platforme har brugt mange år på at løse de redaktionelle problemer.

Man kan genskabe dele af workflowet med GitHub, pull requests og custom værktøjer. På et tidspunkt bliver det dog et forsøg på at genopbygge et CMS. Jeg vil hellere bruge et modent CMS, når arbejdsprocessen faktisk kræver det.

Det samme gælder, når ikke-tekniske redaktører ofte har brug for page building, mediebibliotek, detaljerede roller, previews, taxonomier eller plugin-baserede workflows. En velkendt editor kan sagtens være driftsomkostningen værd.

Hvornår en database er det rigtige værktøj

Argumentet bliver endnu stærkere, når informationen i sig selv er dynamisk.

Produkter kan have varianter, priser, lagerstatus, kategorier og kundespecifikke regler. En forespørgsel som “vis alle blå stole under denne pris, der er på lager” er præcis den slags opgave, en database er bygget til.

Bookinger gør forskellen endnu tydeligere. Tilgængelighed ændrer sig, reservationer oprettes og annulleres, priser varierer efter dato, kunder logger ind, og betalinger gennemføres. Jeg ville ikke gemme den type data i Markdown, blot fordi Git passer godt til redaktionelt indhold.

På et ejendoms- eller udlejningssite kan en beskrivelse fungere fint i MDX. Kalenderen med tilgængelighed hører næsten sikkert hjemme i et bookingsystem, API eller en database. Guiden om driftssikre API-integrationer går længere ned i driften, og klik.villas-casen viser, hvorfor bookingdata og redaktionelle sider har forskellige ansvar.

En af de vigtigste regler i hele diskussionen er:

Redaktionelt indhold og applikationsdata er ikke nødvendigvis det samme.

Database-CMS’ets levetidsomkostning

Et database-CMS bliver tvivlsomt, når en stor infrastruktur findes for et site, der næsten aldrig ændres.

En virksomhedshjemmeside med ti sider kan have PHP-runtime, database, CMS-login, plugins, backups, planlagte opgaver og flere lag caching. Derefter logger nogen ind to gange om året.

Der er ikke noget grundlæggende galt med opsætningen. Spørgsmålet er, om hver bevægelig del gør sig fortjent til sin plads.

CMS, udvidelser og server-runtime skal opdateres. Database og uploads skal backes op. Kompatibilitet skal kontrolleres. Store versioner kræver med tiden migrering. Sikkerhed og kontoadgang kræver fortsat ejerskab.

Den reelle pris på et CMS er ikke kun licensen eller den månedlige hosting. Det er den samlede driftsomkostning gennem hele levetiden.

Revisionshistorik, backups og sikkerhed

Revisionshistorik viser forskellen mellem database- og Git-baseret indhold. WordPress gemmer bevidst revisions, så redaktører kan sammenligne og gendanne tidligere versioner. Det er en nyttig funktion, og revisions gør ikke automatisk WordPress langsomt.

De viser til gengæld, hvordan databasen bliver mere end den publicerede side. Den kan rumme aktuelt og tidligere indhold, metadata, brugere, konfiguration, pluginindstillinger og andre driftsdata. Det aktiv kræver vedligeholdelse og pålidelig backup.

En traditionel CMS-backup skal ofte holde database, uploadede medier, custom kode, konfiguration og udvidelser konsistente. Hvis gårsdagens database gendannes sammen med sidste uges mediefiler, kan resultatet teknisk set være gendannet, men stadig inkonsistent.

Sikkerhed følger samme princip. Et CMS kan eksponere login, administration, API’er, uploads og server-side kode. Plugins tilføjer mere kode. WordPress har en omfattende hardening-vejledning, fordi nyttig software stadig skal sikres.

Det gør ikke WordPress grundlæggende usikkert. Det betyder, at software, som skaber værdi, også giver vedligeholdelsesarbejde og angrebsflade.

Git-baseret CMS

Hvad Git-baseret betyder

Et Git-baseret CMS giver en redaktionel brugerflade, mens filer i Git forbliver den primære kilde til indholdet.

TinaCMS beskriver sig selv som et Git-baseret headless CMS med indhold i Markdown, MDX og JSON. Det tilføjer editor og content API; datalaget bruger en database som indeks eller cache, men filerne forbliver kanoniske.

Decap CMS lægger også en brugervenlig editor foran en Git-provider. Det redaktionelle workflow kan omsætte kladder og publicering til branches, commits og pull requests. Det understøtter blandt andet GitHub, GitLab og Bitbucket.

Workflowet ser omtrent sådan ud:

Redaktør
   ↓
TinaCMS / Decap CMS
   ↓
Markdown / MDX / JSON
   ↓
Git-repository
   ↓
Build
   ↓
Hjemmeside

Det er ofte mit foretrukne kompromis, når kunden reelt har brug for en editor, men det offentlige site ikke behøver en indholdsdatabase ved runtime.

Hvorfor Git fungerer godt som primær kilde

Den største fordel er ikke, at Markdown er moderne. Det er, at repositoryet bliver en mere komplet repræsentation af hjemmesiden.

Når projektet klones, kan kode og indhold følge med sammen. Indholdsændringer kan bruge samme review-, preview- og deploymentproces som kode. En fejl kan kobles til et commit og rulles tilbage. Den aktuelle fil forbliver enkel, mens tidligere versioner ligger i Git-historikken.

Det gør de redaktionelle filer portable. De er ikke fanget i et proprietært eksportformat eller afhængige af en produktionsdatabase, blot for at sitet kan køres lokalt.

TinaCMS og Decap CMS i praksis

TinaCMS giver redaktører en brugerflade oven på filbaseret indhold. De behøver ikke forstå MDX-frontmatter for at ændre et godkendt felt. Tina kan gemme medier i repositoryet eller forbinde til ekstern storage, hvilket er vigtigt, fordi mængden af medier ofte afgør, om et rent repository-workflow fortsat er behageligt.

Decap CMS bruger et mere direkte Git-workflow. Authentication og rettigheder kræver stadig bevidst design. Med GitHub-backend skal normale redaktører have den relevante adgang, mens open authoring kan bruge forks og pull requests for bidragydere uden direkte skriverettighed.

Det viser det vigtigste kompromis: Editoren kan se enkel ud, men Git-rettigheder, preview-deployments og publiceringsregler eksisterer stadig nedenunder. Nogen skal konfigurere og eje dem.

Hvornår et Git-CMS passer

Det er stærkt, når informationen primært er redaktionel frem for transaktionel:

• Ydelsessider
• Artikler og guides
• Cases
• Medarbejderprofiler
• FAQ og dokumentation
• Lokations- og destinationsindhold
• Stabile produkt- eller boligbeskrivelser

Kunden får visuel redigering. Udvikleren får versionsstyrede, portable filer tæt på koden.

Efter publicering kan et build generere statisk HTML og levere det fra hostingplatform eller CDN. CMS’et behøver ikke besvare hvert offentligt sidekald. Hvis editoren midlertidigt er utilgængelig, kan det allerede deployede site fortsætte.

Hvornår et Git-CMS er det forkerte værktøj

Et Git-CMS er stadig et ekstra system. Det kræver konfiguration, authentication, repository-rettigheder, previewadfærd, beslutninger om medier og stabile builds. Egne dependencies og integrationer skal også opdateres.

Git er ikke en erstatning for en database. Det er et dårligt valg til live-lager, transaktioner, kundesessioner eller tilgængelighed, der ændrer sig ofte. Nogle hundrede eller mange tusinde redaktionelle filer kan være håndterbare, men transaktionsvolumen og relationelle forespørgsler er andre problemer.

Målet er ikke at lægge alt i Git. Målet er at lægge den rigtige information i Git.

Intet CMS, men stadig et kontrolleret workflow

Hvad intet CMS faktisk betyder

Intet CMS betyder ikke løse HTML-filer uploadet med FTP. Det betyder heller ikke ingen versionsstyring, ingen struktur og intet review.

Jeg vil stadig have et Git-repository, branches, commit-historik, automatiske builds, previews, schemas og validering, hvor det er relevant. Forskellen er blot, at der ikke findes en separat CMS-brugerflade.

Et Astro-projekt kan for eksempel indeholde:

content/
├── articles/
├── cases/
├── services/
├── team/
└── guides/

Indholdet kan være Markdown eller MDX med struktureret frontmatter. Buildet kan validere krævede felter og stoppe deployment, hvis indholdsmodellen er ugyldig.

Det er kontrolleret indholdsstyring. Det er bare ikke et CMS-produkt.

Hvorfor jeg oftere vælger den løsning

Mange mindre virksomhedshjemmesider har mere brug for et CMS i salgssamtalen end efter lancering.

Virksomheden siger, at den skal kunne redigere alt selv. To år senere har nogen åbnet CMS’et tre gange. Når en reel ændring bliver nødvendig, skriver ejeren til udvikleren, fordi den også omfatter layout, beslægtede sider, SEO-metadata, redirects eller en integration.

I den situation vil jeg hellere starte med den enklere arkitektur. Intet CMS betyder én applikation, én authentication-løsning og én administrationsflade mindre. Det kan også betyde, at det offentlige site slet ikke har en indholdsdatabase.

For en mindre servicevirksomhed, der ændrer nogle få sider hver måned eller hvert kvartal, kan et kontrolleret udviklingsworkflow være bedre egnet end driftsomkostningen ved et CMS, der næsten aldrig bruges.

Repositoryet bliver indholdsworkflowet

Uden CMS er en indholdsændring en almindelig repository-ændring. Beslægtede edits kan tilhøre samme commit. En reviewer kan læse diffen. En branch kan skabe et preview. Validering kan køre før merge. En forkert ændring kan rulles tilbage.

Det, der forsvinder, er abstraktionslaget designet til redaktører. Hvis ingen har brug for brugerfladen, er den svær at retfærdiggøre som noget, der fortsat skal vedligeholdes.

AI ændrer brugerfladen, ikke ansvaret

Historisk havde intet CMS et tydeligt problem: Udviklere kunne uden problemer redigere Markdown, men de fleste kunder kunne ikke. En forklaring af frontmatter, commits og pull requests var ikke en realistisk erstatning for en god visuel editor.

Repository-bevidste AI-værktøjer ændrer den brugerflade. En kunde eller udvikler kan bede om: “Skift leveringstiden fra fem til syv arbejdsdage overalt, men ret ikke gamle cases.” En agent kan søge i repositoryet, finde de relevante filer, lave en konsistent ændring, køre validering og forberede en pull request.

Den, der bestiller ændringen, behøver ikke vide, hvor hver fil ligger. I den forstand kan et AI-assisteret workflow levere en del af den brugerflade, der tidligere krævede et CMS.

Det gør ikke CMS-platforme overflødige, og det bør ikke betyde fri automatisk publicering. Jeg foretrækker et workflow, der kan reviewes:

Ønsket ændring
      ↓
AI opdaterer filer
      ↓
Build og validering
      ↓
Pull request og preview
      ↓
Menneskeligt review
      ↓
Merge og deployment

Ansvaret forbliver menneskeligt. Værktøjet reducerer den tekniske friktion omkring forberedelsen af ændringen.

Sikkerhed og backup uden CMS

Et statisk genereret offentligt site kan være uden CMS-login, indholdsdatabase og en generel applikation, der behandler et artikelkald. Den besøgende modtager HTML, CSS, JavaScript og billeder. Det fjerner CMS-specifik angrebsflade fra det offentlige site.

Det fjerner ikke alle sikkerhedsproblemer. Repository-konti kræver stærk authentication. Adgang skal begrænses. CI/CD-legitimationsoplysninger skal beskyttes. Dependencies og tredjeparts-actions skal gennemgås. Formularer, API’er og bookingflows kræver stadig deres egen sikkerhed.

Angrebsfladen ændrer sig og kan blive mindre, men den bliver aldrig nul.

Gendannelse er ofte enklere for filer i repositoryet, fordi kode og indhold deler versionshistorik. GitHub dokumenterer mirror clones og andre muligheder for repository-backup. Jeg ville stadig have en separat backup af et vigtigt repository.

Eksterne medier kræver deres egen plan. Billeder i R2, S3 eller en billedtjeneste bliver ikke automatisk backet op, blot fordi indholdsfilerne ligger i Git.

Du behøver ikke vælge kun én løsning

De fleste virkelige hjemmesider er allerede hybride. Det nyttige spørgsmål er, hvor hver type information hører hjemme.

Forestil dig et udlejnings- eller bookingsite:

Boligbeskrivelser → Git-repository
Områdeguides      → Git-repository
Artikler og FAQ   → Git-repository
Tilgængelighed    → Booking-API
Priser            → Booking-API
Reservationer     → Database
Billeder          → Object storage

Redaktionelle beskrivelser ændres måske nogle få gange om året. Tilgængelighed kan ændre sig hvert minut. Priser afhænger af datoer, sæson og opholdslængde. Reservationer skal registreres med det samme.

Hvis alt tvinges gennem ét CMS, bliver ansvaret koblet forkert sammen. Et databasebaseret bookingsystem kan håndtere applikationsdata, mens et statisk offentligt site bruger Git-baseret indhold. En kontaktformular kan køre i en serverless funktion. Søgning kan bruge et fokuseret indeks. Authentication kan ligge hos en separat tjeneste.

At én feature kræver database betyder ikke, at siden “Om os” også skal ligge der. På samme måde betyder det ikke, at en booking hører hjemme i Markdown, blot fordi ydelsessider fungerer godt i Git.

Spørg ikke, hvilket CMS der skal eje hjemmesiden. Spørg, hvilket system der skal være primær kilde til hver slags information.

En beslutningsguide

Vælg et databasedrevet CMS, når:

• Mange redaktører har brug for modne roller, planlægning, godkendelse og søgning
• Indholdet har komplekse relationer eller skal opdateres øjeblikkeligt
• Produkter, konti, transaktioner eller bookinger er centrale
• En velkendt administrationsflade bruges ofte
• Organisationen kan eje opdateringer, backups og sikkerhed

Vælg et Git-baseret CMS, når:

• Indholdet primært er redaktionelt og egner sig til filer
• Redaktører har brug for en visuel brugerflade
• Versionsstyring, previews og portabelt indhold betyder meget
• Det offentlige site får reel værdi af statisk levering
• Teamet kan eje Git-rettigheder, builds og CMS-integration

Vælg Git uden CMS, når:

• Sitet er forholdsvis stabilt
• En udvikler eller et kontrolleret AI-assisteret workflow vedligeholder indholdet
• Review og deployment kan ske gennem pull requests
• Fjernelse af en ubrugt administration reducerer levetidsomkostningen
• Der stadig er en tydelig ejer af indholdsændringer og backups

Vælg en hybrid arkitektur, når redaktionelt indhold og live-applikationsdata har forskellige behov. Det er ofte det mest ærlige svar.

Ofte stillede spørgsmål

Har alle virksomhedshjemmesider brug for et CMS?

Nej. Et CMS er værdifuldt, når nogen regelmæssigt bruger editor, rettigheder, publiceringsworkflow eller indholdsmodel. En relativt stabil virksomhedshjemmeside kan være lettere at vedligeholde med strukturerede filer i Git, reviewbare ændringer og automatisk deployment.

Er WordPress et dårligt valg til en mindre virksomhed?

Nej. WordPress er et fornuftigt valg, når redigering, plugin-økosystem eller velkendt workflow giver reel værdi. Det bliver tvivlsomt, når CMS’et næsten aldrig bruges, men stadig skaber løbende arbejde med opdateringer, backup og sikkerhed.

Kan GitHub erstatte en database?

Ikke til transaktionelle eller hurtigt skiftende applikationsdata. Git fungerer godt til redaktionelle filer og reviewede ændringer. Lager, reservationer, betalinger, kundesessioner og relationelle forespørgsler hører normalt hjemme i en database, bookingplatform eller specialiseret API.

Kan en ikke-teknisk kunde styre et site uden CMS?

Nogle gange. Et udviklerstyret eller AI-assisteret workflow kan forberede repository-ændringer, uden at kunden skal forstå Markdown eller Git. Processen bør stadig have validering, preview og menneskeligt review før deployment.

Er et Git-baseret CMS helt uden database?

Ikke nødvendigvis. Det kanoniske indhold kan forblive i Git, mens CMS’et bruger indeks, cache, authentication eller et API-datalag. Den vigtige forskel er, hvilket system der er primær kilde, og hvad der skal gendannes efter en fejl.

Hvad skal afklares, før man vælger CMS?

Definér hvad der skal redigeres, hvem der gør det, hvor tit det ændrer sig, om godkendelse er nødvendig, og om informationen er redaktionel, relationel eller transaktionel. De svar gør normalt den passende arkitektur langt tydeligere.

Tilføj kun et CMS, når det gør sig fortjent til sin plads

Jeg starter ikke med at spørge, om WordPress, Drupal, EmDash, TinaCMS eller Decap CMS er den bedste platform. Jeg starter med menneskerne, dataene og driftsworkflowet.

Hvis en virksomhed har en reel redaktionel organisation, komplekse data eller applikationsfunktionalitet, kan en databasedrevet løsning være præcis rigtig. Hvis indholdet naturligt hører hjemme i filer, men redaktører har brug for en visuel brugerflade, kan et Git-baseret CMS være et stærkt kompromis. Hvis hjemmesiden er stabil, og ændringer allerede går gennem et kontrolleret udviklingsworkflow, spørger jeg i stigende grad, hvorfor der skal tilføjes endnu et lag.

Intet CMS betyder ikke ustyret indhold. Indholdet kan stadig være struktureret, valideret, reviewet, versionsstyret, rullet tilbage og backet op.

Princippet er enkelt:

Brug en database, når dataene kræver en database. Tilføj et CMS, når mennesker reelt har brug for et CMS. Ellers skal arkitekturen holdes så enkel som muligt.

Hvis du skal beslutte, hvordan en hjemmeside skal håndtere sider, guides, produkter, bookinger eller andre data, kan du sende mig det nuværende site og forklare, hvem der skal ændre hvad. Jeg kan hjælpe med at adskille redaktionelt indhold fra applikationsdata og anbefale en arkitektur, der er nem at drive efter lancering.