Skip to main content

Command Palette

Search for a command to run...

What is the best CMS for creating static websites?

How to choose a CMS for a static site: Git-based editors, headless APIs, plain Markdown, rebuild hooks, previews, hosting limits and cost.

Updated
•18 min read•View as Markdown

There is no single winner, because "static website" only describes how pages are served (prebuilt HTML on a CDN) and says nothing about who edits the words. If only developers touch the content, skip the CMS and keep Markdown files in Astro, Hugo or Eleventy. If non-developers need an editor and you want the content to stay in your Git repository, Decap CMS is the free, MIT-licensed starting point, with TinaCMS, Keystatic and CloudCannon as the more visual options. If a content team, several channels or a visual editor matter more than owning the files, use an API-based headless CMS such as Sanity or Storyblok and let a webhook trigger a rebuild. My default recommendation for a small marketing site with one or two non-technical editors is Astro plus a Git-based CMS, hosted on a free static tier.

Full disclosure: I work on VeloCMS, which appears below as one option among several. It is a hosted blog CMS, not a static site generator, and for this particular question it is rarely the best fit. I say why in its own section.

Last verified: 2026-10-06.

A note on method. Every price, limit and feature here was read from the vendor's own page on 2026-10-06, and anything I couldn't read is left out or marked. Prices are USD. Vendors change plans often, so treat this as a map and re-check the page before you pay for anything.

What does a static website actually need from a CMS?

A static site is built once, ahead of time, into plain files that any web server or CDN can hand out. Next.js describes its static export as "an HTML file per route" that can be hosted "on any web server that can serve HTML/CSS/JS static assets" (Next.js docs). Nothing runs on the server when a visitor arrives, so there is no database to patch and not much to attack.

The catch: files on a CDN can't be edited from a browser, so the real question is how content gets from an editor's head into the build. There are three honest answers. Content lives as files in your Git repository (Markdown, MDX, JSON, YAML), and a Git-based CMS gives editors a form that commits those files for them. Or content lives in a hosted service, and your build downloads it through an API on every run. Or there is no CMS, and the people who write are also the people who run git push.

Rebuild triggers, previews, images, hosting limits, cost and exit routes all follow from which of the three you pick, so decide that first.

Do I need a CMS at all, or are Markdown files enough?

For a developer-run site, files are enough. Four generators are worth knowing.

Astro positions itself as a framework for content-driven sites. Its content collections load Markdown, MDX, Markdoc, YAML, JSON or TOML through built-in glob() and file() loaders, validate entries against a Zod schema, and accept custom loaders when the data lives in a CMS. The docs add that build-time collections data "can be cached between builds" and suits tens of thousands of entries (Astro content collections), and the CMS guide lists more than forty headless systems it can read from (Astro CMS guide).

Hugo is a static site generator written in Go that "renders a complete site in seconds, often less" (Hugo intro). That is the vendor's claim, not a benchmark I ran. Eleventy needs a JavaScript runtime (its docs say "typically Node.js (version 18 or higher)") and treats Markdown, HTML, Liquid, Nunjucks and others as templates, with global data files and third-party APIs as inputs (Eleventy docs).

Next.js can also export statically with output: 'export', and Server Components then run during next build. The list of things you give up is longer than people expect: incremental static regeneration, Draft Mode, Server Actions, cookies, and the redirects, rewrites and headers config are unsupported, and next/image needs a custom loader.

My opinion: if your writers are comfortable with Git, a CMS is extra moving parts. Add one when a non-developer needs to publish without asking you.

Which Git-based CMS should I pick?

A Git-based CMS leaves content in the repository, so there's no content database, history comes free, and the exit route is "keep the files."

Decap CMS. Formerly Netlify CMS (renamed in February 2023), Decap calls itself "an open source content management system for your Git workflow." It's a single-page app at /admin, with the content model in a YAML config, sign-in through GitHub, GitLab, Bitbucket, Gitea, Azure or Git Gateway, and an editorial workflow. The license is MIT (Decap intro, backends). The catch is that GitHub sign-in outside Netlify needs an OAuth proxy; the docs suggest "an edge worker or serverless OAuth handler" and mention a hosted service, Decap Turbo, that runs it for you (I didn't look at its pricing). It's the plainest of the four, which for a small site is often a plus.

