Local AI network binding: trace the caller before exposing an endpoint

Inventory endpoints and intended callers

Start with a row for each listener or externally meaningful path, not one row labelled “AI server.” One runtime may expose a model API, a metrics listener and a separate UI; a vector database can expose REST, gRPC, metrics and health routes. Include only components actually selected. An orchestration service belongs in the inventory when it calls or serves the model, but this page does not configure its workflows.

Write down the intended caller precisely: for example, “the n8n container on user-defined network ai-backend” or “an operator on the private administration subnet.” “Internal” and “localhost” are not precise enough. Identify the caller’s namespace, address or service name, DNS source, route and owner. A browser is a distinct caller from the server process that delivered its page.

Do not assume a metrics or health path is harmless because it is not the generation API. Qdrant’s captured monitoring documentation describes /metrics and telemetry endpoints, while its security documentation distinguishes self-hosted configuration from managed defaults. Its health endpoints have their own access behavior. Confirm the exact selected version and route rather than copying a generic path list. Likewise, vLLM’s OpenAI-compatible server documentation notes an API-key limitation for some endpoints; a key configured for one API surface must not be described as protecting every route.

Trace the complete path

For every intended caller, draw the request path in order and then trace the response back. The path can cross process sockets, container namespaces, bridge networks, host publication, routing/NAT, a host firewall, a provider control, and a reverse proxy. A conclusion is only as strong as the least understood hop. Record where TLS ends and whether the next hop is protected.

Process bind and container interface

A bind address names interfaces visible to the process in its own network namespace. Loopback means that namespace’s local interface. On a host process, 127.0.0.1 is host loopback. In a container, the container has its own loopback; a different container’s localhost is not that address. A process listening on all interfaces inside a container can still be unreachable from outside if there is no route or publication. The reverse is also important: a host-side publication or proxy can create another path even when the service’s own configuration sounds local.

Inspect the selected runtime’s documented settings and actual service configuration. Ollama’s FAQ capture describes a default loopback listener on port 11434 and configuration through OLLAMA_HOST; that is a version-sensitive documentation statement to recheck for the installed build. The captured llama.cpp server README at commit 6c01da6278ab6c69ed67d9124806b50d2b299ba7 documents a --host default of 127.0.0.1 for that source snapshot. It does not establish the defaults of every released binary. Record the runtime version and compare it with its own help and matching docs before inferring the listener.

Docker network and host publication

Docker network membership, name resolution and host port publication are different controls. Containers attached to the same user-defined bridge can address one another by service or container name. The default bridge does not provide that same name-resolution behavior. A direct same-network caller generally needs an internal container route, not a host-published port. Whether an application listens on the container interface is a separate condition.

Publishing a port maps a host port to a container port. The host address matters: a loopback-only publication and an all-host-interface publication have different reachability implications. Docker’s port-publishing documentation warns that published ports may be externally reachable depending on the mapping and host networking. Do not take a sample -p command as a recommendation to expose an inference API publicly. Inspect the actual Compose configuration or container metadata in the chosen environment and verify the host IP, protocol and port mapping. Avoid printing environment variables or credential-bearing configuration into notes.

Docker’s firewall behavior also complicates a simplistic “UFW allows/denies it” conclusion. The captured Docker firewall guidance explains that published traffic can be diverted through Docker-managed rules before ordinary UFW input handling. Consequently, a UFW rule list alone does not establish that a published container port is blocked. Use Docker’s current guidance for the selected engine and firewall backend, review the active rules with the host operator, and test only the approved route. Do not disable a firewall as a diagnostic shortcut.

Host, provider, proxy and routing controls

For each edge, record the control owner and the intended source and destination: container bridge, host interface, private subnet, provider network, proxy, or public interface. Include routing, NAT and the return path. A request may arrive but fail on its response path; conversely, a proxy may accept traffic on one address and forward it to a loopback backend. An endpoint’s effective exposure is the union of routes, not the most restrictive-looking single rule.

Record host firewall implementation and version, rules relevant to the exact protocol and port, Docker’s forwarding behavior, provider firewall/security-group scope, and any proxy listener/allowlist. Provider network controls are product-specific and must be verified from the actual account or provider documentation by an authorized owner. The article does not assert that a provider firewall exists, is enabled, or has a particular default. Private address space also does not create a route or authorize every peer on that network.

