CMS FOR
GITHUB PAGES
WITH md0
GitHub Pages already reads markdown from your repo. md0 adds the visual editor layer on top. Your content stays in GitHub. Builds trigger automatically on every save. Free for public repositories.
Background
How GitHub Pages Works
GitHub Pages is GitHub's free static hosting service. Push to the right branch and GitHub builds and serves your site. For most repositories, that means committing to main or gh-pages and GitHub handles the rest.
By default, GitHub Pages runs Jekyll on your repository automatically. You can also push pre-built HTML from any static site generator using GitHub Actions, which gives you more flexibility but requires a workflow file.
Content lives in your repo as files. That is the key detail. md0 connects to GitHub, reads those files, lets you edit them through a visual interface, and commits changes back. The GitHub Pages build then picks up the committed changes and rebuilds your site.
ZERO COST FOR PUBLIC REPOS
GitHub Pages is free for public repositories. md0 is also free for public repositories. The entire stack costs nothing.
GIT-NATIVE BY DESIGN
GitHub Pages was built around the idea that content lives in a Git repo. md0 operates on that same model. No adapter needed.
AUTO REBUILD ON SAVE
Every save in md0 commits to GitHub. GitHub Pages detects the push, triggers a build, and your updated content goes live within minutes.
NO REPO CHANGES NEEDED
md0 does not add admin files, config entries, or build scripts to your repo. Your existing GitHub Pages setup stays exactly as it is.
The Problem
Why GitHub Pages Sites Need a CMS
GitHub.com has a built-in file editor. You can click any markdown file, click the pencil icon, and edit it in the browser. This works for developers who know markdown syntax and understand where files live in the repo tree.
It does not work for the rest of the team. The GitHub file editor has no visual preview, no image upload workflow, no collection view that shows all your posts, and no concept of draft status. Writers who are not developers find navigating a file tree and writing raw YAML front matter uncomfortable.
GITHUB.COM EDITOR LIMITATIONS
- -No visual preview while writing. You edit raw markdown and have to commit to see how it renders.
- -No collection view. Finding a specific post means navigating folders in the file tree.
- -No image upload. Adding images requires a separate PR to upload the file then editing the markdown to reference it.
- -No draft support. Every saved edit immediately commits to the branch that GitHub Pages serves from.
- -Front matter editing is raw YAML. A misplaced colon or wrong indent breaks the file.
WHAT md0 ADDS
- -Visual markdown editor with live preview. Writers format content with toolbar buttons, not syntax.
- -Collection browser. All posts visible in a grid with title, date, and status at a glance.
- -Image upload. Drag and drop an image into the editor. md0 commits it to your repo and inserts the markdown reference.
- -Draft support. Set a post as draft in the front matter. It commits to your repo but Jekyll excludes it from the build output.
- -Front matter as form fields. Typed inputs replace raw YAML. Date pickers, dropdowns, toggles.
Setup Types
Two GitHub Pages Setups md0 Supports
Jekyll (Default GitHub Pages)
When you create a GitHub Pages site without a custom build workflow, GitHub runs Jekyll on your repo automatically. No configuration required on your end. Push a .md file and Jekyll builds an HTML page from it.
Content location
Blog posts in _posts/YYYY-MM-DD-title.md format. Static pages like about.md at the repo root or in _pages/.
Standard Jekyll front matter
--- layout: post title: "My Post Title" date: 2026-01-15 categories: [tutorial] tags: [github-pages, jekyll] published: true --- Post content goes here.
How md0 maps to it
md0 connects to the repo and creates a collection pointing at _posts/. It handles the date-prefixed filename format automatically. Fields like layout, title, date, categories, and permalink become typed form inputs.
Pre-Built Sites via GitHub Actions
Many teams use GitHub Pages with a GitHub Actions workflow to build a non-Jekyll site. Common choices are Next.js, Astro, Eleventy, and Hugo. The workflow runs on every push, builds the site, and deploys the output to GitHub Pages.
Content location
Wherever your SSG reads source files from. For Astro this might be src/content/blog/. For Hugo it is content/posts/. For Next.js with MDX it is often content/ or posts/.
How md0 maps to it
md0 edits the source markdown files. When you save, md0 commits to GitHub. The GitHub Actions workflow triggers on that push, rebuilds the site, and deploys the output. The build latency is 2 to 5 minutes depending on your workflow and site size.
Example workflow trigger
on:
push:
branches:
- main
jobs:
build-and-deploy:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- run: npm install && npm run build
- uses: actions/deploy-pages@v4Setup
How to Connect md0 to GitHub Pages
Your repo must be on GitHub
md0 connects to GitHub directly via OAuth and the GitHub API. Your GitHub Pages repository needs to be a GitHub-hosted repo, not a local git remote pointed at another host.
Log into cms.md0.io with GitHub OAuth
Go to cms.md0.io and click Sign in with GitHub. Authorize md0 and select which repositories to grant access to. You can limit access to your GitHub Pages repo specifically.
Select your GitHub Pages repository
After authentication, pick your repository from the list. Choose the branch GitHub Pages serves from. That is typically main, master, or gh-pages depending on your repository settings.
md0 detects your content directories
md0 scans the repo and lists every directory that contains markdown files. For a Jekyll site this surfaces _posts/ and _pages/. For other SSGs it shows whichever directories hold your source content.
Start editing
Create a collection in md0 pointing at your content directory, define your front matter fields, and open the editor. Each save commits to GitHub. GitHub Pages rebuilds on the push.
The Full Publish Flow
Things to Know
GitHub Pages-Specific Considerations
Public vs Private Repositories
GitHub Pages is free for public repositories. md0 is also free for public repositories. The entire stack has zero cost when your repo is public.
Private repositories require a paid GitHub plan for GitHub Pages hosting. md0 supports private repositories too, on paid md0 plans.
Branch Configuration
GitHub Pages serves content from one specific branch. Common options are main, master, or gh-pages. Check your repository settings under Pages to see which branch is configured.
When you set up md0, point it at that same branch. md0 commits to whichever branch you specify during setup.
Build Latency
There is always a gap between saving in md0 and seeing the change on your live site. The gap depends on your build type:
Plan for this when publishing time-sensitive content. The md0 editor shows the content immediately after saving. The live site catches up after the build finishes.
Custom Domains
md0 does not touch your custom domain setup. That is configured in your GitHub repository settings under the Pages section and in your domain's DNS records. md0 writes markdown files. It has no interaction with how GitHub Pages serves those files at your domain.
Jekyll Plugins
GitHub Pages runs Jekyll in safe mode, which blocks most third-party plugins. If your site uses plugins not on the GitHub Pages allowlist, you need to build with GitHub Actions and push the compiled output to your pages branch. md0 works the same way in both cases since it only writes source markdown files.
Features
What md0 Adds to the GitHub Pages Workflow
VISUAL MARKDOWN EDITOR
A WYSIWYG editor with formatting controls, heading levels, lists, links, and code blocks. Writers produce valid markdown without knowing markdown syntax. The output is identical to hand-written markdown files.
COLLECTION BROWSER
All posts visible in a grid. Title, date, and status at a glance. Searching and filtering by field value. No more navigating a GitHub file tree to find the post you want to edit.
IMAGE UPLOAD
Drag and drop images directly into the editor. md0 commits the image file to your repository and inserts the markdown image reference at the cursor position. Images go into whatever directory you configure for media.
DRAFT SUPPORT
Set published: false in the front matter and Jekyll excludes the post from your built site. The file is in the repo but not visible on the live site. Toggle it to publish when ready.
WORKS WITH STANDARD GIT WORKFLOWS
md0 commits to the same branch your team pushes to. Developers can still open PRs, run code review, and merge manually. md0 is just another committer on the branch.
FRONT MATTER AS FORM FIELDS
Define your Jekyll front matter fields in md0's schema builder. Date pickers, select dropdowns, boolean toggles, and text inputs replace hand-editing YAML. No more broken files from misplaced colons.
Keep Going
Related Guides
Using Jekyll with GitHub Pages
GitHub Pages runs Jekyll by default. If your site uses Jekyll, the dedicated Jekyll guide covers _posts/ naming conventions, custom collections, Liquid templates, and front matter field mapping in more detail.
Use md0 with Other Static Site Generators
md0 works with any SSG that reads markdown from a Git repo. If you deploy to GitHub Pages via Actions with a different SSG, these guides cover the specifics.
Comparing CMS Options?
- Migrating from Netlify CMS? See the comparison →
- Looking at all alternatives? All CMS alternatives →
CONNECT YOUR
GITHUB PAGES REPO
Free for public repositories. No Jekyll config changes. No files added to your repo. Set up in under five minutes.
CONNECT YOUR GITHUB PAGES REPO