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
mediawasn’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.