TinaCMS. "An open-source, Git-backed headless content management system," storing Markdown, MDX and JSON in your repo, with an /admin route, a GraphQL API and real-time visual editing for React-based sites (Tina docs). The code is Apache-2.0 (repo). You can use TinaCloud or self-host, which means wiring an auth provider, a database adapter (the docs mention MongoDB or Postgres) and a Git provider on a Node.js serverless platform (self-hosting). TinaCloud's free tier is "2 users, 2 roles, and community support"; Team is $24 per project per month ($290 a year). Editorial Workflow is not on Free or Team: it starts at Team Plus, $41 ($490 a year), and is also on Business, $249 ($2,990 a year), and Enterprise (pricing). Pricing is per project, so a freelancer with ten client sites should multiply first.

Keystatic. Thinkmill's tool makes "Markdown, JSON and YAML content in your codebase editable by humans," with a local mode, a GitHub mode, support for Next.js, Astro and Remix, and an optional Keystatic Cloud (Keystatic). It's MIT-licensed, but its README still said "Things are experimental at the moment" when I read it today (repo). That line may simply be old; check the project's recent activity before betting a client site on it. I found no Keystatic Cloud price.

CloudCannon. A commercial Git-based CMS with hosting bundled in. Standard is $55 a month ($49 billed annually) for 3 users and unlimited sites, with a 21-day trial; Team is $350 ($300 annual) for 15 users; add-ons include bandwidth at $15 per 100 GB (pricing). Editing, hosting and support from one vendor suits agencies handing sites to clients, and it is the only one of the four that costs real money from day one.

When does an API-based headless CMS make more sense?

A headless CMS keeps content in the vendor's database and serves it through an API, so your repository holds templates and no articles. It fits when several people edit at once, when content must reach more than one channel, when you need roles and review steps, or when editors expect a polished interface.

Sanity. Free is "\(0 forever" with up to 20 seats, 10k documents, 1M API CDN requests and 250k API requests a month, 100GB of assets and bandwidth, and two GROQ-powered webhooks. Growth is \)15 per seat per month with 25k documents, four webhooks, comments, tasks and scheduled drafts (pricing). Generous for a small site; the document cap and webhook count are the limits to watch.

Storyblok. The free Starter plan has 1 seat, 100GB traffic and 100k API requests a month, described as a "limited plan for testing and personal projects." Growth is $99 a month ($90.75 billed annually) with 5 seats; Growth Plus is \(349 with 15. A visual editor is included on every plan (pricing). That editor, where people click the page and change text in place, is the reason to choose it. The catch is the price step: \)99 for the first paid tier, against $15 per seat for Sanity's.

Payload. Open source, "the Next.js fullstack framework": write a config and get an admin panel, REST and GraphQL APIs, authentication, access control and live preview, backed by MongoDB or Postgres, and you can "deploy anywhere" (docs). For a static site that means running a server and database for the admin even though the public site is flat files. I couldn't load a Payload pricing page today, so I'm quoting none.

Contentful belongs on this list too, but its pricing and docs pages answered my requests with HTTP 429 and a bot check, so I'm not repeating figures I couldn't read. Cloudflare's docs do list it among the CMSs you can wire to a deploy hook.

With either hosted service, your content sits on their side of an API, the free tiers are bounded by their usage limits, and every build depends on their uptime.

How do edits turn into a rebuilt site?

A static site doesn't update when someone presses publish; something has to run the build again.

With a Git-based CMS the trigger is a commit. Tina's docs say "a commit is made back to your Git repository" on save, and your host builds from the commit. With an API CMS the trigger is a webhook. Cloudflare Pages gives each deploy hook "its own unique URL, which will receive HTTP POST requests in order to initiate new deployments," and Netlify's build hooks work the same way, with optional parameters such as clear_cache=true (Netlify build hooks). Cloudflare's docs warn that Contentful by default "will trigger a Pages deployment on all project activity, which may be a bit too frequent," so filter your webhook to publish events or every saved draft burns a build. Hook URLs "do not require additional authentication to be used," which makes them secrets (Cloudflare deploy hooks).

Those builds have budgets. Cloudflare Pages' free plan allows 500 builds a month, one at a time, with a 20-minute timeout (limits). Netlify's free plan has 300 credits a month as a hard limit, and a production deploy costs 15 (credits); by my arithmetic that's 20 deploys if nothing else spends credits, and bandwidth at 20 credits per GB draws from the same pool. Vercel's Hobby plan allows 100 deployments a day, and its deploy hooks fire up to 60 times an hour per project (limits). A blog publishing twice a week won't notice. A newsroom saving every few minutes will.

