Decap CMS vs Keystatic

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.

Decap CMS supports the core field types you need: string, text, number, boolean, date, image, file, list, object, and relation. Nested structures are achievable via the object and list widget types. The ceiling appears on complex, deeply relational content models: the relation widget is limited to single-collection references, and there is no block-based component system comparable to Keystatic's blocks field or Sanity's portable text. For a blog or a marketing site with a defined content schema, it is sufficient. For a content platform with rich relational structure, the config will start working against you.

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.

There is no native component or content block library. Reuse of content patterns across collections requires duplicating field definitions in config.yml, which becomes a maintenance burden as the schema grows. Partial YAML anchors can mitigate this, but it is a workaround rather than a feature. Compared to tools with explicit block registries (Sanity, Keystatic), the reuse story is weak.

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.

Required fields, pattern matching via regex, min/max on lists, and basic type constraints are supported natively. There is no custom async validator system and no cross-field validation. For straightforward content models, the built-in validation covers most common use cases. Teams with business-rule-heavy validation requirements will need to handle that at the framework layer.

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 editorial interface is functional and not intimidating for non-technical users. A content editor can learn the basics within an hour: create an entry, fill in fields, upload an image, and save. The friction is on the conceptual model: saving creates a Git commit, and editors without any Git background occasionally find this confusing. The UI itself is clean but dated compared to Sanity or even Keystatic.

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.

Decap CMS includes a preview pane feature, but it requires custom React-based template configuration by a developer to render content as it would appear on the site. Out of the box, the preview pane shows raw field values rather than a rendered page. There is no visual in-context editing. For teams that need true live preview, the setup cost is non-trivial and the result is still not as polished as TinaCMS or Sanity Studio.

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.

The editorial workflow feature (draft, in-review, ready states managed via Git branches) exists but is explicitly marked as beta and has a history of instability. In practice, when content changes involve more than a handful of files, merge conflicts can surface in ways that are hard for non-technical editors to resolve. For solo publishers or small teams with light workflow needs, it is usable. For any team that needs a reliable approval-before-publish chain, it is not dependable enough.

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.

Media uploads are stored directly in the Git repository by default, which causes repo bloat on image-heavy sites. Cloudinary and Uploadcare integrations are available as media library options to offload asset hosting, but they require additional configuration. There is no native DAM, no image transformation pipeline, and no tagging or folder organisation at scale. Adequate for a small blog, limiting for a content-heavy site.

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.

No real-time collaboration. Simultaneous editing by two users on the same entry is likely to produce a Git conflict. There are no presence indicators, no inline comments, and no conflict-resolution UI. The collaboration model is the Git model, which works for developer teams and is an obstacle for dedicated content teams.

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.

Access control is handled at the Git host level (GitHub, GitLab, Bitbucket) or via Netlify Identity. There are no collection-level or field-level permissions within the CMS itself. You cannot restrict an editor to a specific section of content or make certain fields read-only for certain roles. Adequate for teams where all editors have equivalent access; limiting for anything with role-based content ownership.

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.

There is no native multi-locale UI. The common workaround is separate collections per locale or a folder-based convention. An i18n configuration option exists in beta that enables locale-specific folders, but it is not a first-class feature and the documentation reflects its experimental status. Any project with serious localisation requirements should look elsewhere.

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.

Locale fallback logic is not managed by the CMS. Teams relying on fallback behaviour must implement it entirely at the framework layer. There is no fallback indicator in the editorial UI and no mechanism to flag missing translations.

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.

There is no delivery API. Content is read as files from the repository at build time. Decap CMS has no typed SDK, no GraphQL endpoint, and no REST API for content queries. Documentation is functional but reflects a project maintained primarily by volunteers: some sections are outdated, examples reference deprecated configurations, and TypeScript support is absent at the schema definition layer. A developer familiar with static site generators will find their way, but the experience is not polished.

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.

Integration guides exist for Hugo, Jekyll, Gatsby, Astro, and Eleventy in the official docs. The Astro docs include a Decap CMS guide. Setup is manual: two files (index.html and config.yml) in a /public/admin directory, and you are running. No CLI scaffolding, no starter templates maintained by the Decap team. Third-party Astro starters include Decap CMS configurations. For Next.js, integration is possible but less documented than Hugo or Astro paths.

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.

There is no management API for programmatic content operations. Content is created and edited exclusively through the admin UI or directly as files in the repository. You cannot ingest content from external systems via API. Scripting is possible at the Git level, but this is not a supported workflow.

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.

Environments map to Git branches. You can configure Decap CMS to point at a different branch for a staging environment, but there is no first-class environment concept in the admin UI. Environment promotion is a manual Git operation. This is workable with developer discipline but requires establishing your own conventions.

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.

Content is read from the filesystem at build time, so there is no runtime API call and no CDN dependency for content delivery. This is the structural performance advantage of the Git-based model. With a fast static host (Netlify, Vercel, Cloudflare Pages), the full site including content is globally distributed at the CDN layer. External media libraries like Cloudinary add CDN-served image delivery.

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.

There is no CMS server to deploy or maintain. The admin UI is a static HTML and JS bundle served from your /admin path. Netlify hosting is the path of least resistance (Git Gateway and Identity integrate directly), but Decap CMS works on any static host with any of its supported Git backends. No databases, no persistent servers, no CMS-side infrastructure bills.

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.

The integration ecosystem is broader than Keystatic or TinaCMS for static site generators specifically. Hugo, Jekyll, Eleventy, Gatsby, Astro, and Hexo all have documented paths. Media library integrations with Cloudinary and Uploadcare exist. Backend support spans GitHub, GitLab, Bitbucket, Azure DevOps, and Gitea. The plugin and custom widget API allows extending the field type system. What the ecosystem lacks is momentum: fewer new integrations are being built compared to the Netlify CMS era.

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.

With ~18,000 GitHub stars and a long track record, the project has significant visibility. The honest picture post-2023 is one of slower development: the rebrand from Netlify CMS to Decap CMS moved stewardship to a Slovenian agency (PM TechHub), and while the project is not abandoned, the release cadence has slowed compared to competitors. No pull request or issue activity was detected in recent months. The community remains active in discussions, but the direction-of-travel for product development is less clear than for Thinkmill-backed Keystatic or TinaCMS.