The Vault Is the Website

nelson.love publishes itself out of an Obsidian vault. Here's how that works—and what it was like to build it with an AI agent reading my notes over my shoulder.

Most personal sites are a second place you have to keep alive. You think somewhere—a notes app, a doc, your own head—and then you re-enter it into the site: its repo, its format, its notion of what a "post" is. The site is a chore precisely because it's a copy, and the copy starts rotting the instant your real thinking moves on without it.

This one is built the other way around. The content doesn't live in the website. It lives in my Obsidian vault—the same place I already keep essays, project notes, and a whole Johnny-Decimal filing system—and the site is just a rendering of it. I edit a note, click a button, and a minute later it's live. There's no second home to synchronize, because there's only one home. The website is a view.

How it works

The trick is a hard separation between content and formatting. The content is markdown in the vault: a folder of "work" notes, a folder of posts, another of projects, a home page written as plain prose with a hero and a spec-rail, plus a handful of essays elsewhere that I flag collection: essays when they're ready. None of that knows anything about HTML.

The formatting lives in a separate little repo—an Eleventy static site. Two dependencies, one stylesheet, three templates. It has a "datasheet" look: warm paper, a vermilion accent, a serif display face over a monospace one, everything laid out like a precise engineering spec sheet. That repo has almost no content of its own; it's a set of molds.

Between the vault and the molds sits a small Obsidian plugin. Click Sync nelson.love and it walks the designated folders, reads each note, and translates it into exactly the shape the templates expect—mapping my authoring conventions (an Order line, a status, a tag list written with middots) into the frontmatter Eleventy wants, resolving links, stripping the redundant title heading where the template already prints one. It writes the result into the Eleventy repo, shows me precisely what will be added, changed, and deleted, and—once I confirm—commits and pushes. (Lately I keep the button in dry-run and let an agent do the actual shipping through the same transform; the shape of the loop is unchanged.) The push trips a GitHub Action that builds the site and ships it to Cloudflare. Edit → click → live. The vault stays the single source of truth; the published site is always downstream of it.

How we built it

This is the part I didn't expect to be interesting, and it was the best part.

It started as a plain question—what would it take to host something at nelson.love—and turned almost immediately into archaeology. There was already a site there, a dark Astro build I'd half-forgotten. But buried in the vault was something stranger: a note-to-self, months old, describing a different site I'd apparently designed and never shipped—an Eleventy "datasheet" redesign, complete with a decision log explaining why, the content already written, and a plan for a vault-to-site sync script. I had left myself instructions and then not followed them. The agent found them before I remembered they existed.

So instead of arguing about direction in the abstract, we made it concrete: stood up three live test sites side by side—the old Astro one, a Quartz "digital garden," and a reconstruction of the datasheet design—and just looked at them. Seeing beats theorizing. The datasheet one was obviously right; it was the thing I'd meant to build.

The catch was that the original datasheet bundle was gone from disk—only the note describing it survived. So the agent rebuilt it from the spec and the content I'd already authored: a faithful reconstruction of a design I'd lost. Then, deciding to keep it, we rebuilt the sync too. And here the collaboration did something I found genuinely useful. The plugin shipped with a self-test that regenerated the site from the vault and diffed it against what was actually live. The diff wasn't clean—and the reason it wasn't clean was the honest finding of the whole project. The reconstructed site had quietly drifted from the vault: essays that were never flagged, posts with no source note, hand-edited titles the vault didn't know about. The tool didn't paper over that. It told me exactly where my source of truth and my published surface had come apart, so I could bring them back together on purpose.

There was plenty of friction that never makes it into the tidy version. A firewall on my machine kept silently blocking deploys, so the agent had to notice that curl worked where the deploy tool didn't and route around it. The shell flaked on basic commands. We renamed and pivoted more than once. None of it was frictionless—but the shape of the work was steady: I brought the vault (years of accumulated notes and structure and taste, plus the buried intent) and made the calls; the agent brought the building, the exploring, the willingness to stand up throwaway sites and reverse-engineer a deploy protocol, and—crucially—the discipline to surface what was actually true rather than what was convenient.

Why it's worth it

The payoff isn't really the datasheet look or the one-click button, nice as those are. It's that the website stopped being a separate thing to maintain and became the published face of a system I already tend. My notes were always the real artifact; now some of them simply have a public surface, and keeping that surface honest is the same act as keeping my notes honest.

And building it with an agent turned out to be a kind of collaborative archaeology of my own intentions—a partner patient enough to read the whole vault, recover the plan I'd abandoned, rebuild what I'd lost, and hand it back working, with a clear-eyed note about everywhere the copy had drifted from the original. Which is exactly the discipline the whole thing is built to enforce: don't keep two versions of the truth. Keep one, and render the rest.