Can Obsidian be a team knowledge base? Only if everyone reads everything

A knowledge base always has two kinds of people in it. There are the people who write it, a handful who know the material and keep it current, and there are the people who only read parts of it, which is usually everyone else. Any tool that is going to hold a team's knowledge has to tell those two groups apart, and it has to do it per folder, because the hiring loop and the deploy runbook are not the same secret.

Obsidian has two products aimed at teams. Sync makes everybody a writer. Publish makes everybody a reader. Neither of them splits on the line that actually matters, and no combination of the two gets you there either. That is the whole finding of this post, and it is why Baalda, the app this site is for, is built around a server that resolves one person's access to one file rather than around a faster way to copy a folder.

Can Obsidian be a team knowledge base?

It can, for a team where everyone is allowed to read everything.

That sounds like a narrow case and it is not. A four-person startup, a research group, a two-person agency: plenty of teams genuinely have no internal boundary, and for them Obsidian is an excellent answer and costs very little. Obsidian has also been free for work since 20 February 2025, when the commercial licence became optional. The announcement is one sentence long: "Starting today, the Obsidian Commercial license is optional." The licence still exists at $50 per user per year as a way to support the project, but nobody has to buy it.

The question is what happens on the day somebody has to not see something. That day is when most teams discover which product they actually bought.

What does Obsidian Sync give a team?

Obsidian's own help pages are unusually direct about this, which makes it easy to check before committing.

• Everyone pays. "All collaborators must have an active Sync subscription to access a shared vault." Sync is $4 per user per month billed annually, $5 monthly. A ten-person team is $480 a year before anyone has published a page.
• Twenty people, maximum. "The maximum number of collaborators on a shared vault is 20 users."
• Everyone has the owner's access. "All collaborators receive the same permissions as the vault owner, with one exception: only the vault owner can invite collaborators." There is no viewer role and no folder scope. The unit of sharing is the vault.
• Nobody edits together. "Obsidian does not yet support collaborative live editing on the same file. You will not see the other user's cursor, and their edits will only appear once the changes are synced."
• No on-premises option. The teams page states plainly that "Obsidian Sync does not have an on-premises solution at this time."

None of that is a flaw in Obsidian. Obsidian is a local editor reading a folder on disk, and a local editor has nothing in the path between a person and a file that could refuse. Sync is a file transport, and a file transport moves whole folders. We went through why that is structural rather than a missing feature in why Obsidian per-file permissions need a server that can say no.

What does Obsidian Publish give the readers?

A real website, which is more than most of its competitors manage, and exactly one lock on the front door.

Publish is $8 per site per month billed annually, $10 monthly, and the pricing page describes what you get: "No technical knowledge required", custom themes, and "Graph and full text search". That last part is worth saying out loud because it is genuinely good. A Publish site is browsable and searchable by someone who has never installed Obsidian and never will.

The access model is where it stops. You can apply a site password, and you can add several passwords with nicknames so you can hand different ones to different people. But the security page is explicit about the limit: "Individual password protection for published notes is currently not supported." There are no user accounts, no SSO, and no way to give one reader a subset of the site. Removing the password makes the whole thing public again, in Obsidian's own words: "If you decide to remove the site password later, the entire site will become visible to the public again."

So Publish is one site, one boundary, all or nothing on either side of it.

Why do Sync and Publish not add up to a knowledge base?

Because they divide the same way, and it is the wrong way.

Run a real team through that table and the gaps show up fast. The contractor who needs the API docs and nothing else. The new hire who should read the engineering handbook before they are in the salary thread. The designer who should see the product folder but not the hiring loop. The security runbook that everyone should read and three people should edit.

Each of those is one person, one folder, one level, and there is no arrangement of Obsidian products that expresses it. The workaround everyone lands on is more vaults: one vault per boundary, each with its own Sync subscription slot and its own copy of anything that belongs in both. That works, and it degrades exactly as fast as the number of boundaries grows, because a note that belongs in two vaults is now two notes.

What do teams build instead, and does it work?

Obsidian's own teams page sends you to the alternatives: because the notes are plain text, you can use "version control systems such as Git, network attached storage systems, and many services such as Dropbox, Google Drive, and more."

