Front Matter CMS: a headless CMS inside VS Code for Hugo, Jekyll and Next.js sites

The problem Front Matter CMS solves for static site authors

Static site generators give you speed and full control over output, and they take away the editing interface. Content lives as Markdown files with YAML front matter, and every new post means remembering which keys your theme expects, which folder the file belongs in, and which image path the build resolves. Front Matter CMS targets that gap. The README describes it as "a CMS that runs within Visual Studio Code" that keeps "the flexibility and speed of the static site generator of your choice".

The audience is specific: developers and technical writers who already use VS Code and whose content sits in the same repository as the site. The extension lists Hugo, Jekyll, Docusaurus, NextJs and Gatsby among the supported generators. If your content lives in a hosted database or a SaaS CMS, this is not aimed at you. The README also notes the extension is available in English, German and Japanese, with a documented path for adding more languages.

How the extension works: folders, front matter and a dashboard webview

Front Matter CMS activates on a workspace that contains a .frontmatter folder, which is one of the activation events in package.json. That folder is where the extension keeps its project-level configuration, and the repository itself ships one at the top level. A frontmatter.json file also sits in the repository root, which is the other configuration surface the project uses.

The dashboard arrived in version 3 as a webview, and the README describes its role as managing "all your markdown pages in one place", with search, filter and sort. Later releases added dedicated dashboards: media in version 5, data files and folders in version 6, snippets in version 7, and taxonomy for tags, categories and custom taxonomy in version 8. Version 10 added i18n and multilingual content management. The extension also runs SEO checks on title, description and keywords, and it previews the site inside VS Code rather than in an external browser. Extensibility is handled through a scripting hook: the repository contains a sample/script-sample.js file and an ssg-scripts folder, so custom behaviour is written in JavaScript against the extension rather than by patching it.

Installing Front Matter CMS and configuring a first project

The README points to the Visual Studio Marketplace listing under the identifier eliostruyf.vscode-front-matter, and the homepage frontmatter.codes carries the documentation. The extension declares an engine requirement of VS Code ^1.125.0 in package.json, so an older editor will refuse to install it.

Installation goes through the Marketplace listing, which the README links directly:

"publisher": "eliostruyf",
"name": "vscode-front-matter-beta",
"displayName": "Front Matter CMS",
"engines": {
  "vscode": "^1.125.0"
}

Those keys come from package.json in the repository and identify the extension and its minimum editor version. After installation, open your site repository as the workspace folder. The extension activates when it finds a .frontmatter folder, so an existing project that already uses Front Matter CMS will light up immediately. For a project that has never used it, the README describes a welcome view introduced in version 3 that walks through getting started. Once configured, the dashboard is the entry point for content: it lists your Markdown pages and lets you create, filter and sort them.

The preview runs the site inside VS Code, which means the extension needs to know how your generator starts. That mapping lives in the project configuration. The repository's own frontmatter.json is the reference example for the shape of that file, and the docs at frontmatter.codes cover the generator-specific settings. If preview does not start, the configuration is the first thing to check, not the extension installation.

Where Front Matter CMS is the wrong tool

The README is unusually direct about maintenance. A 2026 priorities update states that the author is focusing effort on creating a better revenue stream, that "Front Matter CMS will continue to be maintained" because he uses it daily, and that "major changes will only happen if there's a personal reason, a company commitment, or significant community support". Feature requests, the note says, may take longer to be addressed. That is a reasonable position for a solo maintainer, and it is also a planning constraint. Anyone choosing this extension for a multi-year content platform should read that paragraph before the feature list.

The second limit is structural. This is an editor extension, not a hosted CMS. Every person who writes content needs VS Code installed, the repository cloned, and the extension configured. There is no browser-based editorial login, no approval workflow, and no role model beyond whatever your Git host provides. A marketing team that wants to publish without touching a repository will find the whole model backwards.

A third limit is scope. The extension supports many generators, and the README concedes the obvious consequence: "we cannot support all use cases". Custom behaviour is expected to go through the extension mechanism and the JavaScript scripting hook, which means unusual front matter shapes or bespoke build steps are your code to write.

Front Matter CMS compared with a standalone headless CMS

The nearest alternative in practice is a standalone headless CMS such as a hosted content API, or a Git-based web CMS that commits to your repository for you. The difference is where the editing surface lives.

A hosted headless CMS stores content in its own database and serves it over an API. Your static site build pulls from that API at build time. Non-technical editors get a browser interface, and you get a content model that is independent of the repository. The cost is a second system: content and code drift apart, previews require wiring, and local development needs API credentials.

Front Matter CMS inverts that. Content stays as Markdown files in the repository, so a branch, a pull request and a review are the publishing workflow. There is nothing to authenticate against and no API to call at build time. The cost is that editing requires a development environment, and the content model is expressed in frontmatter.json and the .frontmatter folder rather than in a CMS admin panel. For a documentation site maintained by engineers, the repository-native model is usually the smaller commitment. For a blog with freelance writers, it is the larger one.

Licence and the cost of keeping it updated

The extension is MIT licensed, and package.json confirms the same. MIT is permissive: you can use it commercially, modify it and redistribute it, provided the copyright notice and permission notice are preserved. That is a statement about the licence text, not legal advice for your situation.

The upgrade cost is low by design. Releases are published to the Marketplace, and VS Code updates extensions on its own schedule, so consuming a new version is normally a restart rather than a migration. The version history shows a steady cadence through 2026, with v10.12.0 released on 2026-08-21, v10.11.0 on 2026-07-02 and v10.10.1 on 2026-04-23. The last push to the repository was on 2026-09-20.

The real maintenance cost is configuration drift. Because content types, taxonomies and preview commands are declared in project files rather than in a hosted schema, they are versioned with your site and need updating when your generator changes. The CHANGELOG.md in the repository is the place to check before upgrading across a major version, particularly between version 9 and version 10, where multilingual content management was introduced.

Editorial conclusion

Adopt Front Matter CMS if your content already lives as Markdown in a repository and you want editing, preview and SEO checks inside VS Code rather than a separate web CMS. Skip it if you need a hosted editorial interface for non-technical writers, or if you depend on a roadmap of frequent feature releases, since the README states major changes will only happen with a personal reason, a company commitment or significant community support. Before committing, verify your site's content folder and front matter format against the extension's configuration, and check that your VS Code version satisfies the engine requirement of ^1.125.0 declared in package.json.

Frequently asked questions

Official sources

1. estruyf/vscode-front-matter on GitHub
2. License: MIT
3. Project website
4. README
5. Releases