The seven decisions that shape a CID222 deployment — install medium, connectivity, deployment shape, licence, identity, certificate authority and update channel — and what each one commits you to afterwards.

Every CID222 deployment is the same product, and almost every difference between two deployments comes from seven decisions made before the virtual machine exists. Three of them are expensive to reverse. This page states each decision, what it changes on the day, and what it commits you to for the life of the appliance.

The seven decisions

Decision	Options	Decide it by
Install medium	Appliance OVA · installer ISO · registry-pull direct install	The link between you and the appliance host, and who owns the virtual machine image
Connectivity	Online · air-gapped	Whether the appliance can open outbound 443 in service, not just during the install
Deployment shape	Gateway · inline inspection beside a secure web gateway · both	Whether the customer already owns a device that inspects outbound web traffic
Licence	Built-in 30-day trial · a licensed package	Whether this is an evaluation or a deployment, and which capabilities have to work
Identity	Local accounts · Active Directory	Whether a directory service account exists yet
Certificate authority	Appliance CA · your own CA from a signing request · an uploaded certificate	Which authority your client machines already trust
Update channel	Online channel · offline `.cidupd` bundle	The same connectivity answer, applied to release delivery

Only the first is hard to change afterwards: reinstalling is the way to swap install media. The deployment shape, the licence tier, the directory, the certificate authority and the update channel are all changed later from the dashboard, at the cost of a reconcile or a re-issued licence.

Which install medium

All three media produce the same appliance: the same signed release images, the same updater, the same first-boot wizard, and the same self-update path afterwards. They differ in where the images come from and in what the console gives you.

	Appliance OVA	Installer ISO	Registry-pull direct install
What you receive	One `.ova` file, tens of gigabytes	One ISO, in an online or an air-gap flavour	A configuration set of roughly 300 KB, and credentials
Where the release images come from	Inside the appliance disk	Downloaded during provisioning (online flavour) or carried on the media (air-gap flavour)	Pulled from the CID222 registry by the machine itself
Runs on	Any hypervisor that imports an OVA	Bare metal, or a virtual machine you build	An Ubuntu 22.04 or 24.04 machine you already have
Needs internet to install	No	Online flavour: yes, for the duration. Air-gap flavour: no	Yes
Time to a dashboard	The import, plus a few minutes	30 to 60 minutes on the online flavour	Minutes, on a fast link
Console	A plain login prompt	A status screen with network, service and log tools behind a console password	Whatever the machine already had
Dashboard address	`http://<appliance-ip>/`	`https://<appliance-ip>/`	Plain HTTP until you put an HTTPS front in place
Static addressing at install time	Not offered	Offered by a dedicated boot entry	Whatever the machine already had
Who performs it	You	You	Your CID222 contact, or you with the runbook and credentials they supply

Read the columns as a rule of three:

The appliance host has a slow link to you and a fast one to the internet. Use the installer ISO, online flavour. Moving tens of gigabytes of OVA over the slow link is the thing you are avoiding.
The appliance host has no internet at all. Use the OVA, or the air-gap flavour of the ISO. Both carry every release image and download nothing.
The host already exists, already runs Ubuntu, and has good internet. Direct install is the fastest path, and the box self-updates from the channel afterwards like any appliance.

Warning

The direct install is not a self-service download. It needs registry credentials, a channel token and the release trust anchors, which your CID222 contact issues. It also produces a machine with no appliance console: there is no status screen and no network editor, so recovery is ordinary Linux administration.

Online or air-gapped

An appliance with no internet access is a supported deployment, not a degraded one. Detection runs entirely on models baked into the images, licensing is a file exchange, and updates are a bundle you carry in. What an air gap costs you is narrower than most people expect, and specific:

Capability	Online	Air-gapped
PII, toxicity, jailbreak and injection detection	Works	Works — every model is baked into its image at build time
Document parsing, redaction, OCR	Works	Works, provided the OCR models were baked into the image your release carries
Chat against a vendor cloud model	Works	Fails at send time. The credential still saves and the models still appear in the picker
Chat against a LAN or self-hosted model	Works	Works
Licensing and renewal	File exchange	File exchange — identical, no licence server is contacted either way
Updates	Online channel, or a bundle	Bundle only
Red-team simulation	Works	Needs a model of its own that the appliance can reach
Context summarisation	Works	Fails. It posts to the OpenAI and Anthropic clouds at fixed addresses and cannot be pointed at a LAN model

Warning

Decide the model endpoint at the same time as the air gap. A cloud provider key saves successfully on an isolated network, the models appear in every picker, and the first user request is where it fails. Configure at least one LAN or self-hosted model before you call an air-gapped appliance ready.

Which deployment shape

The shape decides which services the appliance starts, what has to be installed on client machines, and how much of the work is on your side rather than the appliance's. You choose it in the wizard's Deployment mode step, and you can change it afterwards under Settings → System Updates.