As for "incremental builds," none of these vendors promise that a changed article rebuilds alone. What you get are caches: Astro's persisted collections, Hugo's cache of processed images, Eleventy Image's disk cache. Next.js's incremental regeneration is exactly what a static export drops.

How do previews work on a static site?

A static build only knows what was published when it ran, so previews need a separate path. Decap lists real-time preview in its features, Tina offers it for React sites, and Storyblok's visual editor and Payload's live preview serve the same need on the API side. For "show this to the client," Cloudflare Pages lists an unlimited number of active preview deployments and Netlify's free plan lists unlimited deploy previews. With Next.js static export, Draft Mode is unsupported, so previews need a separate server-rendered deployment.

What happens to images?

The generators optimize at build time. Astro recommends keeping local images in src/ so it can "transform, optimize, and bundle them," while public/ files are copied "as-is, with no processing," with Sharp as the default service (Astro images). Hugo offers Resize, Fit, Fill, Crop and Filter, converts formats including WebP, and "caches the results" (Hugo). Eleventy's Image plugin outputs jpeg, png, webp, avif and svg with srcset markup and can save remote images locally (Eleventy Image).

The CMS adds a question: where do uploads live? With a Git-based tool they usually land in the repository, which is fine until you have thousands of photos, and the hosts have ceilings. Cloudflare Pages' free plan allows 20,000 files per site and 25 MiB per asset; GitHub Pages sites "may be no larger than 1 GB." My opinion: a photo-heavy site is a reason to keep media in a hosted service (Sanity and Storyblok both include asset bandwidth) and text in Git.

Where should a static site be hosted?

All four usual suspects serve flat files well; the fine print differs.

  • Cloudflare Pages: 500 builds a month on free, 20,000 files per site, 25 MiB per asset, 100 projects per account, up to 2,000 static redirects.
  • Netlify: Free is $0 with 300 credits and a hard limit; Personal $9 a month for 1,000 credits; Pro $20 for 3,000 (pricing).
  • GitHub Pages: 1 GB sites, a soft 100 GB monthly bandwidth limit, a soft 10 builds an hour (not applied with a custom Actions workflow), a 10-minute deploy timeout (limits).
  • Vercel: Hobby is "restricted to non-commercial personal use only," and commercial use includes "receiving payment to create, update, or host the site," so a freelancer's paid client site belongs on Pro (fair use).

