Show HN: Pages CMS – A CMS for GitHub

A new open source project, Pages CMS, offers a GitHub-based content management system that sits on top of existing static site generators like Jekyll, Hugo, Eleventy, Astro, and Next.js, aiming to recreate a WordPress-style editing experience without locking users into a specific hosting provider. Commenters praise its simpler UX compared to tools like Decap/Netlify CMS and TinaCMS, appreciate easy self-hosting on services like Cloudflare Pages, and highlight features such as multi-repo support, configurable content types, and rich-text editing. Key challenges and roadmap items include better onboarding via auto-generated configs, improved MDX and HTML collection support, media storage options (S3/R2), and broader Git provider compatibility beyond GitHub.

Overall Reception & Target Use Cases

  • Many commenters are enthusiastic, especially those missing Forestry or dissatisfied with Decap/Netlify CMS and Tina.
  • Popular use cases: blogs and documentation sites built with Hugo, Jekyll, Eleventy, Astro, Next.js and other SSGs, making it easier for non-technical users to edit content in Git repos.
  • Some see it as exactly the “thin CMS layer on top of GitHub” they’d been wanting.

Setup, Configuration & UX

  • People praise the UI/UX and report getting it running on Cloudflare in minutes.
  • Others note onboarding isn’t fully “click-and-done” yet; figuring out page configuration and content schemas still takes effort.
  • Several ask for a configuration wizard that infers content types and fields from existing folders and front matter; the author indicates this is planned.

Content Formats & SSG Integration

  • Works well with Markdown front matter for common SSGs.
  • Current limitations: MDX support is partial (single files via “code” mode OK; collections and rich editor not yet solid).
  • Some Jekyll users are unclear how “body” is mapped when it’s only implicit after front matter.
  • There’s demand for better support of HTML and MDX collections, date-from-filename for Jekyll, and flat YAML “collections” instead of one-file-per-entry.

Authentication, Hosting & Git Providers

  • Only GitHub is supported now; code can be hosted anywhere (e.g., Cloudflare Pages), CMS is purely frontend plus small auth functions.
  • GitHub OAuth requires broad repo access; commenters are uneasy but fine-grained personal access tokens and self-hosting mitigate this.
  • Some strongly want support for GitLab, Bitbucket, Gitea, or a generic Git API; generic Git is currently out of scope.

Media Handling & Storage

  • Rich-text editor initially broke when media wasn’t configured; hotfixes were shipped quickly.
  • Users request S3/R2 and third‑party upload services; S3/R2 support is being actively worked on.
  • Media can be colocated with posts by configuring filters on file extensions.

Comparisons, Pricing & Philosophy

  • Compared frequently with Decap, Static CMS, Keystatic, Tina, Statamic, Lektor, Publii, and CloudCannon.
  • Main differentiators discussed: simpler UX than Decap, runs fully online unlike Keystatic desktop mode, and doesn’t require hosting with a specific provider.
  • The project is MIT-licensed and self-hostable; an eventual “Pro” tier for advanced features is mentioned, raising some skepticism about long-term free status.