Tolaria is a desktop app for markdown vaults that treats git as the database

Markdown files on disk, with the app as a reader

Tolaria is a desktop app for macOS, Windows and Linux whose subject is markdown knowledge bases, and its central decision is that your notes are plain markdown files with YAML frontmatter rather than rows in a database. The stated principle is files-first: notes are portable, work with any editor, and require no export step. A second principle is standards-based, with no proprietary formats and no locked-in data, so standard tools still read the vault if you leave. A third is types as lenses, not schemas. Types are navigation aids rather than enforcement: there are no required fields and no validation, just helpful categories for finding notes. That choice cuts both ways. A note written by another editor, or by an agent, is never rejected for missing metadata, and nothing forces a consistent frontmatter shape across the vault. The author's own workspace is described as 10,000+ notes built from refactoring work, personal journaling and second braining, which is the scale the design is aimed at.

Every vault is a git repository, not an app-owned folder

The second principle is git-first: every vault is a git repository, so you get full version history, the ability to use any git remote, and zero dependency on Tolaria servers. Practically, that means your history is not a proprietary sync log you cannot export. It is commits you can read, branch and push to a remote you choose. Add offline-first, with no accounts, no subscriptions and no cloud dependencies, and you get the claim the project makes about lock-in: if you stop using Tolaria you lose nothing. First launch reinforces the file model instead of hiding it. When you open the app for the first time you get the chance of cloning the getting started vault from refactoringhq/tolaria-getting-started, a separate repository that walks through the whole app. This repository also ships a demo-vault-v2/ directory. Both are ordinary checkouts of files, so a first run teaches the model the app assumes.

Two install paths: a Homebrew cask or a signed release build

End users install from one of two places. On macOS, a Homebrew cask is offered:

brew install --cask tolaria

The second path is the releases download page, which serves macOS, Windows and Linux builds from one link. Windows installers are Authenticode-signed, and the project names the remaining friction itself: company-managed devices may still require IT approval of the Tolaria publisher before the first install runs. That matters for a company rollout, because a signed binary from a publisher your endpoint tooling has not catalogued is exactly the case that lands in a review queue. The user documentation is not hidden behind the app either. It lives in site/ in this repository, is published to GitHub Pages, and the README sends new users to site/start/install.md and then site/start/first-launch.md. Note what is not an install path: the root package.json is marked private, so pnpm is for working on the code rather than installing it.

Development needs Node 20, pnpm 8, Rust, and a Mac or Linux

The app is built with Tauri, React and TypeScript, and running it from source has a documented prerequisite list: Node.js 20+, pnpm 8+, Rust stable, and macOS or Linux for development. That last line is the first constraint worth noticing, since it rules out Windows as a contributor platform even though Windows is a supported target for the built app. With the prerequisites in place, the quick start is short:

pnpm install
pnpm dev

That runs Vite and gives you the browser-based mock mode at http://localhost:5173, the fast way to work on the editor without the Rust side. The native desktop app goes through a script that wraps the Tauri CLI:

pnpm tauri dev

The split matters when narrowing a bug. Editor behaviour can be reproduced in browser mock mode, while anything involving the filesystem, the window or the bundled MCP server exists only in the native run. The package.json also names its test surfaces: vitest for unit tests, Playwright for end to end, and separate playwright.smoke.config.ts, playwright.integration.config.ts and playwright.config.ts files, with the smoke script naming specs such as autosave-low-end-typing, create-note-backing-file and delete-note-nonblocking.

Linux needs WebKit2GTK 4.1, and the MCP server needs a system node

Tauri 2 on Linux requires WebKit2GTK 4.1 and GTK 3, spelled out per distribution because the package names differ. On Debian or Ubuntu 22.04 and later:

sudo apt install libwebkit2gtk-4.1-dev build-essential curl wget file \
  libxdo-dev libssl-dev libayatana-appindicator3-dev librsvg2-dev \
  libsoup-3.0-dev patchelf

