How Decap CMS Handles Editing and Editorial Workflow

Decap CMS gives editors a web-based interface with structured fields, rich text, and live preview, while content changes are committed to your Git repository rather than a separate database. It fits teams running Git-backed static or Jamstack sites (Hugo, Next.js, Gatsby, Jekyll, and similar) who want non-technical contributors to edit content without touching code. The editorial workflow adds draft, review, and publish statuses on top of that Git-native model.

The editing experience

Decap's editor is a web UI, not a desktop app or a hosted SaaS dashboard. Editors log in, pick a collection, and fill in fields defined by the developer. Key pieces:

• Structured fields — content is modeled as collections with typed fields, so editors fill in defined inputs instead of free-form files.
• Rich text — a rich text editor handles formatted body content.
• Live preview — editors see how content will render as they type, which is what makes the UI usable for non-technical contributors.

The site notes the demo image is a representation and not how the actual CMS looks, so treat screenshots as illustrative rather than exact.

Editorial workflow: draft, review, publish

Decap supports an editorial workflow that moves content through clear statuses before it goes live. Instead of publishing straight to the main branch, content can pass through draft → review → publish, letting teams keep quality controls without bolting on a separate workflow tool.

Because this runs on Git, those statuses map to branches and pull requests. That means:

• Reviewers can inspect changes in the same system the team already uses.
• Deployment checks and branch workflows apply to content the same way they apply to code.
• Nothing publishes until the workflow allows it.

Git-native history and ownership

Every content change is a commit. Content lives in your own repository — not locked to a provider's database — so you get full version history, branch workflows, and deployment checks in one place. This is the core trade-off: you own the content and its history, but you also own the repository and the build pipeline behind it.

Configuration and extensibility

The entire CMS is configured through a single config.yml file. Developers declare collections, fields, workflow rules, and media handling declaratively, without writing code for the basics.

When defaults aren't enough, Decap is extensible:

• Custom widgets (shortcodes) for specialized field types
• Editor components to change how editing works
• Plugins for broader behavior

Who this fits

Decap CMS is MIT-licensed and described as free and self-hosted. If your project is Git-backed and static, the editing and workflow model above is what you'd be adopting; if you need a hosted database-backed CMS with no repository involved, this isn't that.