GitHub Pages bars sites that mainly run commercial transactions, and Vercel Hobby is for non-commercial use only (I didn't check the commercial-use terms of the other two). GitHub's policy says Pages isn't for running "your online business, e-commerce site, or any other website that is primarily directed at either facilitating commercial transactions or providing commercial software as a service." If the site earns money for anyone involved, read the terms first.

What does it cost, and how locked in will I be?

The free options are free software (Astro, Hugo, Eleventy, Decap, Keystatic, Payload) or free tiers with a catch (Sanity's document cap, Storyblok's single seat, Tina's two users). Paid tiers start at $15 per seat (Sanity), $24 per project (Tina), $49 to $55 a month (CloudCannon) and $99 (Storyblok). The sticker is rarely the whole bill: seats multiply, per-project pricing multiplies, and wiring an OAuth proxy or a webhook costs time.

The Git-based tools are the easiest to leave. Decap and Keystatic are MIT, Tina is Apache-2.0, and the content is Markdown, MDX, JSON or YAML in your repo, so leaving means deleting a config and an /admin route. Hosted headless CMSs are a different story: content and schema sit on their side. I didn't verify Sanity's or Storyblok's export tooling today, so ask before committing how every document and asset comes out, in what format, and whether you can do it on a free plan.

Where does VeloCMS fit?

VeloCMS is a hosted CMS built around blogging, with a visual page builder, newsletter, membership and paywall, and a store. It runs as a Next.js app on a PocketBase backend, and the public site is served from VeloCMS's own infrastructure, so you don't get a folder of HTML to host yourself. For most people asking this question it's the wrong shape of tool.

It can still serve as an editing back end. The REST API is available from Pro, authenticated with a Bearer key from the admin settings, and the published OpenAPI document lists posts, members and webhooks (OpenAPI). Pro allows up to 10,000 API calls a day (help article). Webhooks must use HTTPS and cover events such as post.published, post.updated, post.unpublished, post.deleted and page.published; deliveries are signed and retried. In principle you could point one at a Cloudflare or Netlify hook and fetch posts at build time, but I haven't built that pipeline, so treat it as plausible, not proven.

The limits: the list endpoint returns summaries (title, slug, status, excerpt, tags, dates, image URL) without bodies, with a page size capped at 100, so a build needs one request per post. A 300-post site is about 303 calls per full build, so Pro's quota covers roughly thirty full rebuilds a day, shared with any other API client. And you'd pay for a theme, page builder and newsletter you aren't using. The export is a ZIP of JSONL files (one per collection, plus a media list with signed download links), a data archive rather than rendered HTML; I read that in the code and haven't run it on production.

From velocms.org/pricing: Pro $9 a month, Business $29, Agency $69, each with a 14-day trial that takes a card at signup. Pro includes a custom domain, the page builder, newsletter, membership, ecommerce, 5 GB of storage and 1 site. No free plan is listed, there's no self-hosted edition, it isn't Git-based, and its ecosystem is far smaller than WordPress's or Astro's.

Who is each option best for?

  • Astro, Hugo or Eleventy with Markdown: developers who write the content and want the cheapest, most portable setup.
  • Next.js static export: React teams who accept the unsupported-features list.
  • Decap CMS: small sites with a few non-technical editors and a developer who'll set up the OAuth proxy.
  • TinaCMS: React sites that want in-page editing while keeping content in Git.
  • Keystatic: developers wanting a typed, Git-backed editor for Astro or Next.js, after checking current activity.
  • CloudCannon: agencies wanting editing and hosting from one vendor.
  • Sanity: teams with developers and content for several channels.
  • Storyblok: marketing teams who want to edit on the page itself.
  • Payload: teams who want to own the whole stack, server and database included.
  • VeloCMS: people who want blog, newsletter, paid membership and a small store behind one hosted login and don't need static output.

When is each one the wrong choice?

  • Plain Markdown fails the moment a non-developer must publish unaided.
  • Decap is wrong if editors will balk at any friction; sign-in setup and YAML are real work.
  • TinaCMS is wrong for a freelancer with many small sites on per-project pricing, or for a non-React front end if you want live visual editing.
  • Keystatic is wrong if you need a vendor you can call, or if that experimental note is current.
  • CloudCannon is wrong for a hobby site with no budget.
  • Sanity and Storyblok are wrong when the content model is simple and you don't want every build to depend on a third party's API.
  • Payload is wrong when "static" was meant to reduce operations work.
  • VeloCMS is wrong if you need static files, Git history, self-hosting, a free plan or a big plugin ecosystem.
  • GitHub Pages is wrong for a site that mainly runs commercial transactions or sells software as a service, and Vercel Hobby is wrong for any commercial use, per their own terms above.

FAQ

Is a static site generator a CMS? No. Astro, Hugo and Eleventy build pages and give editors no login. Astro's docs treat a CMS as optional, since Markdown is supported natively (Astro CMS guide).

What's the cheapest setup? A generator, content in Git, Decap CMS (MIT) and a free static host: no license cost, and your time as the price. Check the host's commercial-use rules first.

Can non-technical editors really use a Git-based CMS? Yes. Decap works "using the GitHub, GitLab, or Bitbucket API," so editors see a form while it commits for them. The difficulty sits with whoever configures authentication, which TinaCloud, CloudCannon and Decap Turbo take on for a fee.

How do I make the site rebuild when content changes? Create a deploy hook (Cloudflare Pages) or build hook (Netlify) and call it from your CMS webhook, filtered to publish events (Cloudflare, Netlify).

Can I use Next.js for a static site? Yes, with output: 'export', minus incremental regeneration, Draft Mode, Server Actions and some config features (docs).

Can I use VeloCMS to feed a static site? Technically, through the REST API and webhooks from Pro upward, but it means one API call per post per full build and I haven't built it. If static output and Git are the goal, the tools above fit better (pricing).

Sources

All accessed 2026-10-06. Contentful's pages were rate-limited that day, so no Contentful figures are used.

Next.js static exports · Astro CMS guide · Astro content collections · Astro images · Hugo intro · Hugo image processing · Eleventy docs · Eleventy Image · Decap intro · Decap backends · Decap repo · Tina docs · Tina pricing · Tina self-hosting · Tina repo · Keystatic · Keystatic repo · CloudCannon pricing · Sanity pricing · Storyblok pricing · Payload docs · Cloudflare Pages limits · Cloudflare deploy hooks · Netlify pricing · Netlify credit-based plans · Netlify build hooks · GitHub Pages limits · Vercel limits · Vercel fair use · VeloCMS pricing · VeloCMS OpenAPI · VeloCMS pricing help article