A friend of mine needed a wiki for client documentation. Nothing complicated — pages, structure, a place for each client’s setup notes. Confluence came up first, because that’s the name everyone knows.
Two things killed it.
Confluence bills per invited user. Every client who needs to see their own page counts toward the bill. That adds up fast once you’re inviting people outside your own team.
The second problem was worse. Confluence doesn’t let you hide who else is invited. A client browsing the space can see the full list of other invited users — which means they can see who your other clients are.
My friend didn’t want that. Nobody publishing client-facing docs wants that.
The whole thing was maybe 50 pages. Not a huge wiki. Just one that needed an editor and a public door, without exposing who’s on the other side of that door.
Where Obsidian Publish fits, and where it doesn’t
If you already write in Obsidian, you’ve probably looked at Obsidian Publish for this. It turns a vault into a public website — clean output, your existing notes, no CMS to learn.
The pricing is fair: $8/month per site billed annually, $10/month billed monthly. No extra charge based on how many people read the site. I don’t think the price is the problem here.
The model is closer than I first thought — Obsidian Publish does let a site owner invite collaborators by email, and those collaborators get rights to publish and unpublish pages without touching site settings or permissions. So it’s not strictly single-editor.
What it doesn’t give you is a login-and-write account. Publishing still runs through your local vault: a collaborator needs that vault’s content synced to their own machine first — via Obsidian Sync (a separate paid subscription) or manually via git — before the publish button does anything. It’s collaboration bolted onto a local-first notes app, not a web account someone can use from any browser.
That’s fine if your team already lives in Obsidian and doesn’t mind vault syncing as the step before publishing. It’s a different model from an editor who just logs into a web app and writes.
What we actually needed: an editor account and a public door
The pattern in both cases is the same. Someone needs to write and maintain pages. Other people — clients, customers, the public — just need to read them, without an account, and without being visible to each other or to the person writing.
That’s the setup LeafWiki uses:
- Editors log in and write. Markdown, live preview, no different from any other page.
- Public read-only access means anyone with the URL can read, no account needed.
- There’s no invited-user list a visitor can browse. Public means public; everything else stays behind the login.
It runs as a single Go binary. SQLite instead of a database server. No Node.js, no Redis.
A smaller version of the same need
Someone described a similar case in one of our GitHub discussions: a client’s computer-repair shop needed a public FAQ and how-to page for customers who aren’t technical. No accounts, no login wall — senior-friendly was the actual requirement, not a nice-to-have.
Same shape of problem: one editor, a public docs site, no interest in a permission model built around a single vault owner.
Where this doesn’t fit
If your team wants to write collaboratively inside Obsidian itself — the plugin ecosystem, the graph view, local-first editing — LeafWiki isn’t trying to replace that. I’ve written separately about where that setup holds up and where it doesn’t.
And if your public docs really are a one-off, self-hosting a Go binary for it might be more than you want to manage. That’s a fair objection — it’s also why I’m building a hosted version.
If you’d rather not run the server yourself
LeafWiki Hosted is planned for autumn 2026: $6/month for a solo editor, $19/month for a team, viewers don’t count toward either. If that’s closer to what you need than either self-hosting or a single-vault-owner model, the founding member waitlist is open.
Try the demo — resets hourly. Or check the GitHub repo to self-host it.