Arch and Manjaro get the equivalents through pacman, including webkit2gtk-4.1, appmenu-gtk-module, libappindicator-gtk3 and librsvg, while Fedora 38 and later uses dnf with webkit2gtk4.1-devel, libappindicator-gtk3-devel and librsvg2-devel. The second Linux wrinkle is more interesting. The bundled MCP server still spawns the system node binary at runtime on Linux, so the documentation tells you to install Node from your distro package manager if you want the external AI tooling flow. An otherwise self-contained install therefore still expects a system interpreter, and the AI tooling path is what notices when it is missing. The server is bundled rather than fetched: there is an mcp-server/ directory and a bundle-mcp script that packages it.

Agent setup paths, plus build-time keys for Sentry, PostHog and Lara

The project calls itself AI-first but not AI-only, and it means that concretely. A vault of markdown files works well with agents, setup paths exist for Claude Code, Codex CLI and Gemini CLI, and you stay free to point anything else at the same files. An AGENTS file is provided so agents can work out the layout themselves. The integration point is the MCP server described above. There is also a build-time configuration surface that is easy to miss in a project whose pitch is having no accounts. The .env.example lists VITE_SENTRY_DSN for crash reporting, VITE_POSTHOG_KEY and VITE_POSTHOG_HOST, whose default value is https://eu.i.posthog.com, and LARA_ACCESS_KEY_ID with LARA_ACCESS_KEY_SECRET for the translation CLI. The file states that these are never committed, that .env.local is gitignored, and that release workflows must mirror the values into GitHub Actions secrets. Whether a given build reports anything depends on those values being present at build time. For a tool that markets itself as offline, that file is the one to read before you decide what it does with a network.

The download page points at an alpha, and CI quality is sponsor funded

Maintenance is real, but the release channel is not stable. The last push to main was on 2026-11-02, and the three most recent releases are alpha-v2026.11.3-alpha.0014, alpha-v2026.11.3-alpha.0015 and alpha-v2026.11.3-alpha.0016, all published on 2026-11-03 within about 80 minutes of each other. Since the documented install path is the latest release, the build a new user downloads is an alpha, while the package.json in the root still reads version 0.1.0. Plan for a moving target. The quality tooling is paid for by a sponsor panel of Codacy, CodeScene, CircleCI and getunblocked, and the repository shows where that goes: .circleci/, .codacy.yaml, .codescene-thresholds, a codacy:gate script that can fail a build, a Playwright smoke suite, and an editor performance benchmark with small and large scenarios. The licence is AGPL-3.0-or-later with the text in LICENSE, which is a different decision from a permissive licence if you intend to modify the app and serve the modified version to others.

Where the files-first bet lands against Obsidian and Notion

Tolaria never publishes a feature-by-feature comparison, so the useful comparison is architectural. Both Tolaria and Obsidian keep notes as markdown files in a local folder, and the difference is what sits around them: Tolaria makes git the history and the sync story is any git remote you like, while plugin-driven workflows are not part of its documentation. Notion inverts the model, keeping content in a workspace inside the app, so the file is an export rather than the storage layer. Tolaria's own commitments are the checkable part of any such comparison: plain files with YAML frontmatter, a repository per vault, no accounts, and types that carry no required fields. What the documentation does not claim is just as telling. No sync service and no plugin system. Beyond the desktop targets of macOS, Windows and Linux, the mobile app for iPhone and iPad is still early and in a TestFlight beta. If your requirement list includes a sync service or plugins, this is the wrong shape of tool.

Editorial conclusion

Choose Tolaria if you want your notes to remain files you can grep, branch and edit in any editor, and you can accept an alpha channel and a mobile app that is still an early beta. Skip it if you need a sync service or a plugin ecosystem, neither of which the documentation claims. Before migrating a vault, commit one directory to a test repository and open it with your own tools, because the files are the product and git is your only way back. If you plan to fork it, read LICENSE first, since the package declares AGPL-3.0-or-later.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes