Skip to content

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.