DEV Community: TypeFire

What Obsidian Really Costs a Dev Team in 2026 (and 4 Ways to Sync a Vault)

TypeFire — Fri, 30 Oct 2026 05:13:16 +0000

Somebody on your team starts keeping docs in Obsidian. Then a few more people do. At some point a manager asks the reasonable question: do we need to pay for this?

Short answer: probably not for the license, and maybe for sync. Every figure below comes from Obsidian's own pricing page, which we checked on October 29, 2026.

The price list

What	Price	Required?
The Obsidian app	Free, for personal and work use	No
Sync	$4 per user per month billed yearly, $5 monthly	Only if you use it
Publish	$8 per site per month billed yearly, $10 monthly	Only if you use it
Commercial license	$50 per user per year	No
Catalyst (early access)	$25 once	No

Students, faculty and nonprofit staff get 40% off Sync and Publish.

Is the commercial license required?

No. Obsidian's FAQ answers this directly: you are not required to pay for commercial use. It does encourage organizations to buy the license so the app stays independent and user funded, and companies that buy one can be listed as featured organizations.

So if your team is happy with the app and syncs files some other way, the honest bill is zero. Buying licenses is a way to support a tool you rely on, and plenty of teams do it for exactly that reason. We wrote up the details on our Obsidian commercial license page.

Where the money actually goes

The recurring cost is Sync, because it's priced per person, every month, for as long as you use it. Here's what that looks like over three years:

Annual billing. The last bar includes the optional license, which more than doubles the team figure.

If you want the math as code, so you can plug in your own headcount:

const SYNC = 4 * 12;      // per user per year, billed yearly
const PUBLISH = 8 * 12;   // per site per year, billed yearly
const LICENSE = 50;       // per user per year, optional

function obsidianCost({ people, years = 3, sync = true, sites = 0, licenses = false }) {
  const perYear =
    (sync ? people * SYNC : 0) +
    sites * PUBLISH +
    (licenses ? people * LICENSE : 0);
  return perYear * years;
}

obsidianCost({ people: 10 });                   // 1440
obsidianCost({ people: 10, licenses: true });   // 2940
obsidianCost({ people: 1, sites: 1 });          // 432

Four ways to sync a vault

A vault is a folder of Markdown files, so anything that moves files can sync it. Each option below trades money against something else.

1. Obsidian Sync

The paid service. It's end-to-end encrypted, keeps version history, supports shared vaults, and works on iOS and Android as well as desktop. If your team needs notes on phones, this is the one to pay for, and nothing else here matches it on mobile.

2. Git

Free, and most dev teams already know it. You get full history, diffs and blame on your notes, and the vault can live next to your code. The community Git plugin can commit and pull on a timer, so nobody has to remember.

A few lines of .gitignore keep the noise out. Obsidian rewrites its workspace files every time you open a pane, and you don't want those in every commit:

# Obsidian: per-device UI state, changes constantly
.obsidian/workspace.json
.obsidian/workspace-mobile.json

# Obsidian's local trash
.trash/

# macOS
.DS_Store

Keep the rest of .obsidian/ committed if you want the team to share the same plugins and settings. The trade-off is that Git is a pull and push model: two people editing the same note at the same time get a merge to resolve, the same as with code.

3. A cloud folder (iCloud Drive, Dropbox, Syncthing)

Put the vault in a folder that already syncs and you're done. It's free and needs no setup beyond moving the folder. It works best for one person across their own devices; for several people writing in the same files, Git's history makes changes easier to follow.

4. TypeFire, between Macs

This one is ours, so here's exactly what it does. TypeFire opens the vault you already have, in place: the same .md files, no import and no copy, and Obsidian keeps working alongside it.

Same folder, same files. TypeFire never rewrites a file you only open.

Notes sync is part of TypeFire Pro, a one-time purchase that covers three Macs, with note version history included. It runs through your own iCloud Drive, so nothing passes through a TypeFire server. It's built for Mac to Mac. For phones, Obsidian Sync is the one to pay for. The iCloud sync docs cover what syncs and how.

Here's the Notes tab in two minutes:

While you're in the vault all day

Sync is what costs money. What saves time is getting to a note without leaving the app you're in. TypeFire's note search opens over whatever you're working in, and Enter pastes the note into it:

Search the vault from your editor, terminal or browser, and paste the answer where you are.

We wrote more about this in capturing into Obsidian from any app. For the long version of the cost breakdown, including what Sync gets you, see Obsidian pricing in 2026.

The short version

The Obsidian app is free for work, and the $50 commercial license is optional.
Sync is the real recurring cost: $4 per person per month billed yearly, which comes to $1,440 over three years for a team of ten.
Need mobile? Pay for Obsidian Sync. Desktop only? Git or a cloud folder costs nothing, and TypeFire covers Mac-to-Mac with a one-time purchase.

How does your team sync its vault, and has anyone made Git work smoothly on mobile?

