Genesis Downloads · Air-gap workflow

Air-gap workflow

How signed bundles travel from downloads.genesis.autonomize.ai to your cluster without the cluster ever touching the public internet. One-way flow, sneakernet boundary, no callbacks.

Install guide → Sign in

The three planes

01
Vendor side — Autonomize-run.
This portal at downloads.genesis.autonomize.ai. Issues license keys, signs bundles with cosign keyless, generates SBOM + HIPAA PDF, uploads to Azure Blob, registers a Release row in Postgres. Customer never reaches in here.
02
Gap-host — one-way internet.
Customer-controlled workstation that can talk to downloads.genesis.autonomize.ai over HTTPS but has no connectivity to the customer's K8s cluster. Runs the genesis CLI to pull, verify, and stage bundles for sneakernet.
03
Customer cluster — air-gapped.
Your VPC. Receives .tar.zst bundles via USB / data diode / private artifact registry. The Genesis Operator (in-cluster Control Plane console) drives zarf package deploy. No call-home; opt-in heartbeat is aggregate-only.

The pull → verify → ship → ingest cycle

Pull on the gap-host.

Authenticate once with your license key, then pull both bundles for a release. Each pull writes {bundle}.tar.zst + {bundle}.tar.zst.cosign.bundle + {bundle}.tar.zst.sha256.

genesis login                          # paste sk_yourorg_*
genesis releases                       # list versions you're entitled to
genesis pull 3.2.10                    # ops + platform

B
Verify on the gap-host.
Verify before moving anything. cosign confirms the AzDO release pipeline signed it; sha256sum -c confirms bytes are intact. genesis verify wraps both. Pipe the SBOMs into your vulnerability scanner (trivy sbom ./sbom-3.2.10.cdx.json) and gate on your CVE policy before the bundles cross the boundary.
```
genesis verify ./genesis-ops-3.2.10.tar.zst
genesis verify ./genesis-platform-3.2.10.tar.zst
# ✓ cosign verify OK (identity: sigstore-fulcio)
# ✓ sha256 match
# ✓ SLSA provenance present (build: AzDO genesis-release #58432)
```
C
Ship across the boundary.
Copy the .tar.zst + both sidecars to a host with kubectl + zarf. USB stick, encrypted SCP, internal artifact registry, data diode — whatever your security policy requires. The cluster doesn't pull anything itself.

Ingest in the cluster.

Re-verify on the cluster-side host (zero-trust the carrier), then deploy ops first. The Control Plane wizard's first step (Pre-flight) walks you through customer-prereq verification and the platform install.

# re-verify (same artifacts, second integrity check)
genesis verify ./genesis-ops-3.2.10.tar.zst

# (optional) HolmesGPT credentials Secret — only if you want LLM-driven advice
kubectl create secret generic genesis-holmes-creds -n genesis \
  --from-literal=AZURE_OPENAI_ENDPOINT='https://your-aoai.openai.azure.com/' \
  --from-literal=AZURE_OPENAI_KEY='<your-key>' \
  --from-literal=AZURE_OPENAI_DEPLOYMENT='gpt-4.1' \
  --from-literal=AZURE_OPENAI_API_VERSION='2025-02-01-preview'

# deploy ops (stateless: CRDs + Operator + Control Plane console + 5 agents)
zarf package deploy genesis-ops-3.2.10.tar.zst
kubectl port-forward -n genesis svc/genesis-control-plane 8443:443
# open https://localhost:8443 → Pre-flight tab → Platform install tab
# (the wizard runs zarf package deploy genesis-platform-3.2.10.tar.zst for you)

What never crosses the boundary

No PHI back to vendor

The portal does not receive support bundles, telemetry, or model data unless you opt in. Even with telemetry on, only aggregate metrics ship — redactors strip PHI before any payload leaves the cluster.

REDACT · OPT-IN · AGGREGATE

No tunnels into the cluster

Autonomize cannot SSH, port-forward, or proxy into your cluster. If you need vendor support, the customer-side support bundle flow lets you attach a redacted bundle to a ticket — pull, never push.

NO TUNNEL · NO CALLBACK

No license-as-DRM

Your license key gates access to bundles. It does not gate cluster operation. Even if downloads.genesis.autonomize.ai goes down, your already-installed cluster keeps running indefinitely.

ACCESS-ONLY · NO HEARTBEAT-LOCK

Frequently surprising things

Why two bundles?

Ops brings the kopf operator, the Control Plane console, and the five agents (Preflight, Deploy, Health, Troubleshoot, Support-Bundle) — stateless, no Postgres or Keycloak yet. Platform is the Genesis umbrella (AI Studio + Knowledge Center + ModelHub + Keycloak + APISIX). Splitting the layers means platform upgrades don't restart your operator stack.

Customer brings their own statefuls

We do not ship Postgres, Redis, or cert-manager. The wizard's first step (Pre-flight) verifies your existing infra (Postgres TCP + SELECT 1, Redis PING, cert-manager presence, DNS, TLS chain, image registry) before any install runs.

Customer brings their own K8s + TLS

We don't ship k0s/k3s/embedded Kubernetes — use whatever you already operate (AKS, EKS, GKE, RKE2, OpenShift, on-prem). We don't issue certs either (Let's Encrypt and ACM are out of reach in air-gap anyway). You supply the TLS chain at install.

Image registry — three patterns

Customer-owned (Harbor, private ACR/ECR/GCR, Nexus, Artifactory), Zarf in-cluster (zarf init), or cloud-native attached (AKS attach-acr, GKE Artifact Registry, EKS ECR). Preflight validates whichever you picked.

HolmesGPT is opt-in advice, never a gate

Deterministic preflight is the source of truth. Adding the genesis-holmes-creds Secret enables LLM-driven natural-language explanations on FAIL/WARN rows + a Troubleshoot chat panel. Without it, deterministic checks still gate everything; advice copy is just disabled.

T1 only — never auto-apply

Operators stop at "recommend". The Troubleshoot Agent proposes ordered, copy-pasteable remediation; your platform-admin executes. There is no T2 tier and there will never be.