We tried Obsidian at work. Over Git.

I still think it is a great tool. But that experiment taught me something.

Setting it up for a team means everyone needs to install Git, clone a repository, install Obsidian, and configure the vault โ€” before they can open a single page. For someone who just wants to take notes in a meeting, that is a lot to ask.

Two weeks in, some colleagues still had not done it. Not because they did not care. The path from “I need to write something” to “I can actually write something” was just too long.

The moment it really clicked was during a team Plenum. A colleague was moderating and needed somewhere to capture what was being said. He asked me to send him a link.

I sent him a GitLab URL.

He needed a browser tab. I sent him a repository link that he had never cloned. That was it for me.


Where Obsidian genuinely works well

Obsidian is built for one person who thinks deeply about their own notes. The local-first approach, the plugin ecosystem, the graph view โ€” all of that is designed around a single author with full control over their own vault. For that use case, it is hard to beat.

The file-based storage is also genuinely good design. Plain Markdown on disk. No proprietary format, no database, no lock-in. You can open any file in any editor, grep through everything, put the vault in Git. The content is always yours and always readable without the app.

That philosophy is something I wanted to keep.

Where it breaks for teams

The Git-based collaboration model is the core issue. For developers who already live in the terminal, it is manageable. For everyone else, it is a setup project before the actual work can start.

A few things that come up quickly in a multi-user Obsidian setup:

Onboarding takes too long. Every new person needs Git, needs to clone the repo, needs Obsidian installed and pointed at the right folder. That is three steps before anyone has written a single word.

Conflicts happen. Two people editing the same file at the same time produces a Git merge conflict in a Markdown file. Most people on a team are not equipped to resolve that.

There is no URL to share. When someone asks “can you send me the link to that page”, the answer is a GitLab or GitHub URL โ€” not a page someone can open and edit in a browser. That is the wrong answer for documentation.

Obsidian Sync does not solve the team problem. The paid sync service ($10/month per user) solves the device sync problem for individuals. It does not give you a shared workspace with roles, access control, or a browser interface your non-technical colleagues can use without installing anything.

What a team actually needs

A URL. A place where a colleague can click a link, open a page, and start writing โ€” without installing anything first.

The content can still be Markdown files. Storage can still be on disk. But it needs to live somewhere central, managed, accessible through a browser.


That is the problem LeafWiki is trying to solve. Content is stored as plain .md files โ€” same philosophy as Obsidian, no external database. If you already have an Obsidian vault, the importer migrates it including [[wikilinks]]. After that LeafWiki handles the structure, search, assets, and access.

Your colleagues get a URL. They open it. They write. That is the full setup on their end.


Try the demo โ€” resets hourly. Or check the GitHub repo if you want to run it yourself. If you’d rather skip the server entirely, LeafWiki Hosted is launching autumn 2026.

Tags obsidian team-wiki self-hosting wiki markdown comparison