TinaCMS vs Keystatic

TypeScript-first defineConfig covers string, rich-text, datetime, boolean, image, number, reference, and object field types. Nested objects and arrays are supported. The reference field handles cross-collection relations cleanly. The ceiling is that all content must map to files in Git, so highly relational or graph-like data models require careful design. Within those constraints, the schema system is expressive and type-safe.

Keystatic's TypeScript-based config gives you 30+ field types including blocks, arrays, conditionals, relationships, and rich text via Markdoc or MDX. Complex nested structures are achievable without workarounds. The main ceiling is that all content must map to files, so deeply relational data (many-to-many, cross-collection references) requires careful design. Within those constraints, the schema system is expressive and fully type-safe.

Object fields can be shared as reusable templates across collections, and the rich-text field supports a custom component system that maps to frontend design system components. There is no formal global block library, but the pattern is achievable through shared TypeScript definitions. Less elegant than Sanity's Portable Text, but workable for component-based content patterns.

The blocks field type supports design-system-aligned component patterns, and singletons handle global content like nav and footer well. But there's no true content block library or global component reference system. Reuse happens by convention in code, not enforced by the CMS itself.

Required fields, type constraints, and custom validation functions are supported in the schema definition. Cross-field validation and async validators are not natively available. The built-in validation covers the majority of real-world content requirements; teams with complex business rules will need to handle edge cases at the framework layer.

Required fields, text length constraints, and regex validation are supported via the TypeScript schema. Custom async validators are not natively available. The validation story is solid for basic to intermediate needs but won't satisfy teams with complex business rules who rely on the CMS to enforce them.

The Tina admin UI is clean and reasonably intuitive for non-technical editors. Basic content editing, image uploads, and saving are accessible within an hour for most users. The friction is the Git model: editors need a Tina Cloud account, and saves are commits. For teams on Tina Cloud, the auth flow is handled cleanly. The visual editing mode is the exception, it genuinely reduces the learning curve by letting editors work directly on the page, but it requires developer configuration first.

The admin UI is clean, opinionated, and generally intuitive. A non-technical editor can navigate collections, create entries, and publish within an hour if someone has configured the project correctly. The friction is the Git model itself: editors need to understand that saving triggers a GitHub commit, and that there's no staging area separate from the repo.

Visual in-context editing is TinaCMS's headline feature and its strongest differentiator in the Git-based CMS category. Editors open the admin, navigate to a page, and can click directly on any instrumented text or field to edit it in a sidebar while watching the live page update in real time. No separate preview window, no publish-then-check loop. The experience is comparable to what Sanity offers via its Presentation tool, but built directly into a Git-based workflow. Requires developer setup via the useTina hook.

No built-in live preview. Keystatic doesn't provide an iframe preview or visual editing experience out of the box. You can wire up draft preview routes in Next.js or Astro yourself, but it requires developer setup and isn't seamless. Compared to TinaCMS or Sanity's presentation layer, this is a meaningful gap for content-heavy sites.

Editorial Workflow (drafts, review states, and branch-based staging) is available from the Team Plus plan at $49/month. It supports draft content, review states, and branch previews managed through the Tina Cloud interface. This is a meaningful step ahead of Keystatic and Decap CMS, which have no equivalent native workflow tooling. Scheduling and approval chains are limited compared to full headless platforms like Sanity or Contentful.

No approval workflows, no content scheduling, and no draft staging independent of Git branches. Drafts exist only as uncommitted changes in the browser's local storage. If your editorial process requires review-before-publish or scheduled publication, you're implementing it yourself through Git pull request conventions, which is a developer workflow, not an editor one.

Images can be stored in the Git repo, served via a configured media folder, or handed off to external providers. Tina Cloud supports media offloading to keep binaries out of Git history. The media management UI is functional but not a full DAM: no tagging, no search at scale, no native image transformation pipeline. For blogs and mid-size marketing sites it is adequate; for asset-heavy sites a third-party media provider (Cloudinary, Cloudflare Images) is the recommended complement.

