Choosing how your website stores and serves content is one of those decisions that feels small at first and then shapes every workflow that follows. The Git-backed CMS vs headless CMS debate sits at the center of that choice. Both models separate writing content from the code that displays it, but they keep that content in very different places, and that single difference ripples out into ownership, versioning, build pipelines, and who on your team can comfortably do the work. This post is a fair, practical comparison so you can match the model to how your site and team actually operate.
There is no universally correct answer here. A documentation site run by engineers and a multi-client agency publishing dozens of marketing sites have genuinely different needs. The goal below is to explain where content lives in each model, what that means in day-to-day practice, and the conditions under which each one tends to fit best.
Git-backed CMS vs headless CMS: what each term means
A headless CMS stores your content in a hosted database and exposes it through an API. Your front end — built in Next.js, or any other framework — requests that content over the network at build time or at runtime and renders it. The "head" (the presentation layer) is decoupled from the "body" (the content store), which is the part that gives the model its name.
A Git-backed CMS keeps content as files inside a Git repository. Each Post, Page, or entry is a Markdown or MDX file with YAML frontmatter, sitting alongside (or near) your code. There is no separate content database to query; the content is part of the repository your site already builds from. Acrosite is a Git-backed platform: content lives in your own GitHub repository, and publishing commits those files to a branch and content path you configure.
The shared idea is decoupling content from layout. The dividing line is *where the canonical content lives* — an external service you call, or files you own in version control.
Where your content lives, and why it matters
This is the most consequential difference, so it is worth being concrete.
With a headless CMS, the source of truth is the vendor's database. You read and write through their API and dashboard. Your repository holds code; the content arrives separately at build or request time.
With a Git-backed model, the source of truth is the repository. The exact files that render your site are the same files you can clone, diff, and back up. In Acrosite, a published Post becomes a real file like this in your repo:
content/posts/git-backed-cms-vs-headless-cms.md
---
title: "Git-backed CMS vs headless CMS"
description: "A practical comparison of the two models."
date: 2026-06-06
draft: false
tags: ["cms", "git", "publishing"]
---That file is plain text. It is portable, greppable, and reviewable. If you ever leave the platform, the content is already where you can use it. You can read more about that model on the Git-backed publishing feature page.
Ownership and portability
Ownership is where the two models feel most different over a long horizon.
In a headless setup, your content is structured data inside someone else's system. Most vendors offer exports, but the export is a copy in their schema, not the live thing your site runs on. Migrating means rebuilding integrations and re-mapping fields.
In a Git-backed setup, portability is the default rather than a feature. Because every entry is a file in your repository, "exporting" is just cloning the repo you already have. The same property makes disaster recovery simple: your content history is your Git history.
Portability is not only about leaving a tool. It is about being able to script, search, and audit your content with the same ordinary tools your engineers already use on code.
Versioning, history, and review
Both models track changes, but they do it at different layers.
A headless CMS usually offers its own revision history and, on some plans, editorial workflow features inside the dashboard. That history lives in the vendor's system and follows their model of versions.
A Git-backed CMS inherits Git's versioning for free. Every publish is a commit with an author, a timestamp, and a diff you can read line by line. In Acrosite, each publish is also captured in Publish Logs, which record the steps of an attempt — content validated, committed to GitHub, commit SHA saved, deployment triggered — without exposing tokens or raw provider payloads. Deployment Logs record what happened after the commit when your hosting provider rebuilt.
For teams that already live in pull requests and commit history, this alignment is a real advantage: content changes and code changes share one timeline.
Build and deploy implications
How content reaches a live page differs in ways that affect performance and operational complexity.
The headless path
A headless front end fetches content from the API. For statically generated sites, that fetch happens at build time; for dynamic ones, it can happen per request. Either way you are depending on a network call to an external service, which means you think about API availability, rate limits, and caching. The upside is that content can change without a new build if you render dynamically.
The Git-backed path
In a Git-backed model, a content change *is* a repository change, so it naturally fits static-site build pipelines. A commit triggers a rebuild, the build reads files from disk, and the result is deployed. There is no live content API in the request path, which removes a class of runtime dependencies. Acrosite makes this loop explicit: after a commit, a configured deployment trigger profile tells your hosting provider to rebuild, and you get Deployment visibility into the result. You can see the flow end to end on the how it works page.
The trade-off: because publishing usually implies a build, truly instant content edits to a static site are gated on build time, though scheduling and previews mitigate this in practice.
Who each model tends to suit
Neither model is "better." They fit different shapes of team and site.
A headless CMS often suits:
- Apps that serve content to many channels at once (web, mobile, kiosk) from one API.
- Teams comfortable owning and operating API integrations and caching.
- Highly dynamic sites where content must change without a redeploy.
A Git-backed CMS often suits:
- Marketing sites, blogs, and documentation built on static or hybrid frameworks.
- Teams that already work in GitHub and value content living beside code.
- Agencies managing many client sites who want clean per-site ownership and handoff.
Acrosite is built for that second group while keeping non-technical contributors productive. Editors work in a dashboard with Posts, Pages, and Custom Content Types shaped by typed Custom Fields, and they never have to touch raw files in GitHub. Drafts stay private in the app until published. A clean editorial layer sits on top of a Git source of truth.
A practical way to decide
If you are weighing the two, walk through this short checklist:
- List your delivery channels. Many non-web channels lean headless; a single website leans Git-backed.
- Decide where you want the source of truth to live — a vendor database, or your own repository.
- Look at your team's habits. If pull requests and commits are already normal, a Git-backed workflow will feel native.
- Map your publishing cadence to build time. If most edits can publish on a build, Git-backed fits cleanly; Scheduled publishing helps here by holding an approved draft and committing it at the chosen time.
- Consider client and reviewer workflows. If outside stakeholders need to review without repository access, confirm the model supports that cleanly.
That last point is where many comparisons stop short. Client review is a common need for agencies, and it is easy to assume "files in a repo" means "everyone needs GitHub." It does not. With Acrosite, Client Reviewers are invited per Project and see only the content assigned to them — they can read drafts, comment, and Approve or Request Changes, with no GitHub access and no billing or settings visibility. Internal Team Members manage the Review Queue. The Git-backed foundation stays invisible to the people who only need to review words on a page.
Bringing the comparison together
The honest summary of the Git-backed CMS vs headless CMS question is this: choose based on where you want your content to live and how your team likes to work, not on which model sounds more modern. A headless CMS centralizes content in an API for multi-channel delivery and runtime flexibility. A Git-backed CMS keeps content as portable files in your own repository, aligns publishing with version control, and fits static and hybrid site builds naturally.
For agencies and website owners running content-first sites on frameworks like Next.js, the Git-backed model offers ownership and auditability that are hard to match — and with the right editorial layer, it does not force every contributor to learn Git. If that describes your work, it is worth seeing the full picture on the features overview and weighing the plans available, from Solo through Agency tiers, on the pricing page, which includes a 14-day free trial.