That is where the interesting community work is. Covault is the best current example, and it deserves credit rather than a dismissal. It describes itself as a "Team knowledge base client for Obsidian. Share, consume, and evolve your team's knowledge through silently synced shared folders." It is backed by GitHub repositories, it hides the version control completely (an LLM agent "handles all the git plumbing so you never have to think about commits, branches, or merges"), and it uses a model to resolve conflicts when two people edit the same content. If your team is already on GitHub and your boundaries line up with repositories, this is a real answer and it is free.

Notice what it is doing, though. Git repositories are the permission layer. That gets you a boundary per repository, which is better than a boundary per vault, and it is still a boundary per container rather than per file. It is also still not live editing: the README describes conflict resolution after the fact, not two cursors in one paragraph.

Every one of these approaches, Git included, is a better way to move the file around. None of them puts anything in the path that can decline to hand the file over.

What has to be in the path instead?

Something that resolves a question rather than copies a folder: given this person and this file, right now, what may they do?

In Baalda that is a server-side resolver, and it runs on every request rather than at invite time. The order it resolves in is the whole design:

edit > view > none

1. vault owner or admin    -> edit on everything, unless the vault's
                              posture withdraws it (Read-only, or sealed)
2. otherwise take the MAX of:
     a share on the file itself
     a share on any containing folder, walking parents to the root
     a vault-wide grant (Open / Read-only, or a per-user level)
3. folder grants inherit to descendants
   a file share can only RAISE permission, never lower it
   no matching grant -> none

Two details in there do the work people actually want. A grant on a folder inherits down, so "the engineering handbook, read only, for everyone" is one setting rather than a hundred. And a per-user deny is absolute and applies to owners and admins alike, so "everyone except this contractor" is expressible without building a second vault to express it.

The rest of the stack is the part that makes it a knowledge base rather than an access-control list. Notes are plain .md files in a folder on every member's own disk, so the thing you are permissioning is still a file you can grep, back up and open in any editor. Editing is real-time through a CRDT, with cursors and presence, which is the specific thing Obsidian says it does not do. The whole app is Apache-2.0 and the backend is self-hostable, which is the on-premises answer Sync does not have. It is $0 forever if you run it locally or host the backend yourself, and $10 per vault per month, or $97 a year, for the managed backend. Per vault, not per person, which is a different shape of bill from $4 per user per month once a team is more than a few people.

For readers who will never install anything, a note can be given a public link. The server mints a token, the page is read-only in any browser, and turning the switch off revokes it so the old URL stops working. See how multiplayer editing works on the same markdown files for the editing half, and Baalda vs Obsidian for the feature-by-feature version of this comparison.

Where does Obsidian still win, and where does Baalda not help?

Three places, and one of them is this post's own subject.

Publish is a better reading surface than anything Baalda has. A Publish site is a whole navigable website with full-text search and a graph, for $8 per site per month, readable by anyone with a browser. Baalda's public link is one note, one URL, no index and no search, and "anyone with the link" rather than a named reader. If the main job of your knowledge base is to be read on the web by people outside the team, Publish is the right tool and this post is not an argument against it.

Obsidian's plugin ecosystem is not close to matched. Years of community plugins, themes, Canvas, Dataview, and a library of workflows. If your knowledge base depends on three plugins, that is a real reason to stay.

Neither is a wiki. If what you want is page trees, a navigation sidebar and a structured hierarchy that non-technical people browse, you want a wiki, and we went through which ones keep your markdown on a filesystem in Confluence alternatives that use markdown. Wiki.js in particular syncs its content to Git or local disk continuously while people work in it.

And for one person, Obsidian is simply the better app. The argument here starts at the second person, and it gets sharper with every boundary after that.

How should you decide?

Four questions, in this order.

1. Does everyone on the team get to read everything? If yes, use Obsidian Sync and stop here. It is cheap, mature and good.
2. Is the main audience readers rather than writers? If yes, Obsidian Publish or a wiki. A permission model you do not need is a cost.
3. Do your boundaries line up with Git repositories? If yes, look hard at Covault before you buy anything.
4. Do you need one person to have one level on one folder, while everyone edits live? That is the case none of the above covers, and it is the one Baalda was built for.

The honest summary is that "Obsidian as a team knowledge base" is not one question. It is a question about how many internal boundaries your team has. At zero, Obsidian wins outright. At one, you start making copies. At three or four, the copies are the knowledge base, and that is the point at which you want a server in the path rather than a faster way to copy the folder.