What storing content in Git rather than a database really means — and why it matters for agencies.
In AstroForge, all content is stored in JSON files and versioned on GitHub. This is a fundamental departure from the database approach most CMS systems take.
Database-backed CMS systems store content as momentary data. What was there yesterday, what the headline said two weeks ago — finding answers to those questions is hard. A wrong delete is often irreversible.
In Git, every change is a commit. History is preserved forever. A wrong change: reversed with git revert in a single command. Who changed what and when: visible in seconds with git blame.
Every save made through the CMS is committed directly to GitHub by the astrocms Worker. The commit message identifies which page section was changed. This means:
The npm run seed command generates JSON skeletons for all pages. Existing content is preserved; only missing keys are added. When a new organism is added, all page JSONs can have new keys merged in safely.
Git-backed content has one drawback: extremely high-frequency updates (dozens of commits per minute) can hit GitHub API rate limits. For this scenario, batching CMS writes or using a temporary KV cache layer between the CMS and GitHub is a workable solution.
Astro SSG: Why Static Sites Belong Here | AstroForge Blog
2025-05-10How Multi-Tenant CMS Works | AstroForge Blog
2025-04-18The Organism System: From Component to Page | AstroForge Blog
2025-02-14Choosing a Template Engine for Your Agency | AstroForge Blog
2025-01-30Schema Pipeline: TypeScript to CMS Form | AstroForge Blog
2024-12-20