Working with Markdown files for content is super convenient.
As a developer, it is hard not to like it. Content is just files. You can search it,
diff it, review it in PRs, move it around, and now also let LLMs bulk-manage it.
Need to add metadata to 200 posts or migrate content from one structure to another?
Files are very easy to reason about.
But this does not scale that well for editors. Most marketing and content teams do not
want to open a repo, understand folder structure, run commands, and wait for deployments
just to change a page. They need drafts, preview, permissions, version history,
publishing flows, rollback, localization, and all the other CMS things that are still
very much needed.
So the idea behind MDCMS was pretty simple: why not both?
What MDCMS is
MDCMS is an open-source CMS that is database-backed and Markdown-first. The database
stays the source of truth, so you still get the workflow and safety of a real CMS.
But Markdown/MDX stays the working format, so developers and AI agents can still work
with raw files when that is the better tool for the job.
Brownfield adoption
The part that matters a lot for brownfield projects is adoption. A lot of teams already
have content sitting in their repository: blog posts, docs, landing pages, changelogs,
MDX pages, marketing content. The problem is not starting from zero. The problem is
turning what already exists into something editors can safely manage.
With MDCMS, the goal is that you can run:
mdcms init
And the CLI walks through the existing repository. It scans for .md and .mdx files,
groups content directories, detects locale patterns, parses frontmatter, infers content
types, generates mdcms.config.ts, syncs the schema, and pushes the discovered content
into the CMS as drafts.
That is the adoption path I care about most:
- not rewriting your content model from scratch;
- not migrating everything manually page by page;
- taking the Markdown/MDX content you already have, putting a real CMS workflow around it, and keeping the file-based workflow available when it is useful.
Day-to-day workflow
After that, the workflow looks roughly like this:
- Developers define or refine content types in code.
- Editors work in Studio.
- Content can be pulled locally as Markdown/MDX.
- Agents can update, validate, and restructure content in bulk.
- Changes go back through the CMS layer instead of bypassing it.
For example:
mdcms pull
# update content, metadata, links, translations, SEO fields
mdcms push --validate
The AI part
The interesting part is not "AI writes blog posts." The interesting part is giving AI
agents a safe way to work with content at scale, while still keeping validation,
permissions, history, and rollback.
For us, AI-native CMS means AI can work across multiple layers:
| Layer | What AI can help with |
|---|---|
| Content | Markdown/MDX, metadata, links, translations, SEO fields |
| Configuration | schemas, environments, locales, project settings |
| Codebase | adapters, components, validations, missing workflows |
| CMS actions | eventually controlled actions like users, roles, and permissions |
That is the part raw files alone do not solve. And it is also the part many CMS
dashboards are not great at, because the content is often trapped behind UI flows and
proprietary APIs.
Why we built it this way
MDCMS is our attempt to keep the useful parts of both models.
Files when files are better.
CMS when teams need a CMS.
It is open-source and still early, so contributions are very welcome. If this problem
sounds familiar, check the repo, try it on a small Markdown/MDX project, open an issue,
or pick something from the roadmap.
Website: https://www.mdcms.ai/
Top comments (0)