For a reverse proxy, map client-to-proxy and proxy-to-backend separately: listener address, DNS, certificate name, TLS termination, backend destination, forwarded identity headers and upstream transport. If TLS stops at the proxy, state whether the backend segment is trusted and isolated. Confirm certificate name/validity through the selected operator’s normal approved process. Do not paste private keys, bearer tokens, API keys, full request bodies or sensitive logs into the worksheet.

Identity and endpoint protection

For each endpoint, distinguish network reachability from caller authentication, authorization, encryption and browser origin policy. CORS controls which browser origins may read certain cross-origin responses; it does not establish the identity of a caller, authenticate a command-line client, or replace network restrictions. An origin allowlist is not an access-control boundary for the service API.

Ollama’s FAQ documents configurable cross-origin origins and a server bind setting. Neither statement means that loopback protects every service in a Compose stack. Another container, published port, proxy or host route may provide a separate path. For vLLM, check the exact version’s API-key coverage and documented exceptions endpoint by endpoint. For llama.cpp, optional authentication and related server features in a source-head README are not universal release defaults; inspect the deployed build’s own options and behavior before relying on them.

Qdrant’s captured security documentation lists API-key authentication, network binding and TLS among self-hosted controls and says these must be explicitly configured for self-hosted open-source deployments. The exact configuration and feature availability are version-sensitive. Metrics, health, internal cluster ports and REST/gRPC listeners may have different protection and audience. Mark each separately; do not infer that one key or TLS listener covers all of them.

Authentication evidence should state mechanism, where it is enforced, which paths it covers, how credentials are supplied without revealing them, and how a deny case will be checked. TLS evidence should identify the client-to-server segments encrypted and where termination occurs. If the owner cannot answer those points, pause reachability approval.

Choose target reachability by caller

Select the row that matches the actual placement. These are distinct topologies, not steps to combine. The Docker and n8n guidance below is bounded to the captured n8n documentation’s Ollama connection cases; verify the current documentation, engine, platform and compose arrangement before applying it. In particular, 0.0.0.0 is a bind inside a stated topology, not a guarantee of private exposure and not a blanket instruction to bind a public host interface.

Fill an allow/deny matrix before connection checks. “Deny” means a policy decision to verify from a specifically authorized vantage point, not a license to probe neighboring machines or unknown addresses.

Use Article 10 to decide where n8n and resident model/data services belong and which process is the caller. Use Article 5 for runtime endpoint and default questions, Article 6 for Qdrant endpoint scope, and Article 2 to account for selected cross-host or client traffic. Start with the Local AI decision hub in Article 1.

Authorized verification runbook

This is a controlled observation plan. The command blocks are reader templates, not commands run for this article. They make a request only after the operator edits the named fields, confirms the endpoint from the same caller whose path is being evaluated, and sets the exact authorization gate. The operator must own or have written authorization for the system, endpoint, caller, route, and time window. Do not test a name or address merely because it appears in DNS or belongs to a provider range.

Before the window

1. Name the owner and authority. Record the owner, operator, approval reference, allowed source and destination, and permitted request. Omit any host or network outside that scope.
2. Freeze the expected path. Complete one matrix row per endpoint with source namespace, destination, DNS/address, listener, Docker mapping, firewall/proxy path, authentication, TLS, and return route. State expected allow and deny outcomes.
3. Set a bounded window and stop trigger. Record start/end time, impact constraints, request, and stop authority. Stop on unexpected reachability, exposure, authentication uncertainty, route mismatch, service instability, or unexpected data.
4. Preserve a rollback point. Record the last approved configuration revision and the owner authorized to revert it. These examples make no configuration changes. A separately approved change needs its own diff, backup where appropriate, rollback action, and post-change owner.
5. Protect evidence. Retain only time/timezone, source vantage, destination label, authorized resolution result, response category, configuration revision, and observer. Redact keys, tokens, cookies, private addresses where required, prompts, bodies, and sensitive logs.

Discover the selected local tools

Choose the actual host and shell first. In a POSIX shell, this bounded discovery block only reports whether Docker and curl are available, then prints curl’s client version when present; it makes no network request and does not inspect containers. It is a shell-specific template, not a Windows command. Consult the installed versions’ local help/manual before choosing a platform-specific alternative. If Docker is unavailable or the selected object is not a container on this host, record that branch as unsupported here and use the host owner’s documented read-only management interface. Do not install a tool to complete this worksheet.

