Comparison

next-md-blog targets teams who want posts as markdown files in git, App Router pages they own, and SEO helpers without adopting a full CMS or a heavy codegen pipeline. This page compares common approaches; trade-offs depend on your team size, editorial workflow, and how much you want generated types.

Feature overview

“No meta file” — what we mean

• Per post: you do not need a second file (for example my-post.meta.json or my-post.yaml) next to my-post.md. Title, date, description, tags, authors live in frontmatter at the top of the markdown file.
• No mandatory generated cache for the content graph: the core path is read markdown from disk at request/build time (with familiar Next caching patterns), not “compile all documents into a parallel database” — though you can still add your own caching layer if you need it.
• Site-wide: you typically keep one next-md-blog.config.ts for defaults (site URL, default author, author directory). That is blog config, not a per-post meta file sprawl.

When next-md-blog is a strong fit

• You already want markdown in the repo and PR-based publishing.
• You want Server Components and normal App Router files, not a framework inside the framework.
• You prefer one file per post and minimal moving parts over maximum generated type safety from a pipeline.

Quick answers

next-md-blog vs Contentlayer

Contentlayer compiled your Markdown into generated types and a .contentlayer cache via a required build step, and the original project is no longer actively maintained. next-md-blog has no required codegen and no generated cache — it reads Markdown from disk in Server Components and keeps frontmatter as the only per-post metadata surface.

next-md-blog vs Velite

Velite is a modern “build step → typed content” tool: you run velite build to emit typed data/* modules. Choose Velite for strict generated schemas and maximal type safety; choose next-md-blog if you’d rather skip the extra build artifact and read files directly with built-in SEO, RSS, and sitemap helpers.

next-md-blog vs next-mdx-remote

next-mdx-remote renders MDX strings (e.g. from a database) and leaves storage, metadata, and SEO to you. next-md-blog is filesystem-first and batteries-included — pick next-mdx-remote when content lives remotely or you want the smallest possible abstraction.

next-md-blog vs a headless CMS

A headless CMS (Sanity, Payload, Contentful) is the better fit when non-developers publish daily and need dashboards, previews, and roles. next-md-blog keeps content in git with a PR-based workflow — ideal for developer-owned blogs and docs.

When to consider something else

• Velite / similar if you want generated data/*.json or TS modules, strict schemas, and a single velite build as the source of typed content — at the cost of an extra build step and output artifacts.
• next-mdx-remote if you need remote MDX strings (e.g. from a DB) or you want the smallest possible abstraction and will implement everything else yourself.
• A CMS if non-developers publish daily, you need workflows, previews, and permissions, or content should not live primarily in git.

Notes on maintenance and ecosystem

Tooling around Next.js changes quickly. Contentlayer was widely used but the original project is no longer actively maintained; community forks exist. Velite is a modern alternative in the same “build step → typed content” space. next-md-blog deliberately stays smaller: filesystem in, React + SEO helpers out, with frontmatter as the only post-level metadata surface you must maintain.

← Back to Home · Getting started · Configuration