deploy: MCP servers' own venvs are synced by the deploy, not by memory ...

Each server under mcp-servers/ runs from its own .venv — the interpreter its
config in mcp_servers.d/*.json names — and Navi's venv does not carry those
dependencies. When a server's pyproject.toml gained one (trafilatura, Nov
2026) and the host was only pulled and restarted, the server died at import:
the manager could not connect, its tools silently left every profile's tool
list, and nothing reached the chat. SearXNG was healthy the whole time.

sync-mcp-venvs.sh installs every mcp-servers/*/pyproject.toml into its own
venv, stamped by a sha256 of the pyproject so an unchanged server is skipped
and a re-run is cheap. install.sh calls it as a numbered step; UPDATE.md
runs it unconditionally after a pull and verifies the MCP connection in the
journal; docs/mcp.md no longer reads as "install it yourself by hand".

deploy: runbook for updating a running instance ...

Adds deploy/UPDATE.md: preflight, the branch shapes (master vs the
tracked .env on deploy), what to rebuild before pushing (the frontend
dist is committed and the server never builds it), the verification
commands that prove the new bundle is the one being served, rollback,
and the traps — tracked secrets in mcp_servers.d/, gitignored vendor
kit dist, service-worker cache, Android app needing only a restart.

Linked from deploy/README.md.

port: 8000/8001 -> 8099/8098 everywhere ...

navi runs on shared servers where 8000/8001 are usually taken. New
defaults: API 8099, navi_ui MCP 8098. Touched: config defaults
(navi_port, navi_ui_mcp_port, public_url, gnauth_redirect_uri),
navi-server launcher docs, env.template/.env.example, install.sh
health-check fallback, terminal client base_url, webclient dev configs
(useWebSocket, contentLinks, vite proxy), android url hint, docs.
Also made the navi_ui FastMCP constructor port settings-driven instead
of a hardcoded 8001 (it was overridden at start anyway).

deploy: auto-install docker compose v2 plugin when the host lacks it ...

Ubuntu 18.04's docker packages predate compose v2. The plugin is a
single static binary that runs on any distro with docker CLI >= 18.09,
so the script downloads it into /usr/local/lib/docker/cli-plugins
(system-wide — sudo docker compose sees it too) when docker compose is
unavailable, with the same offline pattern as the python tarball: a
pre-downloaded binary next to install.sh wins. If the CLI is too old
to support plugins at all, the error asks for docker --version.

deploy: standalone CPython fallback for old distros ...

venv cannot be shipped in the repo — it embeds absolute paths and
distro-specific compiled wheels (asyncpg, uvloop, cryptography), so it
dies on any other machine. Instead, when the host has no python >= 3.11
(Ubuntu 18.04: 3.6, 22.04: 3.10; system python must not be replaced),
install.sh fetches a standalone astral python-build-standalone CPython
3.12 into .python/ — self-contained, needs only glibc >= 2.17, works
on any distro. The tarball is cached next to the repo and reused; on
offline servers a pre-downloaded tarball next to install.sh wins.
Verified locally: tarball layout, venv creation, pip install.

deploy: README opens with the full install breakdown

deploy: one-command server bundle (dockerized postgres + systemd) ...

deploy/install.sh — everything in one command: prerequisite checks,
.env provisioning from env.template (generated DB password), dockerized
PostgreSQL (pgvector image, restart: always, bound to 127.0.0.1, vector
+ pg_trgm extensions), venv + pip install, a systemd unit with
Restart=always (the server lives from installation, per the roadmap
where these modules become each other's subagents), health check, and
navi-code/navi-server symlinks into PATH. Idempotent — safe to re-run.

Default deployed shape: web UI off, auth off, terminal client only.
Re-enabling the web panel later is editing .env + restart — nothing is
removed from the tree.

The deploy branch (next commit set) differs from master only by a
filled-in .env.