How to Grow a Digital Garden in Plain Markdown

A digital garden is a collection of notes you tend over time, linked by topic instead of date, and published while still imperfect. You start one as a folder of plain Markdown files you own. The model is the practice; the plain files are the soil. Keep the soil, and the garden can be planted anywhere.

A blog asks you to be finished. Each post is dated, polished, and frozen — so a half-formed idea sits in drafts until it rots. The digital garden is the antidote: a place where notes are allowed to be partial and to keep growing.

The phrase traces to Mike Caulfield's 2015 essay "The Garden and the Stream," which framed the contrast the whole movement later inherited ¹. Maggie Appleton codified the ethos five years on ². The trap in most "how to start a digital garden" guides is that they wire the idea straight to a tool, so your writing inherits the tool's lock-in. This guide starts one layer down.

What is a digital garden?

A digital garden is a collection of evolving notes organized by topic rather than by publication date, written to be revisited and revised instead of finished once. Notes link to each other through meaning, not chronology. They are published while still rough. The point is to think in public slowly, not to perform a finished post.

Maggie Appleton's definition is the canonical one:

"A garden is a collection of evolving ideas that aren't strictly organised by their publication date. They're inherently exploratory – notes are linked through contextual associations. They aren't refined or complete - notes are published as half-finished thoughts that will grow and evolve over time." ²

That last clause is the permission slip. A blog post that is 70% done is a failure — a garden note that is 70% done is simply a note that is still growing. The format changes what "ready" means.

How is a digital garden different from a blog?

A blog is chronological: posts appear newest-first, each one finished and dated. A garden is topological: notes connect by subject, and any note can be edited forever. The blog optimizes for the moment of publishing — the garden optimizes for the slow accumulation of linked ideas. One is a feed; the other is a map.

Appleton names this principle "Topography over Timelines":

"Gardens are organised around contextual relationships and associative links; the concepts and themes within each note determine how it's connected to others. This runs counter to the time-based structure of traditional blogs: posts presented in reverse chronological order based on publication date." ²

Caulfield drew the same line in 2015, before "digital garden" was a phrase anyone searched for. His framing is still the sharpest:

"The Garden is the web as topology. The web as space. It's the integrative web, the iterative web, the web as an arrangement and rearrangement of things to one another." ¹

He set it against the Stream — the feed, the timeline, the blog roll: "In other words, the Stream replaces topology with serialization. Rather than imagine a timeless world of connection and multiple paths, the Stream presents us with a single, time ordered path with our experience (and only our experience) at the center." ¹ A blog is a stream. A garden is a map you keep redrawing.

One honest caveat: a garden is a publishing model, not a tool. You can run a garden inside almost anything that renders Markdown. Owning a folder of files does not, by itself, make a garden — the tending is the work.

The trap: coupling the idea to a tool

The most common mistake in garden guides is binding the concept to one product on step one — pick this app, install this template, host on this platform. Do that and your writing inherits whatever the tool does to it: proprietary link syntax, a hosted silo, a hollow export button. The idea is portable. Most setups are not.

Appleton is blunt about where unportable writing ends up. Writing about the walled platforms most people pour their words into, she notes:

"None of them have an easy export button. And they certainly won't hand you your data in a transferable format." ²

That is the failure mode in one sentence. A garden planted on rented land is not yours; it is a tenancy. The way out is to decide what the durable layer is before you choose how to display it.

The substrate-first move: own the plain files

Start with the substrate: a folder of plain Markdown (.md) files on your own device. Markdown is readable text with no proprietary container, so any renderer can read it and no single tool can trap it. The links between notes are just text. The garden becomes renderer-agnostic: you change how it is displayed without migrating what you wrote.

This is the same instinct Steph Ango, Obsidian's CEO, calls "file over app." Plain files outlast the software that opened them:

"Apps are ephemeral, but your files have a chance to last." ³

Appleton agrees the ownership is the point of the whole exercise:

"Gardening is about claiming a small patch of the web for yourself, one you fully own and control." ²

A second honest caveat: "own your files" is not the same as "own a public garden." Publishing still means choosing a renderer and a host. The win is narrower and more durable than it sounds — your writing never has to migrate, only the renderer in front of it.

How to start a digital garden in Markdown

You can plant a garden in five steps, none of which require an account or a build pipeline. Make a folder. Write notes as plain .md files. Link them by topic. Mark each note's ripeness. Publish a subset when you are ready. Everything after that is tending.

1. Make one folder of .md files. One note per file, plain text, on your device. No database, no app lock-in — just files you can open anywhere.
2. Write notes, not posts. Drop the dateline and the "finished" pressure. A note can be three sentences and a question — that is a complete note in a garden.
3. Link by topic. When two notes touch the same idea, link them. The links are the garden's structure — its topology, not its timeline.
4. Mark ripeness in frontmatter. Use a small status tag so a reader knows what they are getting.
5. Publish a subset when ready. Tend privately first — expose only the plot that is presentable. The rest keeps growing offline.

The ripeness tag is the one convention worth adopting early. It is a self-disclosure about how finished a note is, a courtesy to readers and to your future self. A common scheme borrowed from gardeners and from Devon Zuegel's "epistemic status" idea uses three stages:

---
title: Spaced repetition and why I keep abandoning it
status: seedling   # seedling | budding | evergreen
planted: 2026-06-20
tended: 2026-06-20
---

A seedling is a raw thought I'm still unsure about.
A budding note has been revised once or twice and mostly holds together.
An evergreen note is stable enough that I'd point a stranger to it.

The tags are a convention, not a standard — there is no spec that defines "budding." That is fine. The frontmatter is just metadata at the top of a plain file, which means it travels with the note no matter what renders it. The mechanics of that metadata header are their own subject; this guide treats it as a place to record ripeness and moves on ⁴.

Common mistakes when starting a garden

Most failed gardens fail for the same handful of reasons, and all of them are avoidable on day one. The recurring errors are coupling to a tool too early, hiding behind "finished," over-engineering the structure, and treating links as decoration instead of as the actual map.

• Choosing the tool before the substrate. If your first decision is a platform, your writing is already negotiable. Decide the plain-files layer first — pick a renderer second.
• Waiting until a note is "done." A garden of only finished notes is a blog with extra steps. Publish seedlings. The status tag exists precisely so you can.
• Building a graph before you have notes. An elaborate folder taxonomy and a visualization plugin are procrastination in disguise. Links and one index note carry navigation far longer than people expect — start there ⁵.
• Treating links as garnish. In a garden, the link is the structure. A note with no links is a leaf with no branch — it disappears.

How the same files render anywhere

Because the notes are plain Markdown, the renderer is interchangeable. The same folder can be opened in a local editor, pushed through a static-site generator, or rendered by any tool that consumes .md. Your writing is the fixed point; everything downstream is swappable. You migrate renderers, never sentences.

flowchart TD
    A[Plain Markdown notes<br/>you own] --> B[Local editor<br/>read and tend]
    A --> C[Static-site generator<br/>publish as a website]
    A --> D[Any future renderer<br/>not built yet]
    B --> E[Same words<br/>everywhere]
    C --> E
    D --> E

Figure: one folder of plain Markdown notes feeds every renderer — a local editor for tending, a static-site generator for publishing, and any tool that does not exist yet. The writing is the fixed layer; the renderer changes without touching the words.

The static-site-generator end of that spectrum is alive and well. Quartz, one open-source example, describes itself as a way to "publish your digital garden and notes as a website for free" and is built as "a fast, batteries-included static-site generator that transforms Markdown content into fully functional websites" ⁶. As of June 2026 the project had over 12,000 stars on GitHub, last updated days earlier ⁶.

Note that "for free" is Quartz's claim about Quartz. The broader point is the category, not any one tool: many generators consume the same plain files, so naming one never locks you in.

How this fits with MNMNOTE

MNMNOTE is one place to tend the garden — the writing layer, not the publishing layer. Notes live as plain Markdown on your own device, work offline, and need no account to start. Sharing a plot, when you choose, is end-to-end encrypted. The static-site generators above are how you render the garden; the editor is where you grow it.

The reason this matters is the substrate argument, not a feature list. If the words are plain .md files you hold, then the question of which tool you use today stops being a trap. You can tend the garden in one place, render it in another, and move either one — without rewriting a single note.

Frequently asked questions

What is a digital garden? A digital garden is a collection of evolving notes linked by topic rather than date, published while still imperfect and tended over time. It is a publishing model, not a product — closer to a wiki you keep revising than to a blog you finish and freeze ².

How do I start a digital garden in Markdown? Make a folder of plain .md files, write short notes instead of finished posts, link them by topic, mark each note's ripeness in frontmatter, and publish a subset when ready. No account or build pipeline is required to begin — only files you own.

Is a digital garden different from a blog? Yes. A blog is chronological and finished — newest post first, each one dated and frozen. A garden is topological and editable — notes link by subject and grow indefinitely. Caulfield framed it as the difference between a map (the garden) and a stream (the feed) ¹.

How do I publish my notes as a website I own? Keep the notes as plain Markdown, then point a static-site generator at the folder. Tools like Quartz turn .md files into a website ⁶; the key is that the renderer is swappable while the writing stays put. You publish the renderer's output, not your only copy.

What do seedling, budding, and evergreen mean? They are a ripeness convention, not a standard. A seedling is a raw, unsure note; a budding note has been revised and mostly holds; an evergreen note is stable enough to share with a stranger. The labels live in frontmatter so they travel with the file. Adapt the names freely.

Won't my garden get locked into whatever tool I pick? Only if you couple the idea to the tool. If the durable layer is plain Markdown you own, the renderer becomes interchangeable: you migrate how the garden is displayed, never what you wrote. Appleton's warning about platforms with "no easy export button" is the failure this avoids ².

A blog asks you to be finished. A garden lets you keep growing — and it stays yours only because the soil, the plain files, is yours. This guide builds on Mike Caulfield's 2015 framing and Maggie Appleton's ethos of the digital garden.

If you want a place to tend that garden, mnmnote.com keeps your notes as plain Markdown on your own device — open a tab and plant the first seedling.