15 Text Expander Snippets Every Developer Should Steal (Commits, PRs, Bug Reports)

TypeFire — Fri, 30 Oct 2026 01:39:56 +0000

You type the same things all day. The commit prefix. The PR template. "Steps to reproduce." The standup. The console.log with a label so you can find it again. Each one is ten seconds, and there are dozens of them a day.

A text expander turns each into a few keystrokes: type ;pr and the whole template lands, wherever your cursor is. Below are 15 snippets worth setting up, written in the token syntax we use at TypeFire. The ideas work in any good expander; the syntax is ours.

Type thx, get the whole reply. The tokens below work the same way.

A quick primer on the syntax

Every example uses four kinds of placeholder that fill in at the moment of expansion:

{{fill:Label}} stops and asks you for a value (a ticket number, a scope). {{fill:Label|default}} prefills it.
{{date}}, {{time}} and formats like {{date:dddd}} insert today's date, the time or the weekday. Date math works too: {{date:+1d}} is tomorrow.
{{clipboard}} pastes whatever you last copied.
{{cursor}} leaves your cursor at that spot after expanding (plain-text snippets only).

Save these as Plain Text snippets, even the Markdown-looking ones, so {{cursor}} works and the Markdown pastes exactly as written.

The full list is in the dynamic tokens docs, and this 90-second walkthrough shows fill-ins and date math in action:

A tip on naming: start every abbreviation with a character you never type at the start of a word, like ; or z. Then ;pr never fires by accident in the middle of a sentence.

Git and pull requests

1. Conventional commit, ;cc

{{fill:type|feat}}({{fill:scope}}): {{fill:summary}}

One form, three boxes, and a correctly formatted commit message every time.

2. Branch name, ;br

git checkout -b {{fill:type|fix}}/{{fill:ticket}}-{{fill:short name}}

3. Pull request template, ;pr

## What changed
{{cursor}}

## Why

## How to test
1.

## Checklist
- [ ] Tests added or updated
- [ ] Docs updated
- [ ] No new warnings

If your PR template is Markdown, preview it before you push. We wrote up four ways to preview Markdown live, including the task-list syntax this one uses.

4. Approve with a nit, ;lgtm

LGTM, thanks! One small nit (non-blocking): {{cursor}}

5. Changelog entry, ;cl

## [{{fill:version}}] - {{date}}
### Added
- {{cursor}}

Code review and bugs

6. Review checklist, ;crv

- [ ] Does it do what the ticket says?
- [ ] Edge cases: empty, huge, unicode, offline
- [ ] Errors are handled and shown in plain words
- [ ] Tests cover the change
- [ ] No secrets, no debug logging left in

7. Bug report, ;bug

**Steps to reproduce**
1. {{cursor}}

**Expected**

**Actual**

**Environment:** {{fill:browser or OS}}, reported {{date}}

8. "Can you share more?", ;more

Thanks for the report! Could you share the exact steps, what you expected, and a screenshot or the console output? That'll help us reproduce it.

Code you type a hundred times

9. Labeled log, ;log

console.log("{{fill:label}}:", {{fill:value}});

10. TODO with an owner and a date, ;todo

// TODO({{fill:owner}}, {{date}}): {{cursor}}

A dated TODO is one somebody might actually come back to.

Two more from our developer snippets page: {{clipboard}} drops in what you just copied, {{cursor}} parks the caret inside the block.

11. Markdown table skeleton, ;tbl

| {{fill:Column 1}} | {{fill:Column 2}} |
| --- | --- |
|  |  |

Team rituals

12. Standup, ;su

**{{date:dddd}}**
- Yesterday: {{cursor}}
- Today:
- Blockers: none

13. On-call handoff, ;oncall

Handing off on-call, {{date:MMMM DD}}.
- Open incidents:
- Watch out for:
- Next check-in: {{date:+1d:dddd}}

Two that run code (Mac app)

TypeFire snippets can also be shell scripts: the script runs when you expand it, and its output is pasted. These two live on the Mac app.

14. A fresh UUID, ;uuid (Shell Script snippet)

uuidgen | tr '[:upper:]' '[:lower:]'

15. Your local IP, ;ip (Shell Script snippet)

ipconfig getifaddr en0

Where they work

On the Mac, snippets expand in every app: your editor, the terminal, Slack, the browser. In Chrome, Edge and Brave, the TypeFire extension expands them on every site, so ;pr works right inside GitHub's PR form.

On the Mac, a snippet can also get its own keyboard shortcut, for the ones you never want to type at all.

If you're choosing a browser text expander, we compared the options in our guide to the best Chrome text expander. And there's a page on TypeFire for developers with more code-shaped examples.

The short version

Prefix abbreviations with ; or z so they never fire by accident.
Use {{fill:...}} for the parts that change and {{date}} for anything dated.
Start with the five you type most: commit, PR, bug report, standup, log line.

What's the one thing you type every single day that should be a snippet?

