from obsidian to jekyll

the notes, the articles and even the portfolio start in obsidian. getting content from one to the other without losing my mind or my wiki-links was the main technical problem i needed to solve. here’s how i cobbled it together.

something else

the problem

Obsidian uses its own flavor of markdown. wiki-style [[links]], ![[embeds]], callouts, and a few other things that jekyll doesn’t know about. i could strip all that out before publishing, but then i’d lose the linking — which is the whole point of the garden.

i needed something that could translate Obsidian markdown into something Jekyll can render, without requiring me to maintain two copies of every note or manually convert things.

the plugin

i’m using a Jekyll plugin to handle the conversion. it processes Obsidian-style [[wiki-links]] and turns them into proper markdown links at build time. the plugin resolves link targets against the collection of notes, so if i link to [[some note]] it finds the matching file and generates the right URL.

it also handles backlinks — for each note, the plugin generates a list of other notes that link to it. this means the garden’s link graph works in both directions without me having to maintain anything manually.

the workflow

the actual publish flow is intentionally low-tech:

  1. write and edit in Obsidian, in my private vault
  2. when something is ready (or ready enough), move or copy it to the Jekyll source directory
  3. the air gap is deliberate — nothing auto-publishes from my vault
  4. commit, push to the private repo
  5. merge to the public repo when i’m ready for it to go live

there’s friction at every step and that’s by design. i don’t want to accidentally publish half-finished thoughts or private notes. the air gap between the vault and the repo is the safety net.

frontmatter conventions

Obsidian notes get some extra frontmatter before they go public:

---
title: the note title
status: seedling | growing | evergreen
tags: [some, tags]
date: 2026-04-02
---

the status field drives the garden UI — seedlings get a visual marker so visitors know the note is rough. the plugin picks this up and adds it to the rendered page.

what i’d change

the manual copy step is the weakest link. i’ve thought about writing a script that diffs my vault against the Jekyll source and shows me what’s changed, then lets me selectively stage notes for publishing. haven’t built it yet. for now the manual process keeps me honest about what goes public.

i’ve also got ideas about a pre-commit hook that checks for broken wiki-links — notes that reference something that doesn’t exist in the public garden. that would catch the case where i link to a private note and forget to publish it.

resources

if you’re setting up something similar, the key pieces are the Jekyll plugin for wiki-link resolution, a clear frontmatter convention, and some discipline about what leaves your vault. the tooling matters less than the workflow.

this post is referenced from the colophon page.