Which static site generators and Git providers work with Decap CMS?

Decap CMS works with any static site generator and all major Git providers, because it doesn't build your site or host your content — it edits files that live in your Git repository. If your site is generated from a Git-backed repo (Hugo, Next.js, Gatsby, Jekyll, and similar), Decap can sit on top of it as the editorial layer. The only real requirement is that your content is stored as files in a Git repo, not in a separate database.

Static site generators

Decap is designed for Git-backed static and Jamstack architectures. The documentation names these workflows explicitly:

• Hugo
• Next.js
• Gatsby
• Jekyll

The pattern is the same across all of them: your content lives as Markdown, MDX, JSON, YAML, or similar files in the repo, and Decap reads and writes those files through a config you define. Because Decap is generator-agnostic, the list above is illustrative rather than exhaustive — if a generator reads content from files in a Git repo, Decap can typically manage that content.

What matters more than the generator is your content model. Decap lets you define collections, nested structures, relation fields, and slug behavior, so the CMS matches your project instead of forcing a fixed schema. That flexibility is what makes it portable across stacks.

Git providers

Decap is Git-native: content stays in your own repository with full version history, branch workflows, and deployment checks in the same system your team already uses. The site states it supports all major Git providers, and ownership stays with you — content is not locked to any provider's database.

Practical implications:

• Version history comes from Git itself, so every editorial change is a commit.
• Branch workflows let drafts and reviews happen on branches before merge.
• Deployment checks run in the same pipeline your developers already use.

How the pieces connect

Configuration in one file

The entire CMS is configured with a single config.yml file. Decap's declarative configuration lets developers set up collections, fields, workflow rules, and media handling without writing code. This is the main integration step: point Decap at your repo, describe your content types, and the editor UI is generated from that description.

For editorial teams, that config also drives the editorial workflow — content moves through draft, review, and publish statuses before going live, so quality controls don't require a separate tool.

When this fits — and when it doesn't

Decap is strongest when you want:

• An efficient developer and editorial experience
• A Git-native implementation
• Ownership over your content
• A flexible, extensible platform

It's a good match if your team already works in Git and your site is generated from files. It's a weaker match if your content must live in a hosted database, or if you need a CMS that manages content independently of a repository.

Extending beyond the defaults

If the default fields aren't enough, Decap supports custom widgets (shortcodes), editor components, and plugins. This matters when your content model has special requirements — for example, a custom block type in a rich text field, or a widget that pulls from an external source.

Getting started

The site describes getting started as "simple and free," and Decap is MIT-licensed — free today and intended to remain free. The practical path is:

1. Confirm your content lives as files in a Git repo.
2. Add a config.yml describing your collections and fields.
3. Connect Decap to your Git provider.
4. Let editors work through the web UI with structured fields, rich text, and live preview.

For the exact configuration options and provider-specific setup, the Decap docs are the authoritative reference — the config schema is where generator and provider details actually get wired together.