Decap CMS for publishers: a Git-based editor for static sites

What is Decap CMS?

Decap CMS is an open-source, Git-based editing interface for static websites. Its website calls it “open source content management for your Git workflow”, says it is MIT-licensed, and says it is independently maintained in the European Union with contributors from around the world. It was formerly Netlify CMS: the repository says the project was renamed in February 2023, and the documentation states that Decap and Netlify are separate tools.

Technically it is a single-page application built on React, served from an /admin path on your site according to the repository. It works as a wrapper around Git APIs. Content stays as files in your repository, and editors change them through forms instead of editing Markdown directly. It does not generate your site. A static site generator such as Hugo does that.

Who is Decap CMS best for?

Decap suits a small publication or a client site where a developer has built a static site and editors need a friendly way to write articles without touching Git. It pairs with generators such as Hugo, and Hugo’s own front-ends page lists Decap CMS among the open-source options. If your site is already in a Git repository and you want to keep it there, Decap adds an interface rather than replacing your stack.

It is not aimed at a large newsroom. There are no user-role controls documented beyond what your Git host allows, and live, high-frequency publishing goes through a rebuild. A publisher who wants an all-in-one system with built-in hosting, user management and search should look at a conventional CMS in the directory.

Editorial workflow

By default, Decap saves straight to your repository. For review, set publish_mode: editorial_workflow. The documentation then maps editor actions onto Git: saving a draft creates a branch and opens a pull request, editing pushes more commits, and publishing merges the pull request and removes the branch. GitHub has full support, GitLab tracks status using merge request labels, and Bitbucket uses pull request comments.

That is a real review step with a full Git history, but the roles come from your Git host. Who may approve is whoever can merge. Editors see the entries in a list, and a preview pane can be configured or turned off. We found no scheduling feature in the pages we opened. Scheduled publishing would need your static site generator’s date handling, such as Hugo’s publish dates, plus an automated rebuild.

SEO, structured data and feeds

Decap does none of this itself. Titles, meta descriptions, sitemaps, feeds, canonical tags and structured data are produced by the static site generator and its templates. What Decap contributes is the fields: the configuration decides which fields editors fill in, so a developer can add a meta description field or a canonical URL field to each article collection. A preview_path setting can also generate deploy-preview URLs.

For a news site, check how your generator handles feeds, sitemaps and redirects. Hugo generates RSS feeds and sitemaps by default, according to its documentation. The guides cover what Google asks for.

Media, multilingual and performance

The configuration requires a media_folder where uploads are saved, and a public_folder for how they are referenced on the built site. A third-party media_library such as Uploadcare can be configured, according to the documentation. Image processing is the job of your generator.

For languages, the documentation has an i18n support section and a UI locale setting, though non-English interface languages need manual registration in custom JavaScript. We did not read the i18n section in detail. Performance of the public site is that of your static output. The editor itself is a client-side application, and a 3.16.x release note mentions editor performance work, but we have no measurements.

Hosting and requirements

Decap needs two things on your site: the admin page and a configuration file. The documentation describes installation as requiring just two files. It then needs a backend, which can be GitHub, GitLab, Bitbucket, Gitea, Azure or Git Gateway. For GitHub, the documentation describes deploying a lightweight OAuth proxy, such as an edge worker or serverless function, or using the hosted Decap Turbo option, which handles authentication and caching.

It can be used on any hosting platform, and the documentation says it can be used independently of Netlify. See the self-hosted guide for the general trade-offs.

Extending Decap CMS

Extension is by configuration and JavaScript: custom collections and fields, custom backends (the documentation encourages writing them, with the GitHub backend as a reference), and custom preview or widgets. The documentation lists nested collections and a rich text widget as beta features. Hugo’s front-ends page also lists Sveltia CMS as a drop-in replacement for Decap, which shows that an ecosystem of compatible editors exists. We did not assess it.

What Decap CMS costs

The software is free under the MIT licence; see the licence guide. Costs are the developer who builds the site and configures the CMS, static hosting, a Git provider, and possibly a hosted authentication service. We did not check any Decap Turbo pricing. The cost guide lists the budget categories.

Where Decap CMS falls short

• It is an editor only. You must supply the static site generator, build and hosting.
• Sign-in runs through a Git provider, so editors need an account the repository recognises, unless you set up Git Gateway or a similar route.
• Publishing is rebuild-based. A change is live only after the site is rebuilt and deployed.
• Roles, audit and permissions come from the Git host, not from Decap.
• Some features, such as nested collections and the rich text widget, are labelled beta in the documentation.
• This is a documentation-only assessment. See how we test.

The verdict for publishers

Decap is a sensible, low-cost way to give editors a proper writing screen on top of a static site, and its pull-request workflow gives a genuine review step with a complete history. It makes most sense paired with Hugo or a similar generator, run by a developer who will own the build.

If you need roles, a media library with search, scheduled publishing and one place to manage it all, a conventional CMS is the safer option. Think of Decap as the editor half of a decoupled setup, and judge the whole stack, not just the editor.