Local images are stored directly in the repository, which becomes a problem at scale as repo size grows. Keystatic Cloud's Pro plan adds Cloud Images, which handles upload, optimization, and serving via CDN. This resolves the core problem but puts it behind a paywall. No DAM-level organization, search, or tagging. Adequate for a blog, inadequate for a content-heavy marketing site.

No native real-time collaboration. Simultaneous editing by two users on the same document risks a Git conflict. There are no presence indicators or inline comments in the editor. The collaboration model is the Git branch model, which is workable for small teams with good conventions but is not suitable for newsrooms or large content operations.

Multi-player editing is on the Keystatic Cloud Pro roadmap and listed as experimental as of 2025. In practice, simultaneous editing means Git merge conflicts. There are no presence indicators or inline comments. The collaboration model is pull request-based, which works fine for developer teams but is an obstacle for dedicated content teams.

Tina Cloud supports user roles with permission scoping. The Business plan adds three configurable roles. Role granularity is at the team and content level rather than field level. Adequate for agencies managing multiple client sites or teams with distinct author and editor roles; not sufficient for enterprise compliance requirements with field-level access control.

Permissions are inherited from GitHub repository access levels (read, write, admin) plus basic Keystatic Cloud user roles. There are no collection-level or field-level permissions, no content ownership model, and no way to restrict a specific editor to a subset of content. Adequate for a 2-3 person team, limiting for anything larger.

No native multi-locale UI. Multi-language sites require manual conventions: separate collection paths per locale or a custom field-based locale pattern. There is no locale switcher in the admin, no translation status tracking, and no locale-aware field configuration. Any project with serious i18n requirements should look at Sanity, Hygraph, or Contentful.

Keystatic has no native localization support. Multi-locale content requires manual convention: separate collection paths per locale, file naming schemes, or a custom abstraction layer built on top. There is no locale switcher in the admin UI, no translation status tracking, and no locale-aware field configuration.

Locale fallback logic must be implemented entirely at the framework layer. The CMS provides no fallback configuration, no missing translation indicators, and no locale-aware content inheritance. This is a hard blocker for projects with multi-locale requirements.

Locale fallback logic does not exist in the CMS. Anything beyond a single-language site requires custom implementation at the framework layer. This is a hard blocker for any project with internationalization requirements.

TinaCMS generates a typed GraphQL client from your schema at build time, giving you autocompletion and type safety in your IDE without manual type writing. The official documentation is well-structured, with dedicated guides for Next.js, Astro, and Hugo. The GraphQL layer is a genuine step up from the file-reading approach of Keystatic or Decap CMS, enabling dynamic and static content fetching patterns from the same API.

Documentation is well-organized, genuinely developer-friendly, and the Reader API is ergonomic. Full TypeScript support means your editor gets autocompletion for content queries. There's no delivery API in the traditional sense because content is read from the filesystem at build time, not fetched from a remote API. This is a strength for build-time performance and a limitation for real-time use cases.

Next.js is the primary target framework and the integration is first-class: official starter, documented visual editing setup, and the useTina hook built for React. Astro integration exists with an official starter template, but visual editing with Astro requires React components and the client:tina directive, and is currently listed as experimental. Hugo and other static site generators are supported for basic editing without visual editing. The tighter the React coupling, the better the experience.

First-class Astro and Next.js integration is a genuine differentiator. The Astro integration is official, maintained by the Keystatic team, and the setup takes under 30 minutes. The CLI scaffolds full starter projects. Remix support exists. No Nuxt support. For the specific stack of Astro or Next.js, this is the smoothest integration experience in the Git-based CMS category.