Markdown Live Preview: 4 Ways to See What Your README Really Looks Like Before You Push

TypeFire — Fri, 30 Oct 2026 01:00:51 +0000

You write a README, push it, open the repo page, and the table is a mess of pipes. The list you indented "correctly" is now a code block. The checkbox is a literal [ ].

Markdown is forgiving to write and unforgiving to render. A live preview catches all of that before anyone else sees it. Here are four ways to get one, depending on where you're writing, plus the mistakes worth looking for.

1. VS Code: the preview you already have

VS Code ships a Markdown preview, no extension needed.

Cmd+Shift+V (Mac) or Ctrl+Shift+V (Windows, Linux) opens the preview in a tab.
Cmd+K V or Ctrl+K V opens it side by side, and it scrolls along with the editor.

Good for: files that already live in a repo you have open.

2. GitHub's own Preview tab

Editing a .md file in the GitHub web editor? The Preview tab next to Edit renders it with GitHub's own flavor of Markdown, the same one your repo page uses.

Good for: quick fixes to a file that's already on GitHub.

3. `grip`: GitHub rendering on localhost

pip install grip
grip README.md
# then open http://localhost:6419

grip renders the file through GitHub's Markdown API, so what you see matches the repo page closely. It refreshes when you save.

Good for: checking a README exactly the way GitHub will show it, from the terminal.

4. A browser editor where the preview is the document

Sometimes there's no repo yet. Someone pasted Markdown into Slack, an AI tool answered with a page of ## and **, or you're on a machine where you can't install anything.

For that, we built a free Markdown live preview at TypeFire. You paste Markdown in and it renders the moment it lands, right where you pasted it. There's no second pane to keep in sync, because the rendered text is the thing you edit.

A README pasted in: the heading, inline code and the table render where you pasted them.

A few details that matter for developer work:

Paste a README or drop the .md file onto the page; tables, fenced code, task lists and links render as they land.
Pasting from a web page or a doc converts to Markdown with the headings, links and lists kept, which is handy when you're turning a Google Doc into a README.
Copy it back out either way: File > Copy > As Markdown for the source, or As rich text for an email or a chat.
Nothing is uploaded. Your text stays in the browser tab, and tabs are saved locally so a refresh doesn't lose them.

Pasted from a web page: the heading, bold, link and list arrive as Markdown.

File > Copy gives you the source or the formatted version.

The same editor also ships in TypeFire for Chrome, with your notes in tabs, a text expander and clipboard history:

Good for: Markdown that doesn't live in a repo yet, or anywhere you can't install tools. If you just need to read a .md file on a Mac rather than edit it, the Markdown viewer for Mac guide covers that.

What to look for in the preview

Whichever tool you use, these are the five mistakes a preview catches that your eyes skip in raw Markdown:

1. Tables without a separator row. The second line has to be dashes and pipes, or there's no table:

| Flag | What it does |
| --- | --- |
| `-v` | Verbose output |

Here's the same table without that row, and then with it:

No separator row: just text with pipes in it.

Add | --- | --- | and it becomes a table.

2. A numbered list that doesn't start at 1. On GitHub a bullet list can follow a paragraph directly, but a numbered list starting at 3. with no blank line above it merges into the paragraph. Add the blank line, or start at 1..

3. Nested lists indented by the wrong amount. Line nested items up under the text of the parent item. Too little indent and the child item flattens into the parent list.

4. Task lists that need the exact syntax. It's - [ ] and - [x], with a space inside the empty brackets and a space after them. -[ ] stays as literal text.

5. Fenced code without a language.

```bash

gets syntax highlighting; a bare

```

doesn't. The preview shows you which blocks you forgot to tag.

Which one should you use?

Writing inside a repo in VS Code: the built-in preview.
Fixing a file on GitHub: the Preview tab.
Want GitHub's exact rendering locally: grip.
Markdown from anywhere else, or no install allowed: a browser live preview.

What's the Markdown rendering bug that bit you last?

DEV Community: TypeFire

What Obsidian Really Costs a Dev Team in 2026 (and 4 Ways to Sync a Vault)

The price list

Is the commercial license required?

Where the money actually goes

Four ways to sync a vault

1. Obsidian Sync

2. Git

3. A cloud folder (iCloud Drive, Dropbox, Syncthing)

4. TypeFire, between Macs

While you're in the vault all day

The short version

15 Text Expander Snippets Every Developer Should Steal (Commits, PRs, Bug Reports)

A quick primer on the syntax

Git and pull requests

Code review and bugs

Code you type a hundred times

Team rituals

Two that run code (Mac app)

Where they work

The short version

Markdown Live Preview: 4 Ways to See What Your README Really Looks Like Before You Push

1. VS Code: the preview you already have

2. GitHub's own Preview tab

3. grip: GitHub rendering on localhost

4. A browser editor where the preview is the document

What to look for in the preview

Which one should you use?

3. `grip`: GitHub rendering on localhost