Publishing an Obsidian Vault as a Static Site

I keep a large personal knowledge base in Obsidian — plain markdown files in a folder — and I wanted a curated slice of it readable as a website: shareable, linkable, nicely rendered, but without giving up the thing I like most about the vault, which is that it’s just files I own. That last constraint turned out to be the whole design. The moment you frame it correctly — as a one-way publish problem, not a wiki problem — the right tools pick themselves and the wrong ones become obvious.

It’s a publish problem, not a wiki problem

The tempting move is to reach for a wiki platform — the kind with a nice web editor and a database behind it. It’s the wrong move here, and naming why saved me from a mistake. Those tools want to be the source of truth: content lives in their database, and their web UI is where you edit. But my source of truth is the vault — I edit in Obsidian, in markdown, in git. If I adopt a database-backed wiki, I’m now fighting it forever: round-tripping markdown into its format (lossy), keeping the vault and the database in sync (painful), and editing in two places (a mess). Those platforms are built for collaborative editing, which is a real need — just not this one.

What I actually have is a one-way flow: the vault is the truth, a curated subset gets pushed out, and a website renders it read-only. Nobody edits on the website. Once you see it that way, the whole category of “editing-surface” wiki tools is disqualified, and the right category is a static-site generator fed by the vault.

If you find yourself syncing your notes out of your notes app and back in, you picked a tool that wants to own your content. For publishing, you want one that just reads it.

The pieces that fit

The setup that respects “files are the truth” has three parts:

• A static-site generator that speaks your notes’ dialect. The good ones read markdown directly and understand the Obsidian-isms that matter — [[wikilinks]], backlinks, callouts, tags — so the published site feels like the vault (linked, navigable, even a graph) instead of a flattened export. The build reads files; it never becomes the authority.
• A curation gate in the frontmatter. This is the piece that makes it safe: a simple publish: true flag decides what ships. Everything is private by default; only notes I deliberately flag get built into the site. The vault stays complete and honest — including the scratch, the half-formed, and the sensitive — while the public site is a chosen subset. Private notes can’t leak by accident, because the default is don’t publish.
• A tiny web host and a build step. The generator produces plain static HTML, which is the easiest thing in the world to serve — a small web container, a static host, whatever. A build step (on a schedule, or triggered when I push) regenerates the site from the latest notes. No database, no server-side application, nothing to keep patched beyond a static file server.

The curation gate is the actual product

It’s easy to fixate on the generator, but the frontmatter flag is where the real design lives, because publishing from a personal knowledge base is a curation problem before it’s a technical one. My vault has plenty I’d never put on the internet — private context, unfinished thinking, things that just aren’t anyone else’s business. So “private by default, publish on an explicit flag” isn’t a convenience, it’s the safety model. Every note I write, I make a small deliberate call: does this belong on the public side or not? The site is only ever what I chose to share, and the choice is visible in the file itself.

That deliberate gate is also what keeps the published site good. A site that auto-published everything would be noise; a site that publishes only what I decided is worth sharing stays a curated thing — closer to a knowledge base that compounds than a data dump.

Keep publishing frictionless or it won’t happen

The last lesson is about sustainability. If publishing a note is a chore — export it, reformat it, paste it somewhere, fix the links — I simply won’t do it, and the site will rot to a snapshot of one enthusiastic afternoon. The whole appeal of the vault-fed static site is that publishing is flipping a flag and pushing, so keeping the notes current keeps the site current as a side effect. That’s not a small thing: docs go stale exactly when publishing them is hard, and the reason this setup stays alive is that the friction is nearly zero — the same reason I treat the whole vault as infrastructure worth maintaining rather than a pile I occasionally export.

The result is exactly what I wanted: I write in markdown, in my own vault, like always; I flag the notes worth sharing; and a website appears and stays current, mirroring the linked structure of the notes without ever becoming the place I have to edit. Files stay the truth. The site is just a view. If you’ve published a vault this way — or picked a different tool and have opinions — I’d like to compare setups.