Online vs offline: two ways an AI software update arrives

TL;DR. A governed AI system still needs updates after go-live. If the server can reach a registry, the update arrives as a named online pack — container images plus the install recipe (a Helm chart). If it cannot freely reach the internet, the same version can arrive as one offline tarball you carry in, with a checksum and a signature you can check before you apply it. That is how the software pack gets into the building. It does not mean every site is cut off from the network, and it is not a sandbox around what an agent may do.

The Tuesday problem

Picture the person who keeps the servers.

A new version is ready. On an ordinary network they pull it. In a bureau, a clinic network, or a lab that does not let servers wander onto the public internet, “just pull” is not a sentence they can finish. The software still has to move. The useful question is which door that version uses.

There are two doors, for the same cut:

If the server can reach a registry	If it cannot freely reach the internet
An online pack: container-image references (OCI) plus Helm chart packages	One offline pack: a composed tarball of that cut
The network does the carrying	Someone carries the file in, on media the site already trusts
You can name the version you pulled	You can name the version inside the tarball

Both are tied to a version — product, channel, and version — so “what we installed” is a label you can point at. It is not “whatever was newest when someone clicked update.”

What those words mean, in the room

OCI is the ordinary way container images are named and stored. Think of it as the shipping label on a box of software, not a new product.

Helm is the install recipe Kubernetes already understands: which pieces to start, and in which order. An online update hands you that recipe at a version, plus references to the images it needs. The server pulls them when the network allows.

The offline tarball is that cut composed into one file. An admin who cannot pull images from the public internet can still receive the pack, check it, and apply it on the inside of the wall. The file is the update for that cut — the chart and the images included in it. It is not a promise that one tarball holds every model weight and every optional app on the estate. Model files move on their own path; this page is about the software pack.

A checksum rides with the file so you can see the bytes arrived intact. The release is also built so a signature can travel with the offline tarball. You check it was cut by us before you apply it, including on a machine with no network. That is the shape of the pack. It is not a claim that a signed drop has already landed in every building.

What this is, and what it leaves alone

Three mix-ups show up in the same meeting. Here is the plain version of each.

Air-gap-capable is a posture, not a census. Some sites pull online. Some allow a narrow path out. Some keep the servers dark and carry media in. OrchAI Portal is on-prem, and it can run without a path to the public internet. The two packs cover that range. They do not describe your building until someone has walked the network rule with you.

This is not a site runbook. You will not find a USB label, a VLAN, or a change window here. Those belong with the people who run that site. The point of this page is the shape of the update: a versioned online pack, or one offline tarball.

An offline pack is not an agent sandbox. A sandbox is about containment — what a tool-using agent is allowed to touch while it works. An offline pack is about how the software arrives when the network will not fetch it. Carrying a tarball through the door is a different job from keeping an agent inside a test box. If the question in the room is “what may the agent do?”, you want the harness and the sandbox conversation, not this one.

How this connects to what we build

OrchAI Portal is the enterprise runtime: the governed place the software runs, on infrastructure you control. An update is how that runtime moves forward when “pull it from the internet” is not available — and when it is.

Library still holds cited knowledge. Agents is still the front door for tools people may launch. Eval is still the quality gate before a change is trusted. The pack is how a software version arrives. It does not replace those jobs, and it is not a fifth product.

If the next meeting is “our servers cannot pull this,” talk to us or try the demo — and bring the network rule. Leave the site runbook at the site.

Frequently asked questions

Does this mean every customer is air-gapped? No. Portal can run on-prem, including where servers do not reach the public internet. Plenty of sites still update online. The two packs exist so the same software version has a door for each rule.

Is the offline tarball an agent sandbox? No. The tarball is how a software version arrives when the server cannot fetch it. A sandbox limits what an agent may do with tools.

How do we know the file is the one you cut? The offline pack carries a checksum, and the release is built so a signature can travel with the tarball. You check that before you apply it. This page describes that shape. It is not a record that a live signed drop has already been published to your site.