Last updated: March 21, 2026

Obsidian is a local-first Markdown editor built around a networked notes model. Most teams use it for personal knowledge management — but with the right setup, a shared Obsidian vault becomes a team knowledge base that is faster to write in than Notion, version-controlled via Git, and works offline by default.

Table of Contents

This guide covers: shared vault setup, folder conventions for teams, note templates, linking strategy, and publishing internal docs.

Why Obsidian for a Team Vault

The case for Obsidian over a SaaS wiki:

The trade-off: Obsidian requires more upfront configuration and more team discipline than a hosted wiki.

Vault Sync Options

Option 1: Git Sync (Free)

# Initial setup — one person creates the vault
mkdir ~/team-vault && cd ~/team-vault
git init
git remote add origin git@github.com:yourteam/team-vault.git

# .gitignore for Obsidian vault
cat > .gitignore << 'EOF'
.obsidian/workspace
.obsidian/workspace.json
.obsidian/plugins/
!.obsidian/plugins/list.json
.obsidian/cache
.trash/
*.bak
EOF

# Commit vault config (shared plugin list, themes, templates)
git add .obsidian/
git commit -m "init: team vault config"
git push -u origin main

Each team member clones the vault and installs the Obsidian Git plugin (community plugins). Configure auto-commit on vault close:

// .obsidian/plugins/obsidian-git/data.json
{
  "commitMessage": "vault: auto-backup {{date}}",
  "autoSaveInterval": 0,
  "autoPullInterval": 10,
  "pullBeforePush": true,
  "syncMethod": "rebase"
}

Option 2: Obsidian Sync ($8/mo per user)

Obsidian Sync handles real-time collaboration and version history without Git. It end-to-end encrypts the vault. For non-technical team members (design, marketing), this is easier than Git.

Enable in Settings → Core plugins → Sync, then create a remote vault and share it with teammates via email invite.

Vault Folder Structure

team-vault/
├── 00-inbox/           # unprocessed notes dumped here
├── 01-meetings/        # meeting notes by date
├── 02-projects/        # one folder per project
│   ├── project-alpha/
│   └── project-beta/
├── 03-people/          # one note per team member (async context)
├── 04-decisions/       # ADRs and decision logs
├── 05-runbooks/        # operational procedures
├── 06-reference/       # glossary, standards, API docs
└── templates/          # Templater templates (not indexed)

The 00-inbox folder is critical. Notes dumped without structure go there, not scattered in the root. A weekly review process moves inbox notes to their correct location.

Templates with Templater

Install the Templater plugin (community). Templates trigger on new note creation.

<%* /* templates/meeting.md */ %>---
date: <% tp.date.now("YYYY-MM-DD") %>
type: meeting
attendees: []
project:
---

# <% tp.file.title %>

## Agenda

-

## Notes

## Decisions

## Action Items

- [ ]

---
*Owner: <% tp.user.name %>*

<%* /* templates/decision.md */ %>
---
date: <% tp.date.now("YYYY-MM-DD") %>
type: decision
status: proposed
deciders: []
---

# ADR: <% tp.file.title %>

## Status

Proposed

## Context

What is the issue motivating this decision?

## Decision

What is the change we are making?

## Consequences

What becomes easier or harder after this decision?

<%* /* templates/runbook.md */ %>
---
date: <% tp.date.now("YYYY-MM-DD") %>
type: runbook
owner:
last-tested:
---

# <% tp.file.title %>

## Prerequisites

## Steps

1.

## Verification

## Rollback

Configure Templater to use these templates when creating notes in specific folders:

Settings → Templater → Folder Templates
01-meetings → templates/meeting.md
04-decisions → templates/decision.md
05-runbooks → templates/runbook.md

Obsidian’s power comes from [[wikilinks]]. Establish team conventions:

# In a meeting note — link to project and people
Discussed deployment timeline for [[project-alpha]] with [[jane-smith]] and [[mike-chen]].

# Decision references context
See [[ADR-012-database-choice]] for the original decision.

# Runbooks reference each other
After completing this runbook, follow [[deploy-rollback-procedure]].

Name files consistently so links work across notes:

# People notes: firstname-lastname.md
jane-smith.md

# Projects: project name kebab-case
project-alpha.md

# ADRs: numbered
ADR-012-database-choice.md
ADR-013-auth-provider.md

Dataview Queries

The Dataview plugin turns your vault into a queryable database. Add it to create automatic indexes.

<!-- In a "Projects Index" note -->
## Active Projects

```dataview
TABLE file.mtime AS "Last Updated", owner
FROM "02-projects"
WHERE status = "active"
SORT file.mtime DESC

Recent Decisions

TABLE date, status, deciders
FROM "04-decisions"
SORT date DESC
LIMIT 10

Runbooks Untested in 90 Days

TABLE last-tested, owner
FROM "05-runbooks"
WHERE date(last-tested) < date(today) - dur(90 days) OR !last-tested


These Dataview blocks update automatically as notes are created or modified. The runbook query flags procedures that have not been verified recently.

## Publish Internal Docs with Obsidian Publish

Obsidian Publish ($16/mo) renders selected vault pages as a website. Use it for docs you want accessible in a browser without Obsidian installed — onboarding docs, runbooks, API reference.

```bash
# Via CLI with obsidian-export (free alternative)
cargo install obsidian-export

