Netlify’s Git-based workflow for Decap CMS is surprisingly more about managing code than managing content.
Imagine you’re building a website with Decap CMS. You’ve got your site files (HTML, CSS, JS) and your content files (Markdown, YAML, JSON) all living in a Git repository. When a content editor makes a change through Decap CMS, it doesn’t directly edit files on a server. Instead, Decap CMS commits those changes to your Git repository, just like a developer would. Netlify then sees this new commit and triggers a new build and deploy of your entire website. This "Git-based" approach means your content changes are treated as code changes, inheriting all the benefits of Git: version history, branching, and rollbacks.
Let’s see this in action.
Here’s a typical config.yml for Decap CMS, defining a "Post" collection:
backend:
name: github
repo: your-github-username/your-repo-name
branch: main # Or your primary branch
media_folder: static/images
public_folder: images
collections:
- name: "posts"
label: "Posts"
folder: "_content/posts"
create: true
slug: "{{year}}-{{month}}-{{day}}-{{slug}}"
fields:
- {label: "Title", name: "title", widget: "string"}
- {label: "Publish Date", name: "date", widget: "datetime"}
- {label: "Body", name: "body", widget: "markdown"}
- {label: "Tags", name: "tags", widget: "list"}
When you log into Decap CMS (usually at /admin/), you’ll see an interface generated from this config. If you create a new post, you’ll fill in fields for "Title," "Publish Date," "Body," and "Tags."
After you hit "Save" in Decap CMS, it constructs a Git commit. For example, if you created a post titled "My First Blog Post" on October 27, 2023, the commit message might look like: Add <Post Title> for Posts. The actual content file would be created in your repository at _content/posts/2023-10-27-my-first-blog-post.md (based on the slug pattern).
Netlify, watching your repository, detects this new commit. It then checks out the latest code, runs your build command (e.g., npm run build), and deploys the resulting static site. The new content is now live.
The core problem this solves is separating content management from deployment infrastructure. Traditionally, a CMS would require its own database and server-side logic. With Decap CMS and Netlify, your content lives alongside your site’s code in Git, and Netlify handles the hosting and deployment of the static site generated from that code and content.
This means you can use any static site generator (Gatsby, Hugo, Eleventy, Astro, etc.) and have a user-friendly interface for non-technical users to manage content without touching the build process or deployment.
The "Decap CMS" part is essentially a front-end application that interacts with your Git provider (GitHub, GitLab, Bitbucket) via their APIs. It handles user authentication, displays forms based on your configuration, and then uses the Git API to create commits, push them to your repository, and even create pull requests if you configure it that way. Netlify’s role is to monitor the repository for new commits and trigger builds.
Think about the power of this:
- Version Control for Content: Every piece of content has a full history. You can see who changed what, when, and revert to previous versions with a
git revert. - Staging and Branching: You can create Git branches for content drafts, test them on Netlify’s preview deployments, and merge them when ready.
- Developer Workflow: Content updates become part of the standard Git workflow, fitting seamlessly into CI/CD pipelines.
- Static Site Benefits: You get the speed, security, and scalability of static sites.
The most surprising thing is how Decap CMS manages user authentication without a dedicated user database. It leverages your Git provider’s authentication. When a user logs into Decap CMS, they are essentially authorizing the Decap CMS application to access their Git repository on their behalf. The CMS then uses this authorization to perform Git operations. It’s a clever way to delegate authentication and authorization to a trusted third party (your Git host).
The next logical step is to explore how to implement custom widgets for Decap CMS to handle more complex content types.