Network prerequisites

What the network team has to agree before the virtual machine exists: which ports reach the appliance, what the appliance reaches outward and for how long, and how it behaves behind a corporate proxy. Settle this first — a blocked path is the single most common reason an ISO installation stops halfway.

Inbound — what must reach the appliance

Which process answers on 80 and 443 depends on how the appliance was delivered: the source and production compose files put a Caddy reverse proxy there, while an appliance installed from the ISO is fronted by a separate nginx container outside the compose project. The ports and their purpose are the same either way.

Two rules govern this table.

• Only 80 and 443 are open in a standard deployment. Everything else is either loopback-bound or off. The ICAP listener publishes on the interface named by ICAP_PUBLISH, which defaults to 127.0.0.1; exposing it to a LAN gateway is a deliberate change, and the port must then be firewalled to that gateway's address.
• The inline proxy binds on the host network namespace. It runs with host networking so that client addresses arrive as themselves, which means a port already occupied on the host is not reported as a failure — the container still shows as running. Survey the ports before first boot.

The full per-service table, with the compose profile and declared memory limit of each container, is generated in services, ports and profiles. The variables that move these ports — ICAP_PORT, ICAP_PUBLISH, ICAP_BIND, INLINE_PROXY_HTTPS_PORT, INLINE_PROXY_TPROXY_PORT, INLINE_PROXY_PUBLIC_PORT, USERID_AGENT_PORT — are in environment variables.

Outbound — what the appliance reaches, and when

There is no licensing egress. A licence is a signed file bound to the appliance's installation id. You export an activation request, receive a .lic, and upload it. Expiry is a local clock comparison. The appliance never contacts a licence server, online or air-gapped.

CID222 itself reports nothing home. No analytics, error-reporting or usage-reporting client is written into the gateway, the dashboard or the detection services. One exception is worth naming: the red-team simulator container bundles its upstream framework's own telemetry module, and the appliance sets no opt-out for it. On a network with no egress the question is moot; on a connected one, block that container's outbound access if the possibility matters to you.

Corporate proxy

A site proxy is supported on every path, but it has to be given to the appliance rather than inferred.

• During the setup wizard. The Connectivity step takes an HTTPS proxy URL and persists it; it is applied when you select Finish.
• During ISO provisioning. A proxy the installer was given is copied into Docker's own configuration before the first image pull, because Docker reads neither the package manager's configuration nor the shell environment. The fully unattended boot entry never asks for one, so on a proxy-only segment provisioning stops and you set the proxy from the console before rebooting.
• TLS-inspecting proxies. These work, provided the site's own certificate authority is trusted on the appliance. Installation media built for your site can carry that certificate; otherwise place it in /usr/local/share/ca-certificates, run update-ca-certificates, and reboot.

The environment variables are HTTP_PROXY, HTTPS_PROXY and NO_PROXY, documented in environment variables.

Name resolution

The appliance uses the resolvers the network gives it. Two consequences are worth stating before anyone argues about whether DNS works.

• The installer repairs its own resolution, within limits. If your resolver cannot answer for the registry, the installer routes that one domain to public resolvers and makes the change permanent. If those are blocked too, it falls back to the address the media was built with, and removes that pin if it turns out not to work.
• A browser proving DNS works proves nothing about the appliance. Browsers resolve over DNS-over-HTTPS and keep working on a network whose ordinary DNS is broken.

Time

The appliance's clock has to be right for two independent reasons: TLS rejects a certificate that is not yet valid, and licence expiry is a local clock comparison with no network time source to correct it.

On an ISO-installed appliance the first-boot pass restarts the system time-synchronisation service and waits up to 20 seconds for it to converge before it contacts the registry, warning rather than stopping if it does not. Where an ICAP integration correlates events with a third-party gateway's logs, keep the two clocks synchronised against the same time source.

Proving the path is really open

"This network has full internet access" is usually said in good faith and is usually about a different path than the one the appliance uses. Each of the following passes routinely while an installation still fails, so test the exact thing the installer needs, on the appliance itself:

1. A browser reaching the registry proves little. Browsers resolve names over DNS-over-HTTPS, so they keep working on a network whose ordinary DNS is broken — and the browser is usually on a different machine than the appliance.
2. A successful ping proves little. It tests ICMP. Image pulls are TCP on port 443, and a firewall that permits ICMP and blocks 443 is an ordinary configuration.
3. A working package install proves little. The Ubuntu mirrors are served over port 80, so package installs succeed on a network that blocks outbound 443 entirely.

The three tests that do prove it isolate name resolution, the TCP path and the authenticated pull, in that order. Run them from the appliance console:

# 1. Name resolution, from the appliance's own resolver
nslookup <registry-host>
 
# 2. The TCP path on 443, without DNS in the way
timeout 5 bash -c '</dev/tcp/<registry-ip>/443' && echo "443 open" || echo "443 blocked"
 
# 3. The authenticated pull path, end to end
sudo bash -c 'set -a; . /opt/cid/.env; set +a; printf "%s" "$REGISTRY_PULL_PASSWORD" \
  | docker login "$REGISTRY_PULL_HOST" -u "$REGISTRY_PULL_USER" --password-stdin'

They are not interchangeable because each one can pass while the next fails: resolution can succeed against a resolver that answers with a block page, the TCP path can open to a TLS-inspecting device that then presents its own certificate, and the login can still be refused by credentials that the media carries but the registry no longer honours.

For a deployment that will re-proxy browser traffic, also confirm the upstream model hosts resolve to real addresses from inside the network rather than to a captive portal or block page. A 403 from one of them is fine; a timeout is not.

Air-gapped operation

An appliance with no internet access is a supported deployment, not a degraded one.

• Installation — use the air-gap installer ISO or the OVA. Both carry the release images and download nothing.
• Setup — the first-boot wizard needs no network at all.
• Detection — every detection model is baked into its image at build time. PII, toxicity, jailbreak and injection detection, language detection, document parsing, redaction and the default OCR engine all run with no egress.
• Licensing — export the activation request to removable media, receive the signed .lic, and upload it. No network is involved at either end.
• Updates — obtain the signed .cidupd bundle out of band and upload it. The appliance never phones home.
• Chat — works only against a model the appliance can actually reach, which on an isolated network means a self-hosted or LAN endpoint.

Three things degrade offline and are worth knowing in advance: the highest-accuracy OCR engine downloads its model at first use and therefore does not work air-gapped, the red-team simulator needs a model of its own, and context summarisation posts to the OpenAI and Anthropic clouds at hard-coded addresses, so it cannot be pointed at a LAN model and fails on an isolated network.

Related

• Requirements and sizing — the host the network is being opened to.
• Install from the ISO — where these egress rules are exercised for the first and only time.
• Services, ports and profiles — the generated per-container port and profile table.