Keystatic vs Hygraph

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.

GraphQL-native schema with union types and polymorphic relations. Content Federation adds external data sources.

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.

Component models embed across content types. Schema-first reuse is straightforward for GraphQL-experienced developers.

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.

Basic required, unique, and regex validators. Advanced custom validation is limited compared to alternatives.

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.

The editor is functional but complex. Editors need to understand GraphQL-style relationships before working efficiently.

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.

Preview via configurable URLs. No live preview panel, editors see changes after saving. Developer setup required.

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.

Custom content stages are configurable. Approval workflows with notifications are available on paid plans.

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.

Handles uploads and basic transforms via the built-in API. Less capable than alternatives.

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.

Presence indicators show concurrent editors. Live sync available but less polished.

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.

The most granular here, field, locale, content stage, and model-level access designed for complex enterprise orgs.

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.

Multi-locale is first-class with field-level variants, locale-specific publishing, and multi-region API delivery.

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.

Native fallback configured in project settings with API-level enforcement. GraphQL returns fallback values automatically.

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.

Excellent GraphQL docs with a live playground, schema introspection, and generated TypeScript types.

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.

Good framework examples. GraphQL-first means any client works easily, less framework tooling than alternatives.

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.

Full schema management via GraphQL mutations, types, relations, and fields all programmatically creatable.

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.

Branch schema and content for testing, then promote. Less polished than DatoCMS's one-click sandbox workflow.

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.

Global CDN with multi-region data residency on Enterprise. API performance is strong globally, especially for GraphQL.

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.

Fully managed SaaS with zero infrastructure to configure or maintain.

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.

Focused on e-commerce, frameworks, and enterprise tools.

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.

Enterprise-niche community. Active Discord with responsive support but fewer tutorials and third-party resources.