TinaCMS: A Headless CMS That Stores Content in Your GitHub Repo

Who Needs a CMS That Lives in Git

TinaCMS solves a specific content problem: teams that want the benefits of a headless CMS but refuse to give up Git as the source of truth. Most headless CMS products push content into a proprietary database, which means content lives outside your codebase. TinaCMS flips that. Your Markdown, MDX, JSON, and YAML files stay in your GitHub repository. The project targets developers who build statically generated or server-side rendered pages and want content editors to work without touching code. The README explicitly positions live preview as a way to make editing Markdown intuitive for less-technical people. The core audience is a developer-led team that already uses Git and wants to keep content review, versioning, and history in the same place as code.

The GraphQL API and Content References

TinaCMS provides a GraphQL API that sits on top of your content files. The README gives a concrete example: you can query a post and access the author's first name with `post.author.firstName`. This implies a data model where documents can reference each other, and the API resolves those references for you. The API supports both statically generated and server-side rendered pages, which means it works with frameworks like Next.js or Gatsby, though the README does not name specific ones. The mechanism is not fully detailed in the README, but the presence of a GraphQL layer suggests a schema is generated from your content structure. This is a different approach from a CMS that requires you to define content types in a web UI. Here, the content files themselves define the shape, and the GraphQL API gives you a typed query surface.

Getting Started with create-tina-app

The quickest way to try TinaCMS is to run `npx create-tina-app@latest` in your terminal. This command scaffolds a starter site, according to the README. There is also a demo site hosted on TinaCloud at `https://app.tina.io/quickstart`. The README does not list the exact steps after scaffolding, but the implication is that you get a local development environment with TinaCMS configured. You will likely need to set up authentication for the editor, but the README does not specify how. The absence of detailed setup instructions in the README means you should consult the official documentation at `https://tina.io/docs/` for framework-specific integration. For a first run, the starter app is the fastest path, and it is designed to show the core features without manual configuration.

Live Preview Is Optional, and That Matters

A key design choice is that live preview is optional and opt-in. This is not a CMS that forces a visual editor on every user. The README states that live preview makes editing Markdown files intuitive for less-technical people, but it is not the default experience. This is a trade-off. On one hand, it keeps the core CMS lightweight and developer-friendly, since you can use TinaCMS purely as a GraphQL-backed content API. On the other hand, if your editors need a visual editing experience, you have to configure it explicitly. The opt-in nature means you can start with a simple Markdown workflow and add visual editing later, but it also means the initial setup may not include the preview environment. That is worth checking before you promise editors a WYSIWYG experience.

Licensing and Community Structure

TinaCMS is released under the Apache-2.0 license, which is permissive for commercial use. The repository is written in TypeScript, and the primary package is `tinacms`. There are also related packages like `tinacms-authjs` and `next-tinacms-s3`, which suggest integrations with Auth.js and S3 storage for Next.js projects. The maintainers include a mix of full-time and part-time contributors, many from SSW, a software consultancy. The README mentions a public roadmap and a community Discord, so there is an active development process. The license is a positive signal for adoption, but you should understand that the project is closely tied to TinaCloud, a commercial service. The README links to TinaCloud for the demo, which means the open-source core may have a commercial counterpart. That is not a problem, but it is a factor to evaluate.

Where TinaCMS Falls Short

The biggest limitation is that TinaCMS is tightly coupled to Git and GitHub. If your team does not use GitHub, or if your editors are not comfortable with the concept of commits and pull requests, the workflow will be a barrier. The README specifically says content is stored in your own GitHub repo, so you cannot use it with GitLab or Bitbucket without additional tooling, if at all. Another limitation is that the README does not describe how the GraphQL API is deployed or scaled. If you have a high-traffic site, you need to understand the performance characteristics of the API, but the README is silent on that. The live preview being opt-in also means you may need to invest time in configuration to get it working. For a simple blog with a single editor, TinaCMS might be overkill compared to plain Markdown files. For a large organization with many editors, the Git-based workflow could be a bottleneck.

Alternatives: Git-Based vs. Database-Backed CMS

The closest alternative to TinaCMS is another Git-based CMS like Forestry (now discontinued) or Netlify CMS, which also store content in a Git repository. Netlify CMS, for example, uses a similar approach but with a different editing interface and no GraphQL API by default. The key difference is that TinaCMS provides a GraphQL layer and a more structured content model, while Netlify CMS is more file-based and simpler. On the other side, you have database-backed headless CMS platforms like Contentful or Strapi, which store content in a database and offer a REST or GraphQL API. The difference is fundamental: with a database CMS, content is not in your repo, so you lose Git history and versioning. TinaCMS is the right choice if you want Git as the source of truth, but a database CMS is better if you need a more flexible content model or a fully managed service. The trade-off is between developer control and editorial ease.

Editorial conclusion

Adopt TinaCMS if you are a developer or team that wants content stored in Git with a GraphQL query layer and an optional visual editing experience for non-technical editors. Do not adopt it if you need a fully managed, database-backed CMS or if your editors cannot work with a Git-based workflow. Before committing, verify the live preview setup for your framework, the deployment model for the GraphQL API, and the licensing terms of the Apache-2.0 license.

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes