Static Site CMS Options for Jekyll and Hugo
You love your static site but someone needs an admin UI. Here are the git-based CMS options for Jekyll, Hugo and Astro, what each actually gives you, and the honest limits of the whole approach.
A static site CMS is an editing interface that commits changes to your site repository, so a build runs and the static site regenerates. The main options are Decap CMS, Sveltia CMS, Tina CMS and Keystatic, all open source, plus commercial CloudCannon and the desktop app Publii.
Static sites win on speed, cost and security, and then run into one very human problem: not everyone who needs to publish wants to touch a terminal. Jekyll and Hugo expect you to write Markdown in a repository and push. That is fine for the developer who set it up, and a wall for the colleague who just wants to fix a typo. A static site CMS is the usual answer. Here is how the category actually works, what the real options are, and when it is the wrong tool.
What a static site CMS actually is
Almost every tool in this category is git-based. There is no database. The CMS is an editing interface that reads your content files, lets someone edit them in a browser, and then writes the change back as a commit to your repository. Your existing build pipeline notices the commit, runs Jekyll or Hugo, and deploys the regenerated site.
That design is the whole appeal. Your content stays as plain files in version control, your site stays static, and you gain an admin screen without adopting a database or a running application. The trade-offs all follow from the same design, and we will come to them.
The main options
| Tool | Licence | How it runs | Notes |
|---|---|---|---|
| Decap CMS | Open source (MIT) | Self-hosted admin page in your own site | The long-standing default, formerly Netlify CMS. Config-file driven. |
| Sveltia CMS | Open source | Self-hosted, drop-in for Decap | A modern rewrite aiming at Decap compatibility with a faster UI. |
| Tina CMS | Open source core | Self-hosted, or their hosted backend | Visual, in-context editing. The optional cloud tier is paid. |
| Keystatic | Open source | Self-hosted, runs beside your site | Git-based, with a typed schema for your content fields. |
| CloudCannon | Commercial | Hosted service | Long-standing Jekyll focus and visual editing. Paid. |
| Publii | Open source (GPL-3.0) | Desktop application | Not git-based: you edit locally and it uploads a generated static site. |
| GitHub or GitLab web editor | Free | Already there | No setup at all. Ugly, but genuinely enough for occasional typo fixes. |
Start at the bottom of that table, not the top. If the real requirement is "someone edits a paragraph twice a month", the web editor built into your git host already does it, and adding a CMS is work you do not need.
The honest limits of the git-based approach
These tools are good, and the category has real constraints that no amount of polish removes:
- Publishing is not instant. Saving triggers a commit, then a build, then a deploy. Expect anywhere from tens of seconds to several minutes before a change is live. Editors used to WordPress find this genuinely disorienting.
- Git concepts leak through. Two people editing the same file produce a merge conflict, and the CMS usually cannot resolve it for them.
- Media is awkward. Images committed to the repository make it grow forever. Most teams end up adding external media storage, which is one more moving part.
- Preview is approximate. Because the real page only exists after a build, what the editor sees is a rendering of the editor's guess, not the page.
- Dynamic features stay missing. Comments, search, scheduled publishing and per-author permissions are not things a static site CMS adds. They still need a service somewhere.
A git-based CMS gives a static site an editor. It does not give it a database, and most of the frustration comes from expecting otherwise.
When a static site CMS is the wrong answer
If your list of requirements has grown to include scheduled posts, real multi-author workflow, comments, a search index and instant publishing, you are no longer describing a static site with an editor. You are describing a CMS, and bolting four services onto Jekyll to simulate one is usually more work than running one application. We compare the two architectures directly in static site generator vs CMS.
To be straightforward about where we sit: Inkwell is not a static site CMS. It is a database-backed, self-hosted blog engine on .NET, so it belongs to the other side of that comparison. If your static site has quietly grown into a publication and the tooling is fighting you, it is worth reading the wider field in our guide to self-hosted blogging platforms, or the documentation if the .NET option is relevant. If you are happy with static and only needed an editor, take one from the table above and ignore us entirely.
Frequently asked questions
What is a static site CMS?
It is an editing interface for a site built by a static site generator. Most are git-based: instead of writing to a database, the CMS commits your edit to the site repository, which triggers a build that regenerates and deploys the static files.
Which CMS works with Jekyll?
Decap CMS, Sveltia CMS, Tina CMS and Keystatic all work with Jekyll and are open source, and the commercial CloudCannon has a long-standing Jekyll focus. For occasional edits, the GitHub or GitLab web editor needs no setup at all.
Is a static site CMS free?
The open-source ones are free to licence and you host the admin interface yourself, usually alongside the site at no extra cost. Hosted services such as CloudCannon, and the optional cloud tiers of otherwise open-source tools, are paid.
Why is my static site CMS slow to publish?
Because saving does not publish. It commits to your repository, which starts a build, which then deploys. The delay is your build and deploy pipeline, not the editor, so it ranges from tens of seconds to several minutes depending on site size.
Ready to host your own blog?
Inkwell is free, open-source, and self-hosted — your content, your server, your rules. Deploy in minutes on .NET 10.