Obsidian With a Local LLM: Setup and Privacy Checks
Running a local model through Ollama keeps your vault content off external servers. Here is how to connect one to an Obsidian AI plugin, check what data actually leaves the device, and use fenbs for shared project context.
Updated 5 min read
Running a local LLM (a large language model that runs on your own hardware) with Obsidian keeps your notes off external servers. Ollama is the most common tool for this: it runs open-weight models locally and exposes an API on localhost that Obsidian AI plugins can call. Tools like fenbs fit alongside this setup for the project context that should be shared across AI tools: decisions, tasks and where the work stands can live in fenbs while sensitive source notes stay local.
This article covers setting up Ollama, configuring an Obsidian AI plugin to use it, and checking what actually leaves your device in each step.
What a local LLM setup looks like
Ollama runs on your Mac, Windows, or Linux machine and downloads open-weight models such as Llama or Mistral to a local folder. It starts a server on localhost port 11434 that accepts requests in an OpenAI-compatible format. Obsidian AI plugins that support a custom API base URL can point at Ollama's localhost endpoint instead of an external provider.
The result is that note content you send to the model goes to Ollama on your device and does not leave your network. The model's output comes back through the same local channel. This is the core privacy benefit compared to cloud API services. See what is an LLM for a plain-language explanation of what the model itself is doing.
Install and start Ollama
Download Ollama from the Ollama website (ollama.com). Install and run it; it starts a background service automatically. Pull a model by running a command such as ollama pull llama3 in your terminal. The model downloads to your device. Ollama's server starts on localhost:11434 by default.
The model's quality and speed depend on your hardware. A machine with a modern GPU will run larger models faster. Smaller models like 7B or 8B parameter variants run acceptably on most developer laptops without a dedicated GPU; larger ones will be slow without one. Start with a smaller model to confirm the setup works before downloading a larger one.
Configure your Obsidian plugin to use Ollama
In your Obsidian AI plugin's settings, find the API base URL field and set it to http://localhost:11434/v1 or the equivalent Ollama endpoint your plugin expects. Set the model name to one you have already pulled with Ollama. Most plugins that support OpenAI-compatible APIs work with this configuration without any API key, since Ollama does not require authentication on localhost.
- Set the API base URL to
http://localhost:11434/v1or the Ollama endpoint your plugin supports. - Enter the model name exactly as it appears when you run
ollama list. - Leave the API key field empty or enter any placeholder; Ollama on localhost does not authenticate requests.
- Test with a simple prompt before using vault content.
Verify what actually leaves your device
Even with a local model, data can leave your device through other paths. Check whether the Obsidian AI plugin has any telemetry, crash reporting, or sync features that send data to the plugin developer's servers. These are separate from the model API call and are unrelated to Ollama. Read the plugin's privacy policy and source code if you want certainty.
Also check whether Obsidian itself or your sync service sends anything. Obsidian Sync encrypts vault content in transit and at rest; iCloud and other services have their own policies. A local model does not protect notes you sync to a cloud service.
When to use fenbs alongside a local setup
A fully local setup keeps source notes on your device, which is appropriate for sensitive material: personal medical notes, client records, financial information. But some project context is appropriate to share: the tasks the AI should work on, the decisions the team has approved, and where the last session left off. Keeping those in fenbs lets other connected assistants read the project record without needing access to the private source notes.
This is a practical split: local Obsidian with Ollama for private source content, fenbs for shared project state. The local model reads private notes; fenbs carries the context that is safe to share across AI tools. For more on how to use AI at work with this kind of privacy-conscious setup, that guide covers the broader workflow.
How to do this with fenbs
Keep private source notes in your local Obsidian vault with Ollama, and keep shared project decisions and tasks in fenbs.
- Create a free account and add a project for the work your vault notes support.
- Write Decisions and rules for what the local model may read: which folders contain sensitive notes that stay local, and which contain material it is safe to share.
- Add the current tasks and a note about the local model setup so any connected assistant understands the privacy split.
- Connect a supported AI app to fenbs via Integrations for session context. Use the local Ollama model for tasks that require private vault content.
- Before ending a session, record any new decisions or task progress in fenbs so the next session, on any tool, starts from the current state.
Share what is safe without exposing what is private
fenbs keeps the project decisions, tasks, and Where we left off that are safe to share across AI tools, while your private source notes stay in the local vault. Any connected assistant reads the shared context; the local model reads the private notes. Create a free account and define the split for your first project.
Create a free accountFree for one person · No credit card · Works with Claude, ChatGPT, Cursor and more