Git-based CMS platforms promise an appealing compromise: developers keep content in the repository, while editors get something better than opening Markdown files in GitHub.
That description fits TinaCMS, Keystatic, and Decap CMS, but it hides how different the three products actually are.
TinaCMS increasingly behaves like a modern visual CMS built on top of Git. Keystatic treats content management as another typed, code-defined part of the application. Decap CMS takes the more traditional approach of putting an admin interface in front of files and Git-provider APIs.
All three can be good choices. The important question is not which one has the longest feature list. It is which publishing model matches your developers, editors, framework, and deployment workflow.
This comparison looks at TinaCMS vs Keystatic vs Decap CMS from that perspective, with particular attention to Astro projects, structured content, visual editing, Git workflows, deployment, pricing, and long-term maintainability.
TinaCMS vs Keystatic vs Decap CMS: The Short Answer
| CMS | Best fit | Main tradeoff |
|---|---|---|
| TinaCMS | Teams that want Git-backed content with strong visual and contextual editing | More CMS infrastructure and workflow complexity |
| Keystatic | Developers who want structured content management to feel like part of the codebase | Less emphasis on full-page contextual visual editing |
| Decap CMS | Sites that need a straightforward, framework-agnostic admin UI over Git content | Developer and editing experience can feel more traditional and configuration-driven |
If contextual editing is a major requirement, TinaCMS has the clearest advantage. Its current Astro integration supports React-free visual editing with Astro-specific editable regions and field mapping.
If you want a TypeScript-first content schema that lives close to your application code, Keystatic is especially attractive. It can store content locally or on GitHub, supports Astro directly, and can work with Markdown, MDX, Markdoc, JSON, and YAML-oriented structures.
If your main requirement is simply to give editors a web interface for repository content, Decap CMS remains the most conventional option. It works independently of a specific frontend framework and communicates with Git hosting services through configurable backends.
What Does “Git-Based CMS” Actually Mean?
A database-first headless CMS normally stores canonical content in an external service. Your Astro, Next.js, Nuxt, or other frontend retrieves that content using an API.
A Git-based CMS starts from a different assumption. Content remains in files that can be committed to a repository. Those files might be Markdown articles, MDX documents, JSON configuration, YAML data, or another format the application can read.
That gives Git-based content several useful properties. Developers can inspect diffs, roll back changes, create branches, review pull requests, and edit files without the CMS interface. Moving away from the CMS can also be easier because the underlying content has not necessarily been trapped inside a proprietary database.
But Git also becomes part of the publishing architecture. A save might generate a commit. A draft might become a branch. Publishing may require a merge. A static site may need another deployment before an edit becomes public.
TinaCMS, Keystatic, and Decap CMS all operate within that broad model, but each tries to hide—or expose—different parts of Git.
TinaCMS: Git Content With a Visual CMS Layer
TinaCMS describes itself as an open-source, Git-backed headless CMS. Markdown, MDX, and JSON files can remain in Git while Tina adds schemas, an editor, generated content APIs, media management, and visual editing.
That last capability is what most clearly separates Tina from the other two products in this comparison.
Tina is not merely trying to provide a form where an editor changes a field called “headline.” It can connect that field to the headline visible on the rendered page, allowing an editor to work in the context of the website.
For Astro specifically, Tina now has an Astro-native visual editing architecture. The current integration uses @tinacms/astro, editable Tina islands, metadata-aware requests, and field markers without requiring React inside the Astro page tree.
This makes Tina especially interesting for marketing sites, documentation, product sites, and publications where developers control the component system but non-technical people regularly update the content.
Where TinaCMS is strongest
- Contextual and visual editing
- Structured schemas
- Git-backed Markdown and MDX
- Reusable component and block workflows
- Developer-controlled frontend architecture
- Branch-based editorial workflows on applicable plans
Where TinaCMS adds complexity
The editing experience comes with more infrastructure than a simple admin page. Serious implementations can involve generated clients, schema configuration, visual-editing integration, production authentication, content APIs, editable regions, environment variables, and a Git-connected backend.
If one developer is the only person who edits a five-page website, most of that machinery may not be justified.
Keystatic: A CMS That Feels Like Part of the Codebase
Keystatic has a noticeably different personality.
Its core proposition is to make Markdown, JSON, and YAML-oriented content in a codebase editable through a CMS interface while preserving a developer-centric architecture. Keystatic offers a TypeScript configuration API, local filesystem mode, GitHub mode, and Keystatic Cloud.
A typical Keystatic project defines collections and singletons directly in TypeScript. The application can then read that content through Keystatic’s Reader API or, in an Astro project, continue using Astro’s own Content Collections where that makes more sense. Keystatic’s official Astro guide explicitly demonstrates the latter approach.
This makes Keystatic attractive when the developer wants content modeling to feel like another part of the application’s source code rather than a separate content platform.
It is also stronger than a basic “form over Markdown” description suggests. Keystatic supports MDX and Markdoc content components, allowing developers to create structured blocks inside rich content. Its content-component system supports multiple component patterns and custom previews inside the editor.
Where Keystatic is strongest
- TypeScript-first content modeling
- Strong developer ergonomics
- Local filesystem editing
- GitHub and cloud storage modes
- MDX and Markdoc content components
- Clean fit with application-owned content
- Good Astro integration
What about visual editing?
Keystatic supports preview URLs for collections and has documented workflows for real-time previews, including a Next.js Draft Mode recipe. But that is not the same architecture as Tina’s click-to-edit contextual page editing.
Keystatic’s rich-content components can themselves have useful editor previews, and developers can build sophisticated block-authoring experiences. But if the requirement is “click this heading on my actual Astro page and edit the CMS field responsible for it,” Tina currently provides the more purpose-built model.
That does not make Keystatic weaker overall. It means it prioritizes a different boundary between the CMS and the frontend.
Decap CMS: The Traditional Git CMS Approach
Decap CMS is the successor to Netlify CMS. It remains an open-source CMS for Git workflows and can be used with essentially any static-site generator rather than being designed around one framework.
Its basic architecture is easy to understand. You add an admin application to the site, create a config.yml describing your collections and fields, connect a backend, and let editors update repository content through the browser.
The backend communicates with services such as GitHub or GitLab to read and update files. Decap also documents backends for Bitbucket, Azure, Gitea/Forgejo, and Git Gateway configurations.
This loose coupling is one of Decap’s main advantages.
Your Astro application does not have to adopt a special data client just because Decap edits the Markdown files. The public website can keep reading those files exactly as it did before.
For developers who want the CMS to touch as little of the application architecture as possible, that simplicity is valuable.
Where Decap CMS is strongest
- Framework independence
- Simple mental model
- Multiple Git-provider backends
- Markdown-oriented publishing
- Open-source, self-hosted core
- Git-based editorial workflow
- Low coupling to the frontend application
Where Decap feels more traditional
Decap provides rich-text editing and live preview, and developers can register custom preview templates and styles. However, its preview model is primarily part of the CMS interface rather than the deeper field-to-rendered-page contextual editing Tina is designed around.
Decap can also support block-like page structures through variable-type lists and custom components, but the more sophisticated the editing experience becomes, the more custom configuration and preview work the developer is likely to write. Decap’s documentation notes, for example, that variable-type widgets require a registered preview template rather than receiving a default preview automatically.
Architecture Comparison
The easiest way to understand the difference is to look at the path between editor and website.
TinaCMS
Editor → Tina editing layer → structured content/API → Git files → Astro or another frontend
Tina inserts the richest CMS layer of the three, particularly when visual editing is enabled.
Keystatic
Editor → Keystatic Admin → TypeScript-defined schema → repository files → application content layer
Keystatic feels tightly connected to the application and its developer-defined content model.
Decap CMS
Editor → Decap Admin → Git-provider backend → repository files → site build
Decap is comparatively detached from the frontend. It primarily edits the files your site already knows how to consume.
Which Is Easiest to Set Up?
“Easy setup” needs two definitions: local setup and production setup.
Locally, all three can be relatively approachable. Decap can be especially minimal because its core implementation can be added as an admin application plus configuration. Its documentation describes the basic installation as adding the CMS to the site’s /admin route and connecting a backend.
Keystatic is also straightforward for supported frameworks. Its Astro integration installs @keystatic/core and @keystatic/astro, after which collections can be modeled in a TypeScript configuration file.
Tina’s current Astro tooling has improved substantially, and its Astro starter provides a direct route into the stack. However, once visual editing, production authentication, backend services, and editorial workflows enter the picture, the overall architecture has more moving parts than a basic Decap installation.
For the fastest basic admin-over-Markdown setup, Decap CMS has an advantage.
For developer-friendly structured setup, Keystatic is particularly clean.
For the richest editing experience, Tina justifies more setup by delivering capabilities the simpler architectures do not provide in the same way.
Content Modeling: TinaCMS vs Keystatic vs Decap CMS
Imagine every implementation needs the same Article model:
- Title
- Slug
- Author
- Published date
- Excerpt
- Featured image
- SEO title
- Meta description
- Body
All three can model content at that level.
The difference is how the model is expressed and how closely it connects to the developer’s application.
Tina defines collections and fields in code and uses the schema to generate the editor and typed querying infrastructure.
Keystatic also defines schemas in TypeScript and makes that configuration one of the central parts of its developer experience. Collections, singletons, conditional fields, relationships, and structured rich-content components fit naturally into this model.
Decap primarily models collections and widgets through config.yml. It supports a broad set of widgets, nested objects, lists, relationships, and custom widgets, but the configuration style feels less integrated with a TypeScript application than either Tina or Keystatic.
For a strongly typed modern frontend, Keystatic has perhaps the cleanest “schema belongs to the codebase” philosophy. Tina is similarly structured but couples that schema to a broader CMS API and visual-editing system. Decap prioritizes portability and loose coupling over deep application integration.
Which Has the Best Editor Experience?
Developer experience and editor experience should be scored separately.
A technically elegant CMS is not necessarily enjoyable for the marketer who needs to publish an article before lunch.
TinaCMS editor experience
Tina’s biggest advantage is context. When visual editing has been implemented properly, editors can work next to the actual rendered site and connect visible content with editable fields.
This reduces a common CMS problem: changing a field with a vague name and wondering where it appears.
Keystatic editor experience
Keystatic provides a polished structured admin interface and strong document editing. Its content components can make MDX or Markdoc much friendlier for non-developers because writers select structured components rather than manually writing component syntax.
It is particularly convincing for editorial interfaces where forms and structured rich text matter more than direct manipulation of the final page.
Decap CMS editor experience
Decap provides the familiar CMS pattern of collections, entry forms, rich text, media, and preview. That familiarity can be an advantage because the editor does not need to understand your application’s component architecture.
At the same time, complex Decap setups can expose the limitations of a configuration-driven admin interface sooner than Tina’s visual editing or Keystatic’s tightly modeled rich-content experience.
Visual Editing: Tina Is the Clear Differentiator
It helps to divide “visual editing” into three levels.
Form editing: change structured fields in an admin interface.
Live preview: see approximately or exactly how the page will look while editing.
Contextual editing: connect elements on the rendered site directly to the CMS fields controlling them.
All three can provide forms. Keystatic and Decap can support preview workflows. Tina goes furthest toward contextual editing as a core product capability.
That distinction matters most on component-heavy marketing sites.
If an editor is changing only article titles and body text, a good form interface may be enough.
If the editor is assembling heroes, feature sections, testimonials, FAQs, and calls to action, being able to see those changes within the actual page can dramatically reduce uncertainty.
Winner for contextual visual editing: TinaCMS.
Which Is Best for Page Building?
None of these products should automatically be treated as a replacement for Webflow, Elementor, or another unrestricted visual builder.
They are more interesting when developers define the available building blocks and editors compose content within those boundaries.
Tina supports template-driven structured blocks and a visual selector for block templates. That pairs naturally with its contextual editing model.
Keystatic’s MDX and Markdoc content components can also produce sophisticated component-based content. Developers define the component schema and can provide editor previews.
Decap can represent page sections with lists and variable types, making it possible to create reusable section systems. But sophisticated previews typically require more custom work.
For visually assembled landing pages, Tina has the strongest overall story. For rich documents with embedded structured components, Keystatic deserves serious consideration. Decap remains capable when the requirements are simpler or the team is comfortable building custom previews.
Markdown and MDX
All three are comfortable in file-based publishing environments, but the details matter for technical content.
Tina works naturally with Markdown and MDX and can model rich-text fields and custom elements.
Keystatic has particularly interesting MDX and Markdoc support because its content-component system lets developers expose custom blocks inside the editor. Keystatic statically analyzes MDX, however, which creates some restrictions: for example, its documentation notes that imports inside managed MDX documents are not supported, so rendering components must be supplied elsewhere in the application.
Decap has long supported Markdown-oriented workflows. Its older Markdown widget is currently being deprecated in favor of the newer rich-text widget, which the project recommends for continued support and a better editing experience.
For a technical publication containing prose, code examples, callouts, product cards, and comparison components, Keystatic and Tina generally offer the more structured developer experience. Decap remains attractive when standard Markdown is the primary requirement.
Which Git-Based CMS Is Best for Astro?
Astro changes this comparison because both TinaCMS and Keystatic now treat it as an important first-class framework.
Tina currently provides dedicated Astro setup and visual-editing documentation, including an Astro-specific integration that avoids the React dependency found in older Tina visual-editing implementations.
Keystatic also has a dedicated Astro package and documentation. Its official guide shows that content created by Keystatic can continue to be consumed through Astro Content Collections rather than forcing the site to replace Astro’s existing content model.
Decap works with Astro because it is framework-agnostic. In many ways that is both its advantage and its limitation: there is little Astro-specific architecture to learn, but you also do not get the same deep Astro-specific editing integration.
For an Astro blog managed mainly through forms, Keystatic is exceptionally appealing.
For an Astro marketing site where editors need contextual page editing, TinaCMS is the stronger fit.
For an existing Astro site where you want to add the least application-specific CMS machinery possible, Decap CMS may still be the pragmatic choice.
Authentication and Production Editing
Local editing is easy to demonstrate. Production authentication is where Git-based CMS architecture becomes more visible.
Keystatic’s GitHub mode requires the project to be in a GitHub repository, and collaborators using that mode need write access to the repository. Keystatic Cloud simplifies GitHub authentication and can let team members edit without needing individual GitHub accounts.
Decap offers several backend strategies. Direct GitHub, GitLab, Bitbucket, Azure, and Gitea-style configurations generally depend on appropriate repository access, while Git Gateway can act as a proxy between authenticated CMS users and the repository.
Tina can use TinaCloud for production authentication, content API functionality, and Git-backed editing, while teams that do not want the hosted service can investigate Tina’s self-hosting options.
The broader lesson is that “content is just files” does not mean production editing has no backend requirements. The moment a browser is allowed to change repository content securely, authentication and authorization need to exist somewhere.
Git Workflow and Editorial Review
Git-based CMS platforms become much more interesting when saving content is separated from publishing it.
A mature workflow may look like:
Editor → branch → preview → review → merge → production build
Decap’s Editorial Workflow explicitly supports unpublished entries and uses pull requests with supported GitHub-based configurations. Changes to an unpublished entry add commits to its pull request, and publishing merges the change.
Decap can also expose deploy-preview links when the continuous-deployment platform provides previews for unmerged content.
Tina offers an Editorial Workflow for higher-tier TinaCloud plans, connecting branch-oriented review and preview concepts to the editor experience. Its current pricing places Editorial Workflow on Team Plus and above.
Keystatic supports branch configuration in GitHub and Cloud storage modes and can associate collections with preview URLs. But teams wanting a sophisticated multi-stage editorial process should test the exact workflow they need rather than assuming Git branches automatically create a complete editorial system.
Media Management
Git is excellent at versioning text. It is not necessarily the ideal permanent home for thousands of large images.
Tina can use repository-based media, which keeps assets versioned alongside content, and it also supports connecting external media providers.
Keystatic lets developers control where image fields store files. Its Astro documentation includes specific patterns for placing images under src/assets so Astro’s image pipeline can process them. Keystatic Cloud Pro also offers an optional Cloud Images service for hosted image storage, transformation, and delivery.
Decap supports repository media as well as integrations and strategies for external media workflows. Its documentation also includes Netlify Large Media support for specific configurations.
For small marketing sites, repository media can be perfectly reasonable. For a large publication, image-heavy catalog, or years of accumulated editorial assets, external media storage deserves serious consideration regardless of which CMS you choose.
Frontend Performance
A Git-based CMS should not automatically force the public site to behave like a database-backed application.
Decap is the easiest example: the admin interface can remain separate from the public site’s rendering architecture. Your Astro pages can simply build from files as they did before.
Keystatic similarly allows the frontend to consume repository content through the application’s preferred content layer. In Astro, its own integration guide demonstrates reading Keystatic-managed files through Astro Content Collections.
Tina’s visual-editing architecture is more integrated, but the current Astro implementation was specifically designed to support Astro-native rendering rather than requiring React throughout the page.
The practical advice is to measure the visitor-facing site rather than judging performance from CMS architecture diagrams. Editing infrastructure and public runtime infrastructure are not necessarily the same thing.
Pricing
Pricing is another area where comparing only the word “open source” is misleading.
TinaCMS pricing
As of August 16, 2026, Tina lists a free TinaCloud plan for two users. Its published monthly pricing starts at $29 per project for Team, while annual billing for Team is $290 per year. Team Plus is $49 per month or $490 annually, and Business is $299 per month or $2,990 annually. Editorial Workflow is currently included from Team Plus upward.
Keystatic pricing
Keystatic itself can be used without paying for Keystatic Cloud. Keystatic Cloud currently provides a free plan for up to three users per team. Cloud Pro starts at $10 per month, with additional users beyond the included three priced at $5 per user per month. Pro also includes optional features such as experimental multi-player editing and Cloud Images.
Decap CMS pricing
The core Decap CMS remains free, open source, self-hosted, and MIT licensed. Decap is also developing the optional Turbo service for teams that want features such as centralized authentication, a database proxy, and additional support. The core CMS remains available independently of Turbo.
Subscription price is only part of the cost, however. A free CMS that requires several days of custom authentication, previews, and maintenance can be more expensive than a hosted service that costs a few hundred dollars per year.
Which Is Easiest to Remove Later?
This is one of the most useful tests for any Git-based CMS.
Imagine your team decides to replace the CMS two years from now. Delete its packages and configuration. What remains?
Decap has an inherent advantage when it has been used simply as an editor over ordinary Markdown and frontmatter. The application may have little or no runtime dependency on Decap in the first place.
Keystatic also keeps content in readable codebase files, but advanced MDX or Markdoc component structures may require migration work if your new content system expects a different syntax.
Tina likewise keeps canonical content in Git-friendly formats, which is far better for portability than proprietary-only storage. But a project deeply built around Tina queries, schema-generated structures, or visual-editing components will require application refactoring if Tina is removed.
Git-based storage reduces content lock-in. It does not automatically eliminate application-level lock-in.
AI and Automation
For AI workflows, the most interesting shared feature of all three CMS platforms may not be a built-in writing assistant.
It is Git.
When content exists as files, an AI workflow can create a branch containing proposed changes. A human can inspect the diff, leave comments, reject individual changes, and merge only what should become production content.
That creates a useful governance model:
Content → AI proposal → Git diff → human review → merge → deployment
Possible uses include metadata suggestions, stale-content detection, translation drafts, taxonomy recommendations, summaries, style checks, internal-link suggestions, and accessibility reviews.
Tina currently lists AI features as “Coming Soon” on applicable paid plans rather than presenting them as a completed core capability.
The broader lesson is that a CMS does not need a prominent “Write with AI” button to work well with AI. A transparent Git workflow may provide a safer automation surface because machine-generated changes can be reviewed exactly like code changes.
TinaCMS vs Keystatic vs Decap CMS: Detailed Comparison
| Criterion | TinaCMS | Keystatic | Decap CMS |
|---|---|---|---|
| Git-backed content | Excellent | Excellent | Excellent |
| Basic setup simplicity | Good | Very good | Excellent |
| Developer experience | Very good | Excellent | Good |
| Nontechnical editor experience | Excellent | Very good | Good |
| Contextual visual editing | Excellent | Limited/custom | Limited/custom |
| Structured content modeling | Excellent | Excellent | Very good |
| Markdown workflow | Excellent | Excellent | Excellent |
| MDX/component content | Excellent | Excellent | Good/custom |
| Astro integration | Excellent | Excellent | Good, framework-agnostic |
| Framework independence | Good | Moderate | Excellent |
| Git backend flexibility | Moderate | Primarily GitHub-oriented | Excellent |
| Page-building potential | Excellent | Very good | Good/custom |
| Lowest CMS coupling | Moderate | Good | Excellent |
| Best overall fit | Visual Git CMS | Code-first structured CMS | Simple, flexible Git admin |
These ratings describe architectural fit rather than absolute product quality. A category marked “Good” can still be the best choice if it is the category your project actually needs.
Choose TinaCMS If…
- You want editors to work against the rendered website rather than only forms.
- Your site uses reusable components and structured landing-page sections.
- You want Git to remain the source of truth.
- Developers are comfortable owning the CMS schema and visual-editing integration.
- Your editors need a richer experience than a traditional Markdown admin.
- You are building an Astro site where contextual editing is a priority.
Tina is particularly compelling for developer-led marketing websites. Developers can control component behavior while marketers control the content inside those components.
Do not choose Tina merely because you want a browser form for Markdown. There are simpler solutions for that requirement.
Choose Keystatic If…
- You prefer a TypeScript-first configuration model.
- You want content management to feel closely integrated with the application.
- You use Astro, Next.js, or another supported Keystatic workflow.
- You need structured Markdown, MDX, or Markdoc editing.
- Developers value strong schema ergonomics more than full-page visual editing.
- You want an excellent local editing workflow.
Keystatic is arguably the most natural of the three for a developer who says, “I want a CMS, but I want it to behave like part of my codebase rather than a separate platform.”
It is a particularly strong candidate for technical blogs, documentation, product content, and applications where structured data and rich documents matter more than direct page manipulation.
Choose Decap CMS If…
- You want a straightforward web admin for Markdown and repository content.
- You value framework independence.
- You want to keep CMS-specific application code to a minimum.
- You use Git providers beyond GitHub.
- You want the core CMS to remain fully open source and self-hosted.
- You do not require advanced contextual page editing.
Decap remains particularly useful for static sites where the application already works perfectly with files and the only missing piece is an editor-friendly interface.
Its architecture is less fashionable than some newer visual CMS approaches, but “boring” can be a real advantage when you want the CMS to remain loosely coupled to the website.
Best Git-Based CMS by Use Case
| Use case | Recommended starting point | Why |
|---|---|---|
| Astro marketing website | TinaCMS | Strong Astro-native contextual editing |
| Astro technical blog | Keystatic | Excellent code-first content modeling and Astro integration |
| Simple Markdown blog | Decap CMS | Low coupling and straightforward administration |
| Component-driven landing pages | TinaCMS | Visual editing plus structured blocks |
| MDX-heavy documentation | Keystatic | Strong content-component model |
| Multi-Git-provider agency stack | Decap CMS | Broad backend support |
| Developer-only/local content workflow | Keystatic | Excellent filesystem-based editing mode |
| Nontechnical marketing team | TinaCMS | Context makes structured fields easier to understand |
| Minimal SaaS dependency | Decap CMS | Free open-source self-hosted core |
Final Verdict: Which Git-Based CMS Should You Choose?
TinaCMS, Keystatic, and Decap CMS solve the same broad problem from three different directions.
TinaCMS asks: How can a Git-backed website provide an editing experience closer to a modern visual CMS?
Keystatic asks: How can structured content management become a natural, typed part of the application codebase?
Decap CMS asks: How can we put a practical editor interface in front of files already stored in Git?
If visual editing is the deciding requirement, choose TinaCMS first and evaluate whether its additional infrastructure is justified by the editorial experience.
If developer ergonomics, structured content, Astro integration, and a code-first architecture matter more than full contextual editing, Keystatic may be the better fit.
If you primarily need a reliable admin interface over repository files—and especially if framework and Git-provider flexibility matter—Decap CMS remains difficult to dismiss.
There is no universal winner because the most important difference is not a checkbox feature.
It is where each CMS draws the boundary between Git, application code, and the editor.
Choose the boundary that matches how your team actually publishes.
