md0 VS
TINA CMS
WHICH IS SIMPLER?
Both are Git-based content management tools. Both let editors work on markdown files without touching a terminal. But the setup experience is fundamentally different. md0 requires no config files at all. Tina CMS requires TypeScript schema definitions, a GraphQL content layer, and either Tina Cloud or a self-hosted server. This page walks through exactly where they differ and which one fits your workflow.
TRY md0 FREEBackground
What Tina CMS Is
Open-Source Visual Editor for React Sites
Tina CMS is an open-source Git-based content management system built around a visual editing experience. It was originally called TinaCMS and is developed by the team behind Forestry.io (which shut down in April 2023). Tina embeds a content editing sidebar directly into your site, so editors see their content rendered in the actual page layout while they type. This contextual editing approach is the main thing that sets Tina apart from most Git-based CMS options.
The .tina/ Directory and TypeScript Schema
Every Tina project requires a .tina/ directory at the root of your repository. Inside this directory lives a config.ts file where you define your content collections using TypeScript. Each collection specifies a folder path, a content format (markdown, JSON, MDX), and a list of fields with their types and validation rules. This configuration is the source of truth for Tina, and it must be written and maintained by hand. If you add a new field to your frontmatter, you update the schema. If you rename a folder, you update the schema. There is no auto-detection.
The GraphQL Content Layer
Tina generates a GraphQL API from your schema definitions. At build time, Tina reads your markdown files and builds a local GraphQL server that your frontend queries to fetch content. This means your site does not read markdown files directly anymore. Instead, it queries Tina's GraphQL layer. If you are building with Next.js, this requires using Tina's data-fetching helpers rather than a standard fs.readFileSync or MDX pipeline. Adopting Tina means adopting its query layer, not just its editor UI.
Tina Cloud for Non-Local Collaboration
Out of the box, Tina's visual editor only works when you run the site locally with npx tinacms dev. For non-technical editors who cannot run a local dev server, Tina offers Tina Cloud, a hosted service that connects to your GitHub repository and makes the editor available at a URL. Tina Cloud has a free tier capped at 2 users and 500 documents per collection. The starter plan for larger teams runs $29/month. Production-grade plans with higher limits are priced higher. If you need more than a handful of editors, factor Tina Cloud pricing into the comparison.
Side by Side
Feature Comparison
| Feature | md0 CMS | Tina CMS |
|---|---|---|
| Setup time | 2 minutes | 30 to 60 minutes |
| Config required | No config files | .tina/ schema files |
| GitHub native | Yes | Via GitHub (Tina Cloud) |
| Visual editor | Yes | Yes (contextual) |
| Free tier | Public repos (unlimited) | 2 users, 500 documents |
| Schema definition | Auto-detected | TypeScript (manual) |
| Self-hostable | N/A (SaaS) | Yes (Tina Cloud or self-host) |
| Framework support | Any SSG | React/Next.js preferred |
Where md0 Wins
Where md0 Is Simpler
1. No config to write or maintain
With md0, you connect your GitHub repository and the tool reads your existing file structure. Your collections are defined by folders. Your fields are detected from frontmatter in your existing markdown files. There is no config file to create, no TypeScript to write, and no schema to keep in sync with your actual content. When you add a new field to a blog post, md0 picks it up automatically. With Tina, you open your .tina/config.ts and add the field definition, then redeploy. Every schema change is a code change.
2. No GraphQL dependency in your build
Tina's GraphQL layer is central to how it works. Your Next.js or React site queries Tina's local or cloud GraphQL server to fetch content. This means your build pipeline now depends on a GraphQL server being available. If you want to fetch a blog post at build time, you write a GraphQL query using Tina's generated client, not a plain fs.readFile. md0 does not touch your build pipeline at all. It writes commits to GitHub. Your site reads files from GitHub. The two sides are independent.
3. Faster onboarding for non-technical editors
Getting a non-technical content editor into Tina requires either giving them access to a running dev environment or setting up Tina Cloud. Even with Tina Cloud configured, editors need to be invited, their permissions set, and the connection verified. With md0, you share a URL and the editor signs in with GitHub. If they already have GitHub access to the repo, they are editing in two minutes. There is no secondary service to configure for access.
4. Works with any static site generator
Tina is built primarily for React-based frameworks. Its contextual editing sidebar requires your frontend to render in a browser that Tina can inject its UI into. Hugo, Jekyll, Eleventy, and other non-React SSGs are not well supported. md0 is framework-agnostic. It writes markdown files to your GitHub repo. Whatever reads those files, whether that is Next.js, Astro, Hugo, or any other tool, keeps working unchanged.
5. No migration required from existing markdown
If you have an existing markdown-based site, adopting md0 is a connection, not a migration. Your files stay where they are. md0 reads them and presents an editing UI on top. With Tina, you need to add the .tina/ directory, define your schema, install the Tina package, run the dev server with Tina enabled, and potentially restructure frontmatter to match Tina's expected field types. For sites with hundreds of existing posts, this is a real undertaking.
Honest Assessment
Where Tina Has an Edge
1. Contextual in-page editing
Tina's signature feature is its sidebar editor that renders alongside the actual page. When an editor changes a heading, they see the heading update live on the rendered page beside them. This is a genuinely useful experience for content teams who want to verify layout while they write. md0 uses a separate editing interface, not an embedded sidebar. If contextual in-page editing is a hard requirement for your team, Tina delivers it in a way md0 does not currently match.
2. Complex content relationships
Tina's GraphQL layer and typed schema system allow you to define references between content types. A blog post can reference an author document. A product page can reference a category. These relationships are queryable via GraphQL at build time. If your content model has interconnected documents that need to be traversed programmatically, Tina's architecture handles this more explicitly than a flat folder structure.
3. Self-hosting option
Tina can be self-hosted using an open-source backend. If your organization has a policy against using third-party SaaS tools for content editing, Tina gives you a path to run everything on your own infrastructure. md0 is a hosted SaaS product. It is not available as a self-hosted option today.
Switching
Moving from Tina to md0
If you are on Tina and want to switch, the process is straightforward. Your content files are the key asset, and they stay exactly where they are. Only the tooling on top changes.
Your markdown files need no changes
Tina reads from your existing markdown files and writes back to them in standard format. md0 reads the same files. Your frontmatter structure, your content folders, your file names, all of it carries over without any transformation needed. No migration scripts, no format conversion.
Connect your GitHub repo to md0
Go to cms.md0.io and sign in with GitHub. Grant access to the repository. md0 reads your directory structure and detects your content folders. You can verify that your collections appear and that existing posts render correctly in the editor.
Remove the .tina/ directory from your repo
Once md0 is working and your editors have been onboarded, you can remove the .tina/ directory, uninstall the Tina package from your dependencies, and remove any Tina-specific GraphQL queries from your data-fetching layer. If you adopted Tina's query layer throughout your site, this step involves replacing those queries with your framework's native file-reading approach.
Rebuild your data-fetching if needed
Sites that went deep into Tina's client-generated GraphQL queries need to swap those out for direct file reads or your framework's standard MDX/markdown pipeline. For Next.js, this typically means returning to fs.readdirSync and gray-matter for frontmatter parsing. The effort depends on how thoroughly you adopted Tina's query approach.
Also See
- Ready to switch? TinaCMS migration guide
- Coming from Forestry (which Tina replaced)? Forestry.io alternative | Compare all CMS alternatives
NO CONFIG. JUST EDIT.
Connect your GitHub repo and start editing markdown in under two minutes. No TypeScript schemas. No GraphQL. Free for public repositories.
GET STARTED FREE