4 of 51 min

How an LLM reaches the local Obsidian on my Mac

Obsidian, the vault and the MCP server all run locally on my Mac.

For an external LLM to reach that memory, a separate transport layer is needed.

The current setup looks like this:

LLM / MCP client

Cloudflare

VPS

reverse SSH

MCP server on the Mac

Obsidian Local REST API

Obsidian vault

The public entry point is a separate MCP endpoint.

Cloudflare accepts the request and passes it to the VPS, where cloudflared directs the traffic to:

127.0.0.1:3011

But the MCP server itself isn’t on the VPS.

Port 3011 is created by a reverse SSH tunnel that my Mac brings up on its own.

The key fragment:

-R 127.0.0.1:3011:127.0.0.1:3010

So everything that arrives at 3011 inside the VPS is sent over SSH to local MCP port 3010 on my Mac.

From there the request stays inside the local system:

MCP server

Obsidian Local REST API

vault

In this architecture the VPS remains only a transport layer.

It doesn’t store the vault, doesn’t index notes and doesn’t become a second copy of project memory.

Even port 3011 is only reachable inside the VPS.

Obsidian itself stays local.

For stable operation, the MCP server and reverse SSH run through separate LaunchAgents, and autossh automatically restores the tunnel after drops.

As a result, the external model gets access to project memory without moving the memory itself to the cloud.

Series contents
  1. Why I separated memory from execution
  2. How the LLM got access to my Obsidian
  3. What happens when an LLM searches my memory
  4. How an LLM reaches the local Obsidian on my Mac
  5. Where MCP ends and what comes next