Air-gapped installation

Olympusx AI runs with no internet access once every image it pulls is in a registry the cluster can reach. This page covers what to mirror, how to keep the signatures, and the settings that point the install at your mirror. Read it before the install page for your platform.

What crosses the gap

What	When you need it
The platform’s own images and the Helm chart	Always
The operator, its bundle and its catalog	On an operator install
The bundled third-party components’ images	For each component you leave on: the database, the cache, the identity service, the document converter, the object store, the gateway, the tracing store
The PostgreSQL images the PostgreSQL operator runs	For the managed database and for tenant vector databases
The PostgreSQL operator itself	Through your existing operator mirror, before install day. The managed database does not start without it
The guardrails and reranker images	When you turn them on. They are pinned by digest and do not change every release, so mirror the digest your release pins rather than a version tag
The model packaging image	When you import models into your registry from inside the cluster
Model weights and inference runtimes	Separately, after the install (Model registry, Runtimes)

Budget the transfer around three images that carry model weights so nothing is downloaded at runtime: the guardrails service at about 9.5 GB, the reranker at about 3 GB and the document converter at about 2 GB. Everything else together is under 2 GB. One large model outweighs the whole platform several times over.

List the images

For a Helm install, every image reference is in the chart’s values, with its registry, repository, tag and, where pinned, digest:

helm pull oci://<registry>/charts/olympus --version <version> --untar -d ./chart
helm show values ./chart/olympus \
  | grep -E '^\s*(registry|repository|tag|digest|image|imageName|baseImage):'

For an operator install, the operator’s bundle lists every image a disconnected install needs in its related images. On OpenShift, oc-mirror reads that list and mirrors the catalog, the bundle, the operator and every related image together. On a connected cluster with the operator installed, print the list:

oc -n openshift-operators get csv olympus-operator.v<version> \
  -o jsonpath='{range .spec.relatedImages[*]}{.image}{"\n"}{end}'

Third-party images are pinned by digest where the chart pins them. Those digests name multi-architecture indexes: mirror the whole index, not one platform.

Mirror the images

Mirror the Olympusx AI images and the chart with cosign copy, not docker pull and docker push or a plain skopeo copy. A signature is a separate artifact in the registry; an ordinary mirror leaves it behind, and verification then fails exactly as it would for a tampered image. cosign copy brings the signature and the attestations with the image:

cosign copy <registry>/<image>:<version> <mirror>/<image>:<version>
cosign copy <registry>/charts/olympus:<version> <mirror>/charts/olympus:<version>

Repeat the first command for each Olympusx AI image in the list. For the guardrails and reranker images, copy the digest your release pins. Mirror the third-party images however you already mirror third-party images.

Verify from your own registry

Every Olympusx AI image and the chart are signed, and each image carries a software bill of materials and build provenance. Your Olympusx.ai contact gives you the public key, olympus-cosign.pub, and its SHA-256 fingerprint through a separate channel. Compare them first:

sha256sum olympus-cosign.pub

Then verify what landed in your registry, not the source:

cosign verify --key olympus-cosign.pub --insecure-ignore-tlog=true \
  <mirror>/<image>@<digest>

Output naming the key and the digest means the image is what Olympusx.ai built. An error means it is not: do not deploy it.

--insecure-ignore-tlog turns off the public transparency-log check only. The signature itself is still verified against the key.

Read the bill of materials from the same digest you verified:

docker buildx imagetools inspect <mirror>/<image>@<digest> \
  --format '{{ json .SBOM }}' > sbom.json

Deploy by digest once verified: a tag can be moved, a digest cannot.

Point the Helm chart at the mirror

image:
  registry: <mirror>
  pullSecrets:
    - name: <pull-secret>
gateway:
  image:
    registry: <mirror>

image.registry moves the platform’s own images. Each third-party component has its own image.registry in the values, as gateway does above; set every one you leave on. The PostgreSQL images the PostgreSQL operator runs are full references: postgresqlCNPG.imageName for the managed database, and the vector database image under vectorDatabase. Install the chart from your mirror:

helm install olympus oci://<mirror>/charts/olympus --version <version> \
  -n olympus -f olympus-values.yaml --wait --timeout 20m

Leave <pull-secret> out if the nodes can already pull from the mirror.

The database pods the PostgreSQL operator creates do not use the chart’s pull secret. The nodes must be able to pull those images by themselves: from a mirror path that needs no credential, with node-level registry credentials, or through a registry mirror configured on the container runtime.

Point the operator at the mirror

Repoint the catalog. Apply the CatalogSource from Install on OpenShift with image: set to your mirrored catalog. Applied unedited, it reaches out to the original registry and the operator never appears. Pin the catalog by digest; the poll interval then does nothing.
Move the platform’s images with spec.image.registry on the Olympus resource:
```
spec:
  image:
    registry: <mirror>
  secrets:
    registry: <pull-secret>
```
No trailing slash.
Redirect the third-party images with an ImageDigestMirrorSet, and an ImageTagMirrorSet for those referenced by tag. They redirect cluster-wide with no change to the resource. spec.image.registry does not move them.

Model serving with no internet access

The install needs nothing more. Before the first model deployment:

Model weights reach the cluster as images in your registry. A connected cluster can import and push them; with no connected cluster, Olympusx AI generates the commands for a machine that has access, and verifies what you push (Model registry). A bastion attached to a cluster can fetch them for it (Remote access).
Inference runtimes are copied into each cluster’s registry by digest (Runtimes).
Each cluster names its registry and pull credential in the console, and can be declared air-gapped so a deployment whose weights are missing is refused up front (Clusters).
Tool servers that tenants register are pulled from wherever you point them; mirror them like any other image.

Cloud model providers are unreachable from an air-gapped install.