haylanandClaude-Bot
6f4e736da8
Move docs/coding-cli-setup.md to docs/coding-cli-setup/ with one file per CLI (claude-code, kimi-cli, opencode, qwen-code) plus a shared index.md for the gateway intro, tool-calling risk note, and summary table. Also fixes the qwen-code doc: context sizes are per-slot (LLAMA_CTX_SIZE / LLAMA_PARALLEL), not raw LLAMA_CTX_SIZE (same fix applied to OpenCode's limit.context); documents the fastModel classifier provider and its own context math; adds the omniroute-search MCP server (SearXNG web search) and Auto Mode permissions tuning that were missing from the original qwen-code section. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2.9 KiB
Network access: proxy-ai.home / proxy-ai.haylan.ch
This stack has no chat UI — every client is a coding CLI reaching the AI gateway (OmniRoute). It doesn't run its own reverse proxy — it publishes the gateway's API port to the host and relies on the existing Nginx Proxy Manager (NPM) instance already fronting other self-hosted services on this network.
llama.cpp's raw API stays LAN-only — deliberately
The inference API (port ${LLAMA_PORT:-8080}) is not registered in NPM and is not reachable externally. It has no authentication of its own — putting it on the public internet would mean an unauthenticated inference endpoint. Coding-agent CLIs (Claude Code, Kimi, OpenCode, Qwen Code — see docs/coding-cli-setup/) don't reach it directly at all now; they go through the gateway below, same as everything else.
If you later want external CLI access too, that's a deliberate scope change — see the map (issue #1) before doing it, since it changes the security posture.
The AI gateway (OmniRoute) — proxy-ai.home / proxy-ai.haylan.ch
As of issue #31 (migrated from LiteLLM), the gateway is OmniRoute:
proxy-ai.homeandproxy-ai.haylan.chboth point only at${OMNIROUTE_PORT:-4000}— the API port. Set up as two NPM Proxy Hosts pointing at this machine's LAN IP on that port;proxy-ai.homeinternal-only,proxy-ai.haylan.chexternal via the DMZ already forwarding to NPM (let NPM issue/manage the TLS cert as usual).- The dashboard (
${OMNIROUTE_DASHBOARD_PORT:-20128}) is never registered in NPM at all, anddocker-compose.ymlnever publishes that port to the host either — it manages every workload's keys, so it doesn't belong on the public internet, same reasoning as LiteLLM's old/ui. Unlike LiteLLM, OmniRoute's split-port mode means this is structural (no network route exists) rather than an NPM path-deny rule that has to be maintained and could be misconfigured. Reach the dashboard only from the host itself or over SSH port-forward.
Every gateway call already requires a valid API key (Bearer token, see docs/proxy-key-onboarding.md), so no extra NPM-level auth is needed for the external hostname.
RAG knowledge graph (Neo4j) — knowledge.proxy-ai.home
Set up as an NPM Proxy Host pointing at this machine's LAN IP on Neo4j's Browser port (7474, see docker-compose.yml's neo4j service, PR #50). Internal-only, same as proxy-ai.home — no DMZ/external route, this is admin/dev tooling, not a client-facing endpoint. Bolt (7687, the actual query protocol) isn't proxied through NPM at all — clients on the LAN reach it directly at <this-machine>:7687.
Qdrant's dashboard (6333) stays on its raw LAN IP/port for now — no hostname assigned yet.