ADD VISUAL EDITING TO YOUR
MARKDOWN FILES
Already editing markdown in VS Code? md0 adds a visual editor for your non-technical collaborators, without touching your file structure, frontmatter, or build process.
ADD md0 CMSHOW MOST DEVELOPERS EDIT MARKDOWN TODAY
The standard workflow is straightforward: open VS Code (or Vim, or any editor), edit a .md file, run git commit, push to GitHub, and wait for the static site generator to rebuild. For a developer, this is second nature.
It works well when every person touching the content is comfortable with Git and code editors. That covers most engineering teams. It breaks down the moment a non-technical teammate needs to update something: a writer who needs to publish a new post, a product manager who wants to correct copy on a landing page, a client who hired you to build their site and now needs to add blog content without scheduling a call.
Asking a non-developer to clone a repo, install Node, open a terminal, and run git push just to fix a typo is not a realistic expectation. But routing every content change through a developer turns into a bottleneck fast.
md0 solves this without changing anything about how the content is stored or how your build works.
WHAT md0 ADDS (WITHOUT CHANGING ANYTHING)
md0 is an interface layer, not a data format change. Your markdown files stay markdown files. Your frontmatter stays frontmatter. Your Git history stays intact. What md0 adds is a web-based visual editor that reads and writes those same files through the GitHub API.
When a collaborator opens the editor at cms.md0.io, they see a clean WYSIWYG editing surface (bold, italic, headings, links, images, lists, code blocks) with no markdown syntax visible. The frontmatter fields they need to fill in (title, date, tags, any custom fields) appear as labeled form inputs: a text box for the title, a date picker for the publish date, a toggle for a boolean field.
When they hit Save, md0 writes the updated file back to your GitHub repository as a normal Git commit. The commit message, author, and file path all look exactly the same as a commit made from VS Code. Your existing build pipeline (GitHub Actions, Netlify, Vercel, or anything that watches your repo) picks up the change and rebuilds as usual.
Your collaborator sees
- → Visual WYSIWYG editor (no markdown syntax)
- → Form inputs for frontmatter fields
- → A Save button that commits and publishes
- → A file browser for their content folder
What stays the same
- → Your .md file structure
- → Your frontmatter format
- → Your Git history
- → Your build process
WHO THIS IS FOR
This setup is a good fit in a few recurring situations. A developer who built a blog for a client: the site is on GitHub, content is markdown files, and the client needs to add posts or update the homepage copy without scheduling a call with the developer each time.
A documentation team where engineers write most of the content but a technical writer needs to review drafts, correct phrasing, and publish updates without filing a PR. The technical writer knows what they want to say and should not need to learn Git to say it.
A marketing team that maintains a static site and needs to update landing page copy before a product launch without routing a text change through an engineer.
More broadly: anyone whose content collaborators are comfortable with Google Docs-style editing but not comfortable with command-line Git. md0 is not for teams that want to move away from markdown. It is specifically for teams that want to keep markdown and just need a better editing interface for the non-developers.
SETUP (NO MIGRATION REQUIRED)
This is not a migration. There is nothing to move. Your files stay where they are. The setup is a one-time configuration that tells md0 where to find your content and what your frontmatter fields look like.
Add your collaborator to the repo
Create a GitHub account for your collaborator if they do not have one, and add them as a collaborator on your repository with read/write access.
Sign in to cms.md0.io
Go to cms.md0.io and sign in with your GitHub account via GitHub OAuth. No password to manage. GitHub handles authentication.
Connect your repository
Select your repository from the GitHub repos your account can access. md0 uses GitHub OAuth to read and write files through the GitHub API.
Create a collection
Set the folder path where your content files live (e.g., content/blog), the file pattern (e.g., **/*.md), and define the schema fields matching your frontmatter keys.
Share the URL
Share cms.md0.io with your collaborator. They sign in with their GitHub account, see the content folder you set up, and start editing.
Total setup time: about 5 minutes. No new infrastructure, no build changes, no config files added to the repo.
HOW EDITING WORKS
When your collaborator opens a file in md0, the editor parses the frontmatter and renders it as a form at the top of the page. If the file has a title field, they see a text input labeled "Title". A date field becomes a date picker. A published boolean becomes a toggle.
Below the frontmatter form, the body content opens in a WYSIWYG editor. They can bold text, add headings, insert links, upload images, add code blocks, and format lists, all without writing a single character of markdown syntax. The underlying file is still markdown; the editor is just a visual layer on top of it.
When they hit Save, md0 commits the updated file to your repository. If you have configured md0 to write directly to your main branch, the commit goes in immediately and your build pipeline triggers. If you prefer a review step, configure md0 to write to a named branch instead. Every save opens or updates a pull request, and you merge it when you are ready.
Your existing CI/CD setup handles the rest. If you have a GitHub Actions workflow that deploys on push to main, it will run exactly as it always has. If Netlify or Vercel is watching your repo, they pick up the new commit and rebuild. md0 is not in the deploy path. It just puts a commit in your repo.
SCHEMA DEFINITION
The one real setup step is telling md0 about your frontmatter fields. Go to the collection settings in md0 and add field definitions that match the keys in your frontmatter. The field type determines which input control appears in the editor.
For a typical blog post with title: string, date: date, and tags: string[]: add a Text field named "title", a Date field named "date", and an Array field named "tags". That is the entire schema for that content type.
If a frontmatter key is not in your schema definition, md0 reads and writes it transparently. It preserves the value in the file but does not show it as an input. Nothing in your file is lost or modified by the CMS. You can add new schema fields at any time without touching any content files.
Example: blog post schema in md0
Collection: Blog Posts Folder: content/blog Pattern: **/*.md Fields: title → Text field date → Date field excerpt → Textarea field tags → Array field published → Boolean field
KEEPING YOUR DEVELOPER WORKFLOW
Adding md0 does not change anything about how you work as a developer. You can still open the content folder in VS Code, edit files directly, and commit them the same way you always have. Git commits from md0 and Git commits from your editor look identical in the repository history. There is no lock-in, no proprietary file format, and no dependency on md0 being available for your build to work.
If you want a review step before content changes go live, configure md0 to write to a branch (for example, cms/updates) instead of directly to main. Every save your collaborator makes opens or updates a pull request. You review it, merge it, and the site rebuilds. This gives you the same PR-based review workflow you use for code changes, applied to content.
The file format is unchanged. If you decide md0 is not the right fit at some point, you stop using it and your content files are exactly as they were: plain markdown with frontmatter, fully readable by any tool, any SSG, any future CMS you choose.
HOW md0 COMPARES
There are a few other tools that add a CMS layer on top of Git-based markdown. Here is an honest comparison of what each approach requires and what it gives you.
| Approach | Config in repo | Non-dev friendly | Git history |
|---|---|---|---|
| Direct file editing (VS Code) | No | No | Yes |
| Netlify CMS / Decap CMS | Yes (/admin folder) | Yes | Yes |
| TinaCMS | Yes (tina/ folder) | Partial | Yes |
| md0 CMS | No | Yes | Yes |
The main practical difference: md0 does not require adding any configuration files to your repository. The schema is stored in md0 itself, not in your codebase.