docs/docker-internal-inventory.md

Docker-internal inventory

Live at http://192.168.1.8:13080/docker-internal-inventory/.

Containers that have no LAN-published port — reachable only on their Docker bridge network. This is the third tier of our access model:

1. public — Zoraxy-routed via *.nuclide.systems (internet-reachable)
2. LAN — 192.168.1.0/24 direct (host port mapping)
3. docker-internal — only via container-to-container bridge (this doc)

Default per feedback_internal_only: keep new things at tier 2 or 3 unless there's a real external-access reason. Most of what is on tier 3 should stay there — that's the point of having three tiers.

Recommendation legend

• 🟢 Keep internal — sidecar / backend / engine, must not be exposed
• 🟡 Maybe — admin UI exists; could be useful to reach directly but low value
• 🔴 Expose to LAN — broken access pattern, fix recommended

CT 104 (docker host) — 43 internal-only

AI / MCP plumbing — all 🟢 keep internal

Backend MCP servers consumed only by the MCP gateway. Exposing them would bypass auth + audit.

• mcp-proxmox, gitea-mcp, mcp-immich, mcp-fetch, mcp-time, mcp-git, mcp-gotify, mcp-unifi, mcp-ntfy, mcp-markitdown, mcp-context7, mcp-youtube-transcript, mcp-sequential-thinking, mcp-wikipedia-mcp, mcp-gitlab, mcp-crawl4ai, coder-mcp, ariel-mcp, paperless-mcp, claude-max-bridge
• Plus the ephemeral crazy_colden/stoic_kirch/etc. (auto-spawned MCP one-shots — Docker name collisions, no static port).

Backends for exposed services — 🟢 keep internal

• karakeep_meilisearch, karakeep_chrome (Karakeep search + headless browser)
• immich_postgres, immich_redis, immich_machine_learning (Immich backends)
• immich_power_tools — 🟡 maybe. Power-user UI for Immich. Bind to LAN if you ever want to use it directly.
• paperless-ngx-tika-1, paperless-ngx-gotenberg-1, paperless-ngx-broker-1 (Paperless OCR/PDF/redis)
• redis-searxng, rdtclient (auxiliary)

Diagrams — 🟢 keep internal

• kroki, kroki-mermaid, kroki-excalidraw — rendered via MCP, no UI to expose.

Monitoring agents — 🟢 keep internal

• node-exporter (scraped by Prometheus on :9100 over container network; LAN exposure not needed since Prometheus is on the same LAN already)
• arcane-agent (talks back to Arcane server on CT 109)

CT 105 (nextcloud) — 8 internal-only

🟢 All keep internal — Nextcloud AIO architecture.

• nextcloud-aio-nextcloud (fronted by AIO apache proxy on :11000)
• nextcloud-aio-database (Postgres), nextcloud-aio-redis, nextcloud-aio-imaginary, nextcloud-aio-notify-push, nextcloud-aio-collabora, nextcloud-aio-docker-socket-proxy
• arcane-agent

Exposing the AIO backends directly would break Nextcloud's auth model and crash backups.

CT 109 (ops) — 1 internal-only

• node-exporter — 🟢 keep internal. Scraped via host.docker.internal from Prometheus on the same host.

CT 110 / 111 / 112 / 113 — arcane-agent only

🟢 All keep internal. The Arcane agent on each Docker host calls back to the Arcane server on 192.168.1.8:10002; no inbound LAN traffic needed.

Plus:

• CT 111: act-runner 🟢 (Gitea Actions runner — outbound to Gitea API; never needs inbound)
• CT 112: infisical-db, infisical-redis 🟢 (Infisical app on :8200 is the only intended entry)

Cross-tier issues spotted

None. The 3-tier model is clean across the fleet:

• No backend Postgres/Redis is accidentally LAN-bound
• No MCP server is double-exposed
• No admin UI is bound to LAN when it shouldn't be

Candidate LAN-bind, if you want them

If you ever want direct LAN access to one of the 🟡 services, the pattern is to add a ports: line to its compose entry:

Service	Suggested port	Why you might
immich_power_tools	:3001 on CT 104	Bulk Immich operations (album merge, dedup) the main UI doesn't expose

Everything else: leave at tier 3.