4 из 51 мин

Как LLM добирается до локального Obsidian на моём Mac

Obsidian, vault и MCP-сервер работают локально на моём Mac.

Чтобы внешняя LLM могла обращаться к этой памяти, нужен отдельный транспортный слой.

Текущая схема выглядит так:

LLM / MCP-клиент

Cloudflare

VPS

reverse SSH

MCP server на Mac

Obsidian Local REST API

Obsidian vault

Публичной точкой входа служит отдельный MCP endpoint.

Cloudflare принимает запрос и передаёт его на VPS, где cloudflared направляет трафик на:

127.0.0.1:3011

Но самого MCP-сервера на VPS нет.

Порт 3011 создаётся reverse SSH-туннелем, который мой Mac поднимает самостоятельно.

Ключевой фрагмент:

-R 127.0.0.1:3011:127.0.0.1:3010

То есть всё, что приходит на 3011 внутри VPS, через SSH отправляется на локальный MCP-порт 3010 моего Mac.

Дальше запрос уже идёт внутри локальной системы:

MCP server

Obsidian Local REST API

vault

В этой архитектуре VPS остаётся только транспортным слоем.

Он не хранит vault, не индексирует заметки и не становится второй копией проектной памяти.

Даже порт 3011 доступен только внутри VPS.

Сам Obsidian остаётся локальным.

Для устойчивой работы MCP server и reverse SSH запускаются через отдельные LaunchAgent, а autossh автоматически восстанавливает туннель после обрывов.

В результате внешняя модель получает доступ к проектной памяти без переноса самой памяти в облако.

Оглавление серии
  1. Почему я разделил память и выполнение
  2. Как LLM получила доступ к моему Obsidian
  3. Что происходит, когда LLM ищет что-то в моей памяти
  4. Как LLM добирается до локального Obsidian на моём Mac
  5. Где заканчивается MCP и что будет дальше