TinaCMS exposes a GraphQL management API via Tina Cloud or the self-hosted backend, enabling programmatic content reads and writes beyond the admin UI. This is a meaningful step above Keystatic and Decap CMS. The API surface is not as mature as Sanity's Mutations API, but it covers the primary use cases for content seeding, migration scripts, and external integrations.

There is no management API for programmatic content operations from external systems. Content is authored through the admin UI or directly as files. You cannot push content via API from a pipeline or integrate with a third-party DAM or PIM. The GitHub API is technically available for scripting, but this is not a supported pattern.

Branch-based environments are supported in Tina Cloud's editorial workflow. You can point the admin at a specific Git branch, enabling a staging branch workflow alongside production. Tina Cloud handles branch management in the UI on paid plans. On the free tier and in self-hosted mode, environment separation requires manual Git branch conventions.

Environment branching maps to Git branches. In GitHub mode, you can point Keystatic at a specific branch per environment, which gives you a basic staging setup. There's no first-class environment concept in the admin UI, no environment promotion workflow, and no preview environment linking. It works but requires deliberate branch management conventions.

At build time, content is read from Git via the GraphQL layer and compiled into your static output, so there is no runtime CMS API call for statically generated pages. In visual editing and preview mode, the useTina hook fetches from the Tina Cloud or self-hosted GraphQL endpoint at runtime. Content delivery performance for production sites is excellent (Git-based, no runtime CMS dependency); preview mode adds a network dependency that is acceptable for editorial use but not production traffic.

Content is read from the filesystem at build time, so there are no API calls at runtime and no CDN dependency for content delivery. This is a structural performance advantage for statically generated sites. Cloud Images on the Pro plan adds CDN-served optimized images. The absence of a runtime delivery API means no CDN latency to worry about and no rate limits to design around.

Tina Cloud is the zero-infrastructure path: connect your repo, add environment variables, and you have a managed backend. The trade-off is a SaaS dependency that Keystatic and Decap CMS do not require. Self-hosting the backend means deploying a database adapter (Redis/ MongoDB), auth provider, and a GraphQL API endpoint. It is well- documented but adds meaningful infrastructure overhead compared to the file-reading simplicity of other Git-based tools.

No separate CMS infrastructure to deploy or maintain. Keystatic runs as part of your Next.js or Astro app. Local mode requires zero configuration. GitHub mode requires setting up a Keystatic Cloud account or configuring a GitHub OAuth app, which is straightforward. No databases, no servers, no CMS-side deployments. This is meaningfully simpler than any hosted headless CMS.

Official integrations and starters exist for Next.js, Astro, and Hugo. The plugin surface is smaller than Sanity or Contentful but larger than Keystatic. TinaCMS has a media adapter system for external asset providers. The ecosystem is focused rather than broad, covering the most common Jamstack use cases without the breadth of a larger platform.

The integration ecosystem is limited but growing. Official support for Astro, Next.js, and Remix exists. No official plugins for analytics, commerce, or third-party integrations. Thinkmill's broader KeystoneJS ecosystem provides some adjacency but Keystatic is a distinct project. Compared to Sanity or Contentful, the plugin and integration surface is minimal.

TinaCMS has approximately 12,000 GitHub stars as of early 2026, ahead of Keystatic (~2,000) and behind Decap CMS (~18,000). The project is backed by a dedicated company (the former Forestry team), which gives it more active development momentum than the community- maintained Decap CMS post-rebrand. Release cadence is consistent, the GitHub Discussions board is actively monitored, and the team ships meaningful features. The risk profile is lower than community- only projects but higher than a fully enterprise-funded platform.

Thinkmill is a credible backer with a strong open-source track record (KeystoneJS). The GitHub repository has ~2,000 stars and ~50 contributors as of early 2025, which is smaller than Decap CMS (16k stars) or TinaCMS (9k stars) but with substantially faster growth rate. Release cadence is active and the GitHub Discussions board is responsive. The risk is concentration: Thinkmill is a small agency and if priorities shift, the project could stall.