Databases are the default answer for content management, but for a single-author blog they're usually overkill. Every post here is a plain markdown file in the git repository — and the admin panel is just a friendly window into that folder. This post explains the whole pipeline.
The stack#
- Markdown files with frontmatter live in
content/posts/. Each file is one article; the filename is the URL slug. - Next.js reads them at build time, generates fully static pages, and ships them from a CDN.
- The admin editor saves posts by committing to GitHub via its API. The commit triggers an automatic redeploy.
- No database anywhere. Your content lives in version control, which you already back up, diff, and can edit by hand.
What a post file looks like#
Every article starts with frontmatter between two --- lines:
---
title: "Your Post Title"
description: "One-sentence summary used for SEO and previews."
date: "2026-07-28"
category: "Blogging"
tags: ["markdown", "workflow"]
coverImage: "https://example.com/cover.jpg"
draft: false
featured: false
---
Everything after that is regular markdown: headings, lists, tables, code blocks with syntax highlighting, images, links.
Why this beats a database for small sites#
Portability. Content is text files. grep, editors, scripts, and any future platform can read them forever.
Version history for free. Every save is a commit. Made a bad edit? Revert it. Want to see what changed since March? Diff it.
Speed and SEO. Static pages render in milliseconds, get perfect Core Web Vitals scores, and crawlers see complete HTML every time.
Zero infrastructure. Nothing to patch, back up, or pay for beyond hosting itself.
The publishing flow#
- Open
/adminand log in. - Paste your AI-generated draft (or write from scratch) into the editor. The right pane previews exactly what readers will see.
- Fill in title, description, tags, and category. The slug generates automatically from the title.
- Hit Publish. If GitHub credentials are configured, the file commits to your repository; otherwise (running locally) it's written straight to disk.
- Your host's deploy webhook detects the commit, rebuilds, and your article is live — typically within a minute.
Editing and deleting#
The dashboard lists every post including drafts. Drafts (draft: true) are invisible to readers but visible to you, which makes them perfect for half-finished ideas. Deleting a post removes the file via the same GitHub API — again creating a revertible history entry rather than destroying data.
When not to use this approach#
Git-based publishing shines for blogs up to a few thousand posts with a handful of authors. If you need comments, user accounts, per-post view counters, or many editors working simultaneously, introduce a database or a dedicated CMS. But if you're one person publishing great articles — especially drafts coming out of an AI chat window — files plus git is refreshingly simple.
Try it#
This blog ships with everything above preconfigured. Set three environment variables (GITHUB_TOKEN, GITHUB_REPO, GITHUB_BRANCH), deploy, and you have a professional publication pipeline where "publish" means "commit".
