A static site CMS is a content layer for a static site. There are two patterns: git-based CMSs (Keystatic, Publii, Siteleaf, Decap) keep the content in the repo as Markdown or YAML, with edits triggering a rebuild; API-based CMSs (Sanity, Contentful, Strapi, Payload) keep the content in a service, with the build fetching the content at build time. The two are not interchangeable — git-based is simpler and works for developer-only teams, API-based scales to non-technical editors and supports real-time previews. The right answer depends on whether the team writing content is the same team building the site, and on how often the content changes.
This post walks through both patterns, the trade-offs, the right answer for a small team, the right answer for a content team, and the right answer for a marketing site.
Table of contents
- What a static site CMS actually does
- The git-based pattern
- The API-based pattern
- The trade-off: simplicity vs scalability
- The right answer for a small team
- The right answer for a content team
- The right answer for a marketing site
- The deploy story
- How this fits the rest of the stack
- FAQ
What a static site CMS actually does
A static site CMS is the content layer for a static site. The static site is a build of HTML, CSS, and JavaScript files, served from a CDN. The content is the data the static site displays — the blog posts, the product pages, the marketing copy, the documentation. The CMS is the tool the team uses to author the content.
The CMS does not serve the content. The CMS authors the content. The build picks up the content, generates the static site, and the CDN serves the static site. The separation is the part that makes the pattern scalable — the build is a snapshot of the content, the snapshot is served from the CDN, the snapshot can be cached aggressively.
The two patterns, git-based and API-based, differ in where the content lives between builds. Git-based: the content lives in the repo, the CMS edits the repo, the build picks up the changes. API-based: the content lives in a service, the CMS edits the service, the build fetches the content from the service.
The git-based pattern
The git-based pattern is the simpler one. The team picks a git-based CMS (Keystatic, Publii, Siteleaf, Decap, Forestry), the CMS writes to a Git repo, the build picks up the changes on push.
The standard flow:
- The team installs the CMS in the repo (Keystatic is a Node.js package, Decap is a Git-based plugin).
- The team configures the CMS with the content collections (blog posts, products, pages).
- The team’s editors use the CMS’s local or hosted UI to edit the content.
- The CMS commits the changes to a Git branch.
- The build picks up the changes, regenerates the static site, deploys the new build.
The benefit: the content is in the repo, the team has a full version history, the team can edit the content via Git directly if the CMS is unavailable. The deploy story is the same as any other static site — push to main, the build runs, the site is live.
The gotcha: the CMS needs to be able to commit to the repo. The team’s GitHub token is in the CMS’s config, the token has write access to the repo. The team that is uncomfortable with the token can use a service account, but the account still has write access.
The second gotcha: the CMS’s UI is either local (Keystatic runs in the developer’s environment) or hosted (Decap has a hosted version). The team that picks a local CMS has to teach the editors how to run the CMS locally, which is a non-trivial onboarding cost.
The API-based pattern
The API-based pattern is the more scalable one. The team picks an API-based CMS (Sanity, Contentful, Strapi, Payload), the content lives in the service, the build fetches the content at build time.
The standard flow:
- The team signs up for the CMS service.
- The team configures the content schema in the CMS (or in code, for headless CMSs).
- The team’s editors use the CMS’s hosted UI to edit the content.
- The CMS stores the content in its database.
- The build fetches the content via the CMS’s API, generates the static site, deploys the new build.
The benefit: the content is in a service, the editors use a hosted UI, the team’s developers do not have to teach the editors how to run anything. The CMS handles versioning, scheduling, multi-language, real-time previews, and other features that are out of scope for a git-based CMS.
The gotcha: the content is in the CMS, not in the repo. The team that wants a full version history uses the CMS’s history feature, not Git. The team that wants to edit the content via Git cannot — the content is not in Git.
The second gotcha: the CMS service has a cost. The team’s bill is the CMS’s plan plus the static site hosting. The right answer is to model the CMS’s plan alongside the static site’s plan.
The third gotcha: the CMS is a runtime dependency. The build needs the CMS to be reachable. The team that has a CMS outage cannot build the site. The right answer is to cache the content in the repo (a content.json file committed at build time) so the build can fall back to the cache.
The trade-off: simplicity vs scalability
The trade-off is the simplicity of git-based vs the scalability of API-based. The git-based pattern is simpler to set up (no service to sign up for, no API to integrate), but it does not scale to non-technical editors (the editors have to run the CMS locally or use a hosted CMS that is git-based). The API-based pattern is more scalable (hosted UI, versioning, scheduling, real-time previews), but it is more complex to set up (a service to sign up for, an API to integrate, a content schema to design).
The right answer depends on the team. The team that writes content and builds the site (a developer-only team) is fine with git-based. The team that has separate content writers (a content team) needs API-based. The team that has a marketing team with a content writer or two is in between, and the right answer depends on the marketing team’s preference.
The right answer for a small team
The right answer for a small team (one to three developers) is git-based, with a hosted UI. The standard picks: Decap (formerly Netlify CMS) has a hosted UI that commits to the repo, Keystatic is local-first but supports hosted mode, Publii is a desktop app for solo writers.
The standard pattern: the team uses Keystatic or Decap, the content is in the repo, the build picks up the changes on push, the deploy is automatic. The team’s content writers use the CMS’s UI, the team’s developers use the repo. The workflow is the same as any other Git-based project.
The right answer for the team that has only one writer: Publii or Siteleaf, both of which are designed for solo writers. The CMS runs on the writer’s machine, commits to a Git branch, the build picks up the changes.
The right answer for a content team
The right answer for a content team (separate from the developers, with multiple writers, with a content calendar) is API-based. The standard picks: Sanity is the most popular in 2026 (with a real-time preview, a hosted studio, and a structured content model), Contentful is the enterprise pick (with a more formal content model and a higher price), Strapi is the open-source pick (the team runs the service themselves), Payload is the developer-first pick (the team defines the schema in code).
The standard pattern: the content team uses the CMS’s hosted UI, the developers integrate the CMS’s API at build time, the build fetches the latest content, the deploy is automatic. The team’s developers do not have to teach the content team how to use Git.
The right answer for the team that wants the content schema in code (so the developers own the schema): Payload or Sanity. The right answer for the team that wants the content team to own the schema: Contentful. The right answer for the team that wants to self-host: Strapi.
The right answer for a marketing site
The right answer for a marketing site is API-based, with a real-time preview. The standard pick: Sanity (with the real-time preview plugin), Contentful (with the preview API), Strapi (with the preview mode).
The standard pattern: the marketing team uses the CMS’s hosted UI, the developers integrate the CMS’s API at build time, the build fetches the latest content, the deploy is automatic. The marketing team sees a preview of the page as they edit, the preview is a hosted environment, the team can share the preview URL with stakeholders for review.
The gotcha: real-time preview is a feature, not a default. The team that picks a CMS without real-time preview has a slower feedback loop. The right answer is to pick a CMS with real-time preview, or to use a service that provides it (e.g., Vercel’s preview deployments for the static site).
The deploy story
The deploy story for a static site CMS is the same as for any other static site. The build is a snapshot of the content, the snapshot is served from a CDN, the snapshot is cached aggressively. The team picks a static site host (Vercel, Netlify, Cloudflare Pages, RunxBuild), the host builds the site on push, the host deploys the build to the CDN.
The right answer for the team that wants the CMS to be the source of truth: the build is triggered by a webhook from the CMS. The team that uses Sanity, for example, sets up a webhook that triggers a rebuild on content change. The build is automatic, the deploy is automatic, the content is up to date.
The gotcha: the build needs to be fast. The team that has a 10-minute build is in trouble — the build runs on every content change, the team is waiting 10 minutes for the preview. The right answer is to use incremental builds (Vercel’s ISR, Netlify’s build plugins, or the CMS’s own incremental API).
How this fits the rest of the stack
The CMS pattern is also a hosting pattern. The team’s static site is a service on a platform, the platform runs the build and serves the content. The platform decision is also a cost decision — the build minutes, the bandwidth, the CDN, and the storage each show up as a line item, and the team’s mental model for the project cost is the sum of those numbers. The RunxBuild hosting calculator is the right place to model that — pick the build frequency, the bandwidth, the CDN, and the storage, and the calculator shows what the static site actually costs at the team’s actual usage.
Useful related references:
FAQ
What is a static site CMS?
A static site CMS is a content layer for a static site. The CMS authors the content, the build picks up the content, the static site is generated, the CDN serves the static site. The two patterns are git-based (content in the repo) and API-based (content in a service).
What is the difference between a git-based and an API-based CMS?
Git-based CMSs (Keystatic, Publii, Siteleaf, Decap) keep the content in the repo as Markdown or YAML, with edits triggering a rebuild. API-based CMSs (Sanity, Contentful, Strapi, Payload) keep the content in a service, with the build fetching the content at build time. The difference is where the content lives between builds.
When should I use a git-based CMS?
For a small team (one to three developers) that writes content and builds the site. The git-based pattern is simpler to set up, the content is in the repo, the team has a full version history.
When should I use an API-based CMS?
For a content team (separate from the developers) with multiple writers, a content calendar, and a need for hosted UI, real-time previews, and versioning. The API-based pattern is more scalable, but more complex to set up.
What is the right CMS for a marketing site?
API-based, with real-time preview. Sanity is the most popular pick in 2026, Contentful is the enterprise pick, Strapi is the open-source pick, Payload is the developer-first pick. The right answer depends on the team’s preferences.
Can I use a static site CMS with a deploy platform?
Yes. The standard pattern: the CMS is the source of truth, the build is triggered by a webhook from the CMS, the deploy is automatic. The team uses the deploy platform’s build pipeline and CDN, the CMS handles the content.
How do I handle real-time previews for a static site CMS?
The CMS provides a preview URL for each piece of content. The team configures the deploy platform to serve the preview URL. The marketing team sees the preview as they edit, the preview is a hosted environment.
What is the right CMS for a solo writer?
Publii or Siteleaf, both of which are designed for solo writers. The CMS runs on the writer’s machine, commits to a Git branch, the build picks up the changes.