# Export specific vault sections to static HTML
obsidian-export ~/team-vault/05-runbooks ./output/runbooks

# Or deploy the output to Netlify/Cloudflare Pages

Search and Discovery at Team Scale

As the vault grows past a few hundred notes, full-text search becomes the primary navigation method. Obsidian’s built-in Quick Switcher (Cmd+O) and global search (Cmd+Shift+F) cover most needs. Add the Omnisearch community plugin for better fuzzy matching across note body text and frontmatter.

For teams using Dataview, build a tag-based taxonomy early. Consistent frontmatter tags make filtered queries reliable:

---
date: 2026-03-15
type: runbook # meeting | decision | runbook | reference | project
project: project-alpha
owner: jane-smith
status: active # draft | active | deprecated
tags: [kubernetes, deployment, infrastructure]
---

The graph view becomes genuinely useful once the vault exceeds 200 notes. Filter it to show only notes of a specific type (e.g., type:decision) to see which projects generated the most architectural decisions, or filter by type:runbook to find operational procedures that are isolated (no backlinks) and therefore likely to be forgotten.

Use the Map of Content (MOC) pattern for high-traffic topics. An MOC is a plain note that manually curates links to related notes — think of it as a hand-authored index page:

# MOC: Infrastructure

## Active Runbooks
- [[kubernetes-cluster-scale]]
- [[rds-failover-procedure]]
- [[deploy-rollback-procedure]]

## Key Decisions
- [[ADR-008-container-orchestration]]
- [[ADR-014-rds-vs-aurora]]

## Reference
- [[vpc-architecture-overview]]
- [[cost-center-tagging-policy]]

MOC notes appear prominently in the graph view because they have many outbound links, making them natural entry points for new team members exploring the vault.

Onboarding New Team Members

A shared vault accelerates onboarding when a dedicated entry point exists. Create a note called START-HERE.md at the vault root:

# Start Here — New Team Member Guide

Welcome. This vault is the team's primary knowledge base.

## First: Read These
1. [[team-working-agreements]]
2. [[communication-conventions]]
3. [[tool-access-request-process]]

## Your First Week
- Week 1 checklist: [[onboarding-week-1-checklist]]
- Meet the team: [[03-people/]]

## Where Things Live
- Meeting notes → `01-meetings/`
- Project work → `02-projects/YOUR-PROJECT/`
- Operational procedures → `05-runbooks/`
- Architecture decisions → `04-decisions/`

## How to Contribute
- Use templates (Cmd+P → Templater: Open insert template modal)
- File your notes in the right folder, not `00-inbox`
- Link to related notes using [[wikilinks]]
- Run `Obsidian Git: Sync` before closing the app

New team members who can navigate the vault independently within their first week are a strong signal that the structure is working.

Conflict Resolution with Git

When two people edit the same note simultaneously and both commit, Git will create a conflict:

# The conflict looks like this in the file:
The database decision was finalized on 2026-03-15.

# Resolve by keeping the correct version
# Edit the file to remove conflict markers
# Then:
git add 04-decisions/ADR-012-database-choice.md
git commit -m "resolve: ADR-012 date conflict"

The Obsidian Git plugin’s sync command runs pull --rebase then push. Most single-note edits merge cleanly without conflicts.

Tool Comparison: Obsidian vs. Alternatives for Team Knowledge Management

Feature Obsidian (Git sync) Notion Confluence Logseq
File format Plain Markdown Proprietary Proprietary Plain Markdown
Version control Git native Limited history Page history Git native
Offline access Full Limited Limited Full
Per-seat cost $0 (Sync: $8/mo) $10-18/mo $5.75-11/mo $0-8/mo
Plugin ecosystem 1,500+ community Limited Marketplace Growing
Graph view Yes No No Yes
API / scripting Dataview + JS Yes REST API Clojure queries
Learning curve Medium Low Medium Medium

Notion and Confluence win on onboarding ease and collaborative editing. Obsidian wins on data ownership, offline access, and long-term cost for teams comfortable with Git.

Built by theluckystrike — More at zovo.one

Frequently Asked Questions

Who is this article written for?

This article is written for developers, technical professionals, and power users who want practical guidance. Whether you are evaluating options or implementing a solution, the information here focuses on real-world applicability rather than theoretical overviews.

How current is the information in this article?

We update articles regularly to reflect the latest changes. However, tools and platforms evolve quickly. Always verify specific feature availability and pricing directly on the official website before making purchasing decisions.

Does Obsidian offer a free tier?

Most major tools offer some form of free tier or trial period. Check Obsidian’s current pricing page for the latest free tier details, as these change frequently. Free tiers typically have usage limits that work for evaluation but may not be sufficient for daily professional use.

How do I get my team to adopt a new tool?

Start with a small pilot group of willing early adopters. Let them use it for 2-3 weeks, then gather their honest feedback. Address concerns before rolling out to the full team. Forced adoption without buy-in almost always fails.

What is the learning curve like?

Most tools discussed here can be used productively within a few hours. Mastering advanced features takes 1-2 weeks of regular use. Focus on the 20% of features that cover 80% of your needs first, then explore advanced capabilities as specific needs arise.