Shape	Choose it when	What CID222 runs	What your endpoints need
AI Gateway	Users and tools call the appliance directly — the browser extension, Claude Code, an API client	The gateway, the detection services, the model proxy	Nothing, beyond trusting the appliance certificate
Inline inspection (SWG/ICAP)	The customer already owns a device that inspects outbound web traffic — a secure web gateway of any make	The gateway plus the inspection listener on 1344	Nothing. The gateway administrator adds one external-service rule pointing at the appliance
Both	Both audiences exist on the same network	Everything above	Per audience, as above

A fourth arrangement exists and is not a wizard mode: where there is no secure web gateway to dial in, the appliance's own forward proxy re-signs browser traffic itself. That path installs a root certificate and a proxy auto-configuration file on every endpoint, which is the largest amount of client-side work of any shape. Confirm which of these you are doing before the install appointment — walking in expecting an existing gateway and finding none doubles the time on site.

Trial or licensed

A fresh appliance runs a built-in 30-day trial at the Starter capability set, stamped from first boot rather than from the day the image was built (CID_TRIAL_DAYS, CID_TRIAL_TIER). The trial is a working product, not a demonstration mode, and the whole install completes without a licence file.

	Evaluation on the trial	Licensed deployment
What you do at the wizard's licence step	Select Skip	Upload the `.lic` your CID222 contact issued
Capabilities	The Starter set	Your package's set
When it stops	30 days after first boot, then product routes answer `402` `LICENSE_EXPIRED`	At the expiry date in the file, after its own grace period
Evaluating a Professional or Enterprise capability	Not possible on the trial	Ask for a time-limited licence at that tier instead

Activation is a file exchange in both directions, so it is identical online and air-gapped. Nothing about the trial has to be undone: uploading a licence at any point replaces it.

Which authority signs the appliance certificate

Reaching the appliance by IP address over its own untrusted certificate is fine for a first look and fine for nothing else — the browser extension, Claude Code and an API client all refuse a certificate they do not trust.

Choice	Choose it when	The work	Renewal
Appliance CA	Nothing in your estate already signs for these names	Distribute one root certificate to your fleet, once	The host renews the leaf; the root is valid for ten years
Your own CA, from a signing request	You run an internal PKI your machines already trust	Generate the request on the appliance, have your CA sign it, install the result	Yours to do, before it lapses
An uploaded certificate	Your PKI issues the key as well as the certificate	Paste the certificate, chain and key	Yours to do, before it lapses

Two variants change the answer. An IP-only deployment with no DNS works, because the appliance puts its own addresses in the certificate — but every client then has to trust the appliance CA, since no public authority signs for a private address. A wildcard certificate has to come from your own PKI: the appliance's own names field accepts hostnames and IPv4 addresses only, so it neither issues nor requests a wildcard.

Which update channel

	Online channel	Offline bundle
How a release arrives	The appliance fetches a signed manifest from the channel host in `SYSTEM_UPDATE_CHANNEL_URL`	You obtain a signed `.cidupd` bundle and upload it in the dashboard
When	Only when an operator presses check or install. The appliance never polls	Only when you upload one
Egress	443 to the channel host	None
Verification	The same signature check on both paths — an unsigned or altered release is refused	The same

An air-gapped appliance is on the offline path by definition. A connected appliance can use either, and nothing is lost by leaving the channel configured and never pressing the button.

What each choice commits you to

Decision	What it changes later
Installer ISO rather than OVA	The appliance serves HTTPS only, so plain `http://` renders a blank page rather than an error. The console is a status screen rather than a login prompt
Direct install rather than either	No appliance console and no appliance-managed HTTPS front unless the release you install brings the certificate tooling with it
Air-gapped	Updates and licences are file exchanges forever. Your model has to live on the LAN
Inline inspection	The appliance's inspection listener admits callers by source address alone, and a virtual-machine lab defeats that control. Plan the peer's address before you rely on the allowlist
Trial	The appliance hard-blocks its product routes on day 31. Sign-in, the dashboard, the licence page and System Updates keep working, so it is always recoverable
Appliance CA	Every new client machine needs the root certificate before it can talk to the appliance. Every retired appliance needs it withdrawn again
Your own certificate	Expiry is yours to track. The appliance warns at 30 days but renews nothing it did not issue
Optional services in the package	Each one you enable raises the memory floor and lengthens an update. See Optional services

Limits and known gaps

The setup wizard cannot be re-run. Once it completes, its bootstrap routes refuse further calls and every answer is changed from its own Settings page instead. Plan the deployment mode and the administrator account before you start rather than during.
The licence is bound to the appliance's installation identity. Changing that identity invalidates the licence, and there is no self-service recovery — it takes a re-issued file. This is what makes an in-place move from a self-generated identity to a hardware-derived one a renewal rather than a setting.
Nothing in the product schedules a backup or restores one. The procedures in Backup and restore are manual and are what the appliance's layout supports, not a product capability.
There is no decommissioning workflow and no remote wipe. A retired appliance keeps working until its licence expires on its own dates; destroying the disk is the control.
Hyper-V cannot import the OVA, and there is no conversion procedure for you to run. Ask for a converted disk before the deployment date.

Requirements and sizing — what the medium you chose has to be given.
Network prerequisites — the egress matrix for the shape you chose.
Install on a hypervisor — the OVA path, one page per platform.
Install from the ISO — the installer path, and the branch for every network it meets.

Choose your install path