Decap CMS
Founded 2016
Decap CMS Verdict
3/5Summary
Decap CMS (formerly Netlify CMS) is the most established Git-based CMS available, with nearly a decade of production use across static site ecosystems. Its YAML-driven config works reliably for straightforward content structures, and it integrates with more Git backends than any competitor. The honest caveat: development slowed materially after Netlify handed the project to the community in 2023, the editing UI has not kept pace with newer tools, and the lack of TypeScript-native schema definition is a real friction point compared to Keystatic. It is a solid, battle-tested choice for teams already comfortable with YAML config and not chasing modern DX.
Best For
Teams building with Hugo, Jekyll, or Astro who want a zero-cost, Git-based editorial interface with broad backend support and no vendor dependency.
Watch Out
YAML config becomes unwieldy on complex content models, editorial workflows are limited, and the post-rebrand development pace is noticeably slower than Keystatic or TinaCMS.
What Is Decap CMS?
Decap CMS is an open-source, Git-based content management system that provides a browser-based editorial interface for static sites and Jamstack projects. Instead of storing content in a database, it reads from and writes to Markdown, YAML, and JSON files in your Git repository. The admin UI is a React single-page application served at /admin, configured entirely through a config.yml file that describes your content collections, fields, and backend settings. When an editor saves content, Decap CMS commits the change directly to your repository via the configured Git backend.
The project started life as Netlify CMS in 2016, created by Netlify to fill the gap between the simplicity of static site generators and the editorial usability that content teams expected. For years it was the de facto standard for Git-based content management, widely adopted across Hugo, Jekyll, Gatsby, and Eleventy sites. In February 2023, Netlify transferred ownership to the open-source community under the organisation decaporg, rebranding it as Decap CMS. The code and config format are unchanged, but stewardship shifted from a well-funded SaaS company to a smaller community effort led primarily by PM TechHub, a Slovenian agency.
Today, Decap CMS sits in an interesting position. It remains the most battle-tested Git-based CMS with the broadest backend support (GitHub, GitLab, Bitbucket, Azure DevOps, Gitea) and an established integration surface across the static site ecosystem. The trade-off is visible: the editorial UI has not kept pace with newer tools, the YAML configuration system shows its age on complex projects, and the post-rebrand development pace is slower than competitors like Keystatic or TinaCMS. For teams that need a proven, zero-cost, infrastructure-free CMS with no vendor dependency, it still earns its place.
Key Features
- Git-native storage: Content is Markdown, YAML, and JSON committed directly to your repository, no database or external service required
- YAML configuration: A single config.yml file defines all collections, field types, backends, and media settings
- Multiple Git backends: Native support for GitHub, GitLab, Bitbucket, Azure DevOps, and Gitea, plus the Git Gateway proxy for teams without direct repository access
- Editorial workflow: A beta draft/review/ready workflow that uses Git branches to stage content before publication, intended for teams that need a review step before publishing
- Media library integrations: Default local storage in the repo, plus integrations with Cloudinary and Uploadcare to offload asset hosting to a CDN
- Netlify Identity support: Netlify's Identity service allows editors to log in without needing a Git host account, lowering the barrier for non-technical teams hosted on Netlify
- Custom widgets: An extension API for registering custom field types when the built-in widgets do not cover a specific content need
- Framework-agnostic: Works with Hugo, Jekyll, Eleventy, Astro, Gatsby, and any static site generator that stores content as files
Pricing
Decap CMS is free in every meaningful sense. The MIT license places no restrictions on use, commercial or otherwise. There are no paid tiers, no editorial seat limits, and no feature gating. The admin UI is a static bundle you add to your /public directory. You host it on the same infrastructure as your site.
The only costs are infrastructure you are likely already paying for: your Git host (GitHub free tier is sufficient for most projects) and your static host (Netlify, Vercel, Cloudflare Pages, GitHub Pages). If you use Netlify Identity for editor authentication, it falls within Netlify's free tier for teams with under five users. If you choose the Git Gateway backend without Netlify, you need to self-host the gateway server or configure OAuth directly against your Git provider, which is free but requires some setup.
For teams already on Netlify, the combination of Decap CMS plus Netlify Identity is genuinely zero incremental cost for a complete editorial setup.
Our Experience
We have been using this CMS since the Netlify CMS era, and it earned our trust on a range of projects before the 2023 rebrand. For a content structure like a blog, a documentation site, or a marketing site with a modest number of fields, the YAML config comes together quickly and the editorial interface is straightforward. The reliability of the Git-based model, no SaaS dependency, no database outages, no pricing changes that break project budgets, was a real advantage on client projects where long-term maintenance predictability mattered.
The friction we have consistently encountered is with config.yml at scale. Once a content model grows beyond a handful of collections with complex nested structures or multiple related types, the YAML starts to feel unwieldy. There is no TypeScript config, no code editor autocompletion, and no type-checking on the schema. Mistakes produce runtime errors in the admin UI rather than build-time feedback. We have also run into the limitations of the editorial workflow feature on projects where non-technical clients needed a reliable draft-and-review cycle: the branch-based workflow is marked as beta for a reason.
When Lucky Media Recommends Decap CMS
We reach for Decap CMS when:
- The project uses Hugo, Jekyll, or Eleventy, where Decap CMS has the most mature integration path
- The team needs to connect to GitLab, Bitbucket, Azure DevOps, or Gitea (backends that Keystatic does not support)
- Absolute zero cost is a hard constraint and the team is already on Netlify (Identity + Git Gateway is the fastest zero-cost editorial setup)
- Content editors are non-technical and will authenticate via Netlify Identity, avoiding any Git host account requirement
- The content model is relatively straightforward: a blog, a simple marketing site, or a documentation site without complex relationships
- The team is already familiar with YAML-based configuration and has existing Netlify CMS projects to maintain
We would suggest alternatives when:
- The project is on Astro or Next.js and developer experience matters: Keystatic offers a substantially better DX for those frameworks
- The content model is complex, with nested blocks, rich relational references, or component-based content structures
- Editorial workflows with reliable draft, review, and scheduling are a firm requirement
- The team needs TypeScript-native schema definition with editor autocompletion and build-time type safety
- Multi-locale content management is required
- The team values a rapidly evolving platform with active feature development rather than a stable but slower-moving one
faq
What is Decap CMS?
Decap CMS is an open-source, Git-based content management system originally built by Netlify. It provides a browser-based admin interface at /admin that lets editors create and update content stored as Markdown, YAML, or JSON files in a Git repository, without needing to touch the command line. It was called Netlify CMS from its launch in 2016 until February 2023, when Netlify handed the project to the community and it was renamed Decap CMS under the decaporg GitHub organisation. The core concept is the same as it has always been: your content lives in your Git repo, changes are commits, and the CMS is a UI layer on top of your existing version control workflow.
Is Decap CMS free?
Yes, fully. Decap CMS is MIT-licensed open-source software with no paid tiers and no SaaS pricing. The admin UI is a static bundle you host yourself alongside your site. The only costs are the infrastructure you are already paying for: your static host (Netlify, Vercel, GitHub Pages, or any other) and your Git host (GitHub, GitLab, Bitbucket). If you use Netlify Identity for editor authentication, that falls within Netlify's free tier for small teams. There is no usage cap, no editorial seat licensing, and no enterprise tier.
What is the difference between Decap CMS and Netlify CMS?
They are the same project with different names. Netlify CMS was created by Netlify in 2016 as an open-source Git-based CMS for static sites. In February 2023, Netlify transferred the project to a community organisation called decaporg and rebranded it as Decap CMS. The npm package changed from netlify-cms to decap-cms, the GitHub repository moved to github.com/decaporg/decap-cms, and the website moved to decapcms.org. The codebase, config format, and feature set are the same. If you have an existing Netlify CMS installation, migration to Decap CMS is a package rename and a URL update.
What is the difference between Decap CMS and Payload CMS?
They solve different problems at different levels of the stack. Decap CMS is a lightweight editorial UI for Git-based content: no database, no server, no delivery API, just a browser-based interface on top of files in a repository. It is best suited for static sites and Jamstack projects where content lives as files. Payload CMS is a full-stack, self-hosted headless CMS with a Node.js and MongoDB or PostgreSQL backend, a REST and GraphQL delivery API, TypeScript-native schema definition, and access control at the collection and field level. Payload is the right choice when you need a backend, a delivery API, complex relationships, or role-based permissions. Decap CMS is the right choice when you want zero backend infrastructure and Git-native content storage.
How does Decap CMS compare to Keystatic and TinaCMS?
All three are Git-based, but they differ meaningfully in maturity, developer experience, and momentum. Decap CMS is the most established (~18k GitHub stars, nearly a decade in production) and integrates with the widest range of Git backends and static site generators. Keystatic (built by Thinkmill) is newer but offers TypeScript-native schema definition, a cleaner Astro and Next.js integration, and a more actively developed codebase. TinaCMS offers visual in-context editing that neither Decap CMS nor Keystatic provides, and has a hosted cloud option with branch-based workflows. In practice: choose Decap CMS if you are on Hugo or Jekyll and want a proven zero-cost solution. Choose Keystatic if you are on Astro or Next.js and developer experience is a priority. Choose TinaCMS if visual editing for content editors is a firm requirement.
Our verdict
| Content Modeling | |
|---|---|
| How flexible is the content modelling system?Can you define complex, nested, and relational content types without workarounds? | ●●●●●3/5 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. |
| How well does the platform support reusable content blocks?Blocks that map directly to design system components. | ●●●●●2/5 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. |
| Does the platform enforce content validation rules natively?Required fields, character limits, regex, custom validators. | ●●●●●3/5 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. |
| Editor Experience | |
| How intuitive is the editing interface for a non-technical editor?Could a new editor publish their first piece of content within one hour, without help? | ●●●●●3/5 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. |
| Does the platform offer live or visual preview of content?As it will appear on the frontend, without developer configuration. | ●●●●●2/5 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. |
| How well does the platform handle the full editorial workflow?Drafts, scheduling, approval chains, role-based permissions. | ●●●●●2/5 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. |
| How effective is the media and asset management?Upload, organisation, image transforms, search at scale. | ●●●●●2/5 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. |
| Collaboration | |
| Does the platform support real-time collaboration?Simultaneous editing, presence indicators, inline comments. | ●●●●●1/5 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. |
| How granular and practical are user roles and permissions?By content type, locale, or specific fields, not just admin/editor. | ●●●●●2/5 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. |
| Localisation | |
| Is multi-locale content management native?Field-level localisation, not page duplication or plugin workarounds. | ●●●●●2/5 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. |
| Can editors manage locale fallback logic natively?e.g. show English if French translation is missing. | ●●●●●1/5 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. |
| Developer Experience | |
| How well-documented and developer-friendly is the delivery API?REST, GraphQL, typed SDKs, TypeScript support. | ●●●●●2/5 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. |
| How fast and friction-free is integration with modern frontend frameworks?Next.js, Astro, Nuxt, Remix, official examples or starter kits available. | ●●●●●3/5 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. |
| Does the platform provide a Management API for programmatic content operations?Bulk import, AI pipelines, scripting. | ●●●●●1/5 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. |
| Does the platform support environment branching or staging environments?For safe content and schema testing before promoting to production. | ●●●●●2/5 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. |
| Performance | |
| Does the platform deliver content via a global CDN?And how does this affect real-world API response times for your frontend? | ●●●●●4/5 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. |
| How straightforward is hosting and deployment?Does the platform reduce or add infrastructure complexity? | ●●●●●4/5 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. |
| Ecosystem & Longevity | |
| How mature and practically useful is the integration ecosystem?Not just quantity, are the integrations your clients actually need available and well-maintained? | ●●●●●3/5 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. |
| How active and meaningful is platform development?Community health, release cadence, direction of travel. | ●●●●●2/5 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. |
Final verdict The verdict score is a weighted average of the criteria above. | 3/5 |