command -v docker || true
if command -v curl >/dev/null 2>&1; then
  curl --version
else
  printf '%s\n' 'curl unavailable; use the selected platform documentation or record unsupported.'
fi
# If docker is present, consult the installed CLI documentation before the
# optional read-only container template below. Do not substitute other flags.

For a selected Docker container, fill in its exact name or ID from the authorized inventory. This template prints only the image, attached network names and addresses, and published port mappings; it deliberately excludes the full configuration and environment. The official CLI documents docker inspect --type container --format and these data fields. If the installed CLI does not support the documented form, stop and record “unsupported on selected CLI”; do not guess flags or dump full output.

# Reader template: Bash / POSIX shell. Replace the value before opting in.
I_HAVE_OWNER_AUTHORIZATION='REPLACE_WITH_yes_ONLY_AFTER_APPROVAL'
CONTAINER_NAME='REPLACE_WITH_AUTHORIZED_CONTAINER_NAME_OR_ID'
if [ "$I_HAVE_OWNER_AUTHORIZATION" != 'yes' ] ||
   [ "$CONTAINER_NAME" = 'REPLACE_WITH_AUTHORIZED_CONTAINER_NAME_OR_ID' ] ||
   [ -z "$CONTAINER_NAME" ]; then
  printf '%s\n' 'STOP: set explicit authorization and the selected container.'
  exit 1
fi
command -v docker >/dev/null 2>&1 || { printf '%s\n' 'STOP: Docker CLI unavailable; use the selected platform owner-approved read-only interface.'; exit 1; }
docker inspect --type container --format='image={{.Config.Image}} networks={{range $name, $network := .NetworkSettings.Networks}}{{$name}}={{$network.IPAddress}} {{end}} ports={{range $port, $bindings := .NetworkSettings.Ports}}{{$port}}->{{with $bindings}}{{(index . 0).HostPort}}{{else}}unpublished{{end}} {{end}}' "$CONTAINER_NAME"

This format is based on the official Docker CLI reference, which documents .Config.Image, .NetworkSettings.Networks, and .NetworkSettings.Ports, including the nil/unpublished case and host port. It intentionally does not derive the host publication address; read that from the selected Compose/config source through its owner-approved path. Review results locally and record only relevant fields. Never use a whole-configuration format: environment values can contain credentials. Docker publication can interact with host firewall processing; the captured Docker firewall guidance warns that UFW alone may not determine published-port reachability. Have the host owner review the actual selected engine and firewall path. No network, firewall, listener, or service changes belong in discovery.

Make one bounded request from the chosen caller

The following exact request example is only for an authorized Ollama endpoint. First select the URL that this same caller is configured to use: use http://localhost:11434 only when Ollama is on that caller’s own host or in its own network namespace; for a container or remote caller, replace it with the exact already-approved service hostname and port reachable from that caller (for example, a private DNS name, never an assumed loopback). Do not run this from a different machine and call it a test of the intended caller path. This uses Ollama’s documented read-only GET /api/version route, with explicit three-second connection and ten-second total time limits. Plain HTTP is permitted only on an explicitly trusted, approved private route; use HTTPS only if that exact endpoint is configured for TLS and its certificate/name are expected. Curl’s default certificate and host verification remain enabled. No credentials are supplied.

# Reader template: edit the URL to the exact selected caller endpoint.
# Set the authorization value to yes only after written approval for this request.
I_HAVE_OWNER_AUTHORIZATION='REPLACE_WITH_yes_ONLY_AFTER_APPROVAL'
I_CONFIRMED_THIS_IS_THE_APPROVED_SAME_CALLER_ENDPOINT='REPLACE_WITH_yes_ONLY_AFTER_CONFIRMING_CALLER_AND_URL'
OLLAMA_BASE_URL='REPLACE_WITH_EXACT_APPROVED_URL_FROM_THIS_CALLER'
CONNECT_TIMEOUT_SECONDS='3'
MAX_TIME_SECONDS='10'
if [ "$I_HAVE_OWNER_AUTHORIZATION" != 'yes' ] ||
   [ "$I_CONFIRMED_THIS_IS_THE_APPROVED_SAME_CALLER_ENDPOINT" != 'yes' ] ||
   [ "$OLLAMA_BASE_URL" = 'REPLACE_WITH_EXACT_APPROVED_URL_FROM_THIS_CALLER' ] ||
   [ -z "$OLLAMA_BASE_URL" ] ||
   [ "$CONNECT_TIMEOUT_SECONDS" != '3' ] ||
   [ "$MAX_TIME_SECONDS" != '10' ]; then
  printf '%s\n' 'STOP: authorization, same-caller confirmation, exact URL, and fixed timeouts are required.'
  exit 1
