Pages CMS is an open-source, MIT-licensed editor for content that lives in a GitHub repository. You add a .pages.yml file that describes your content and media folders, and editors get forms to change them. Each save is a commit. It is one of the actively developed tools in our Git-based CMS comparison.
What is its status in October 2026?
Active. The repository, now at hunvreus/pagescms, had a commit on 16 October 2026 and has about 4,100 stars. The latest release, v2.1.8, came out on 8 June 2026. Version 2 is a rewrite that needs a database for the self-hosted setup, so older guides for v1 no longer apply.
How do you run it?
Two ways. The simplest is the hosted app at app.pagescms.org, where you sign in with GitHub and open a repository. Or you self-host: that takes PostgreSQL, a GitHub App you create yourself, and a set of environment variables. Self-hosting is a real piece of infrastructure, not a static file.
Which site generators does it work with?
Any, because it only edits files in the repository. The maintainers name Jekyll, Hugo, Next.js, Astro and VuePress. The config supports fields such as text, rich text, image, date, reference and file, so a typed content model is possible. We found no live preview of the rendered page in the docs.
Who does it suit?
Small sites, blogs, docs and landing pages whose code is on GitHub and whose editors can use a GitHub login or be added as collaborators. It is a good quick win for a client who currently edits Markdown by hand.
Where are the limits?
- GitHub only: GitLab, Bitbucket and self-hosted Git are not supported.
- Roles: Access follows GitHub collaborators, so per-field or per-locale permissions do not exist.
- Preview: No live preview of the rendered page.
- Scale: It reads files through the GitHub API, which suits hundreds of entries rather than many thousands.
- Media: Images go into the repository, which grows over time unless you move them elsewhere.
When would we use something else?
If your code is on GitLab or you need an editorial workflow with pull requests, we would use Decap or Sveltia CMS. For visual on-page editing on a React site, Tina. For client handover with their own accounts, CloudCannon. For relational content or several front ends, a full headless CMS.
What can we do for a team using Pages CMS?
- Write the
.pages.ymlfor your real content model, with sensible field validation. - Self-host the app with its database and GitHub App, and keep it upgraded.
- Wire up builds and preview deployments on Hugo or another Jamstack stack.
- Migrate to a fuller CMS when you outgrow it. Content is already files, so the move is mostly schema work and redirects.
