Leafwiki Devlog #7: v0.6.1 - Introducing Backlinks + Better Search (SQLite FTS5) 🌿

#opensource #go #markdown #documentation

Hi!

It’s time for another update on LeafWiki 🌿

The new version v0.6.1 focuses on two things you use constantly in a wiki:

Search — fuzzy search & improved ranking
Backlinks / link UX — introducing backlinks

If you’re new here: LeafWiki is a lightweight, self-hosted Markdown wiki built as a single Go binary.

It’s for people who think in folders, not feeds.

LeafWiki stores everything locally — Markdown files on disk, plus a small tree file for structure and metadata.

If LeafWiki disappears tomorrow, your content is still yours.

👉 GitHub: https://github.com/perber/leafwiki

Backlinks

Backlinks are one of those features that turn a wiki into a knowledge base.

They also enable something important: showing the impact of moves and renames - because in a real wiki, pages don’t stay static forever.

LeafWiki follows an explicit approach here (similar to working in an IDE):
when you rename or move a page, you can decide whether links inside Markdown should be updated as well.

(Automatic link updates are planned for a future release.)

Backlinks answer questions like:

“Where is this page referenced?”
“Which docs depend on this decision?”
“What’s connected to this topic?”

What’s included in v0.6.1 (Backlinks & Links)

Incoming backlinks per page
Outgoing link list
Broken links are tracked (so you can see what needs fixing) (A dashboard / overview for broken links is planned for a future release.)
The link section was intentionally made less visually dominant, so your page content stays the focus

My goal is to make link navigation feel useful without turning LeafWiki into a graph tool.

This is the first release where I’m properly introducing backlinks — and I’d love feedback on how you use them.

Search improvements for a Markdown based wiki

Search is a daily driver feature — if search feels unreliable, a wiki slowly turns into a graveyard.

In v0.6.1, I focused on making search feel more reliable and practical during day-to-day use.

🛠️ Under the hood: local SQLite FTS5 (no external services)

LeafWiki is file-based, so search needs to be fast without requiring a separate DB server or Elasticsearch.

LeafWiki uses a local SQLite FTS5 index (search.db) and keeps it up to date.

A few implementation details for devs & self-hosters:

Parallel indexing: Markdown files are indexed using a small worker pool
Markdown-aware indexing: headings are extracted and indexed separately so important sections rank well
Relevance ranking: results are ordered with BM25 weighting (title > headings > content)
Better UX: highlighted titles and snippets/excerpts generated directly by FTS
Fuzzy-by-default: normal queries get * wildcards automatically

(Optional: tiny schema snippet)

CREATE VIRTUAL TABLE pages USING fts5(
  title,
  headings,
  content,
  tokenize = "unicode61 tokenchars '-_/+#.'"
);

Feedback welcome

Backlinks can be a deep rabbit hole (graphs, tags, multi-references, etc.).

LeafWiki tries to keep it simple — but useful.

So I’d love to hear:

Do you use backlinks in your documentation or more for knowledge management?
Should the link section be more prominent, or is the subtle approach better?

Thanks for following along 🌿

Try it out: https://demo.leafwiki.com

If you like the project, check it out on GitHub: https://github.com/perber/leafwiki