fi
case "$OLLAMA_BASE_URL" in
  http://*|https://*) ;;
  *) printf '%s\n' 'STOP: URL must explicitly select http:// or https://.'; exit 1 ;;
esac
command -v curl >/dev/null 2>&1 || { printf '%s\n' 'STOP: curl unavailable; use the selected platform documented client or record unsupported.'; exit 1; }
# -q is curl's first option so a user curlrc cannot add request settings.
curl -q --connect-timeout "$CONNECT_TIMEOUT_SECONDS" --max-time "$MAX_TIME_SECONDS" -- "$OLLAMA_BASE_URL/api/version"

The official curl manual requires -q (or --disable) to be the first option to prevent loading the default curlrc; the example places -q first. The manual documents --connect-timeout and --max-time. Do not add verbose or trace flags: those can expose request details. If the selected endpoint is not Ollama, do not guess a health or version path; use only that selected product release’s documented low-impact request and record the exact path and source. If authentication is required, stop and arrange the owner-approved credential method separately; do not put a token in the command, shell history, environment dump, or receipt.

After the request, compare actual observations with the prewritten matrix. A timeout does not prove a firewall deny: DNS, routing, listener state, TLS, proxy behavior, and return path can also explain it. Test an expected-deny case only from a specifically authorized source to a specifically authorized destination. Never scan, enumerate provider ranges, probe public DNS targets, or try an unauthorized external caller.

For each outcome, record whether it matched policy, the exact vantage and endpoint, response category and time, policy evidence reviewed, and follow-up owner. If reachability is unexpected or authentication coverage is unknown, stop further requests, preserve redacted evidence, notify the owner, and use only a separately reviewed authorized change to restrict exposure.

Evidence and update gate

Source captures checked 2026-11-06. The source material supports bounded documentation statements and a procedure; it contains no observation of this reader’s host, firewall, provider network or endpoint. Runtime defaults, authentication coverage, Docker behavior and provider controls can change. Before acting, recheck the exact installed runtime/build, Docker engine and firewall versions, selected provider routing controls, endpoint paths, certificates and caller placements. Keep observed facts separate from expected policy.

• Ollama FAQ — captured guidance on loopback, OLLAMA_HOST, origins and server configuration; version-sensitive documentation, recheck against the selected build.
• Ollama Docker documentation — captured container publishing example; an example mapping is not approval for public exposure.
• n8n Ollama node common issues — captured caller-placement branches for host, Docker and shared network cases; confirm current docs and actual topology.
• Docker: port publishing — host publication and reachability distinctions.
• Docker: packet filtering and firewalls — Docker firewall behavior, including UFW interaction; inspect the selected engine’s actual rules and path.
• vLLM OpenAI-compatible server — API-key endpoint coverage and documented limitations; verify the installed version.
• llama.cpp server README at captured commit — source-specific server behavior, not a universal released default.
• Qdrant security and Qdrant monitoring — captured self-hosted controls and endpoint roles; check version and configured routes.
• Docker CLI reference: docker inspect — targeted source recheck 2026-11-06; documents the selected container type, format option, image, network, and port-binding fields used in the redacted read-only template.
• Ollama API: Get version — targeted source recheck 2026-11-06; documents GET /api/version and the same-host example URL.
• curl manual — targeted source recheck 2026-11-06; -q/--disable must be curl’s first option, with documented connection and total timeouts and default TLS verification. The template places -q first.
• NIST SP 800-41 Rev. 1 — historical firewall guidance published September 2009; neither a current AI-specific standard nor authorization to test.

For the wider workload decision, see the Local AI VPS hub. The related storage and egress worksheet, runtime comparison, Qdrant and RAG planning page, and n8n placement decision own their respective questions. Draft checked 2026-11-06; no endpoint test or deployment observation is claimed.