How Do You Update Ollama On An Air-Gapped Computer Without Reopening Internet Access?

August 20, 2026

Update Ollama offline by staging a pinned release on a connected system, verifying its hash and signature, transferring it through approved media, and proving the target never regained public egress.

You can update Ollama on an air-gapped computer without connecting that computer to the internet. Download one exact Ollama release and every required platform package on a separate connected staging system, record the release metadata, verify the artifacts, transfer them through your approved media process, install locally, and then prove that the isolated machine still has no public egress.

Do not temporarily reconnect the protected computer “just for the update.” That defeats the boundary you are trying to preserve. An offline update is a controlled supply-chain transfer, not a brief online update window.

The important catch is that removable media bridges the air gap. The Australian Cyber Security Centre's cross-domain guidance warns that routine maintenance and patching can compromise an isolated environment and that moving media between domains effectively bridges the gap. Your media approval, scanning, custody, and audit process therefore matter as much as the Ollama command.

The Short Answer

Use this five-part STAGE process:

  1. Select an exact Ollama version and platform package.
  2. Transfer the complete release bundle through an approved path.
  3. Authenticate the files with SHA-256 and, where available, a code signature.
  4. Guard the installed models, configuration, rollback copy, and network boundary.
  5. Exercise the local API and a known model while proving that public egress remains unavailable.

As of August 20, 2026, Ollama's latest GitHub release is v0.32.15. That release includes Windows installers and standalone archives, Linux archives for several architectures and GPU stacks, macOS packages, install scripts, and a sha256sum.txt file. Use the version approved for your environment rather than assuming that today's latest release is automatically the right one.

What Is Confirmed

Ollama documents installation paths that do not require its desktop updater to run on the protected machine.

The current Windows documentation provides a standalone ollama-windows-amd64.zip containing the CLI and NVIDIA GPU dependencies. It lists separate ROCm and MLX archives for hardware that needs them. The same page documents OLLAMA_MODELS for a custom model directory and identifies the default model/configuration area under the user's .ollama directory.

The current Linux documentation provides direct .tar.zst packages for manual installation. It also documents version-pinned online installation through OLLAMA_VERSION, but that pipe-to-shell path still downloads from the internet and is therefore a staging-system convenience—not an air-gapped-host procedure.

Ollama's GitHub releases currently publish a SHA-256 digest with each asset through GitHub's release API and include a downloadable checksum list. For example, v0.32.15 publishes distinct digests for OllamaSetup.exe, ollama-windows-amd64.zip, and each Linux archive. Those values are release-specific; never copy a digest from this article and apply it to a later version.

Ollama's current Windows install script also checks the Authenticode signature on OllamaSetup.exe and requires the signer organization to be Ollama Inc. before it runs the installer. The release workflow shows checksum generation and the required release artifacts.

That gives an operator several useful controls:

NIST explains that code signing provides integrity and source authentication. A checksum proves that two copies have the same bytes. A valid signature additionally helps identify who signed those bytes. They answer related but different questions, so use both when the artifact supports both.

What Is Still Unclear

Ollama does not publish one universal “air-gapped upgrade” procedure for every operating system, packaging method, GPU stack, service wrapper, and security policy.

Your exact install may be:

Those layouts have different service accounts, paths, permissions, GPU dependencies, rollback methods, and signing controls. A checksum alone also cannot prove that a compromised publisher account did not publish both a malicious file and a matching digest. Stronger environments may require an internal package repository, independent approval, malware analysis, software-bill-of-material review, or a vendor signature anchored in an approved trust store.

Signature validation can also behave differently offline. A protected Windows computer may not be able to retrieve current certificate-chain or revocation information. Verify the Authenticode signature on the connected staging system, preserve the certificate details and validation result, and follow your organization's offline trust-validation policy on the target. Do not reinterpret an unverifiable offline status as a valid signature.

Finally, updating the Ollama runtime does not automatically update every model, driver, front end, plug-in, or agent that uses it. The new runtime can be correct while the complete application is still incompatible or unexpectedly network-dependent.

Build A Complete Offline Update Bundle

Do not transfer only the first executable you find. Build a manifest for the complete change.

At minimum, record:

For v0.32.15, the official release contains different Windows archives for AMD64, ARM64, ROCm, and MLX, plus multiple Linux archives. Selecting the wrong architecture or omitting a GPU package can turn a routine update into a CPU fallback or failed service start.

The connected staging system should download from the exact tagged release, not a third-party mirror or an unversioned “latest” link. Save the release page or API response with the manifest so an auditor can reconstruct which digest belonged to which asset at approval time.

Verify The Bundle On The Connected Staging System

On Windows, calculate the installer or archive hash:

Get-FileHash -Algorithm SHA256 -LiteralPath .\OllamaSetup.exe
Get-FileHash -Algorithm SHA256 -LiteralPath .\ollama-windows-amd64.zip

For the signed Windows installer, also inspect the signature:

$signature = Get-AuthenticodeSignature -LiteralPath .\OllamaSetup.exe
$signature.Status
$signature.SignerCertificate.Subject

The current Ollama install script expects a valid signature whose signer subject contains the exact organization Ollama Inc.. Record the full subject, certificate thumbprint, timestamp information, and result rather than saving only a screenshot that omits details.

On Linux or macOS, calculate SHA-256 with an approved tool such as:

sha256sum ollama-linux-amd64.tar.zst

Compare the result character for character with the pinned release record. A checksum file downloaded beside the archive is useful for detecting transfer corruption. For higher assurance, preserve the digest through a separately controlled approval channel or internal repository so the file and its expected value are not accepted from one unaudited source in one step.

Scan And Quarantine Before Crossing The Boundary

Run the bundle through the controls required for your environment. That may include malware scanning, archive inspection, sandbox execution, package allowlisting, or a staging network that cannot reach the protected domain.

Use newly prepared or approved media. Label it with the change identifier and direction of transfer. Do not reuse a drive that routinely moves in both directions unless your cross-domain policy explicitly permits and sanitizes that workflow.

If the protected environment has an internal repository or cross-domain solution, import the artifact there instead of walking the same USB device between arbitrary workstations. An internal repository also makes it easier to preserve the release, digest, approval, and rollback package together.

Preserve Models And Configuration Before The Update

Ollama's runtime binaries and model storage are separate, but “separate” is not a backup.

Before changing anything, capture:

ollama -v
ollama ls

Record the process owner, service definition, environment variables, listening addresses, and model directory. On Windows, the documented default model/configuration location is under %HOMEPATH%\.ollama, while OLLAMA_MODELS can redirect model storage elsewhere. The Windows guide says an installer uninstall does not remove models stored in a changed OLLAMA_MODELS location, but that statement does not guarantee recovery from an operator mistake, disk failure, permission change, or service-account mismatch.

Back up configuration and the model manifest according to your recovery policy. Copying hundreds of gigabytes of model blobs may not be necessary when storage is already protected and snapshotted, but you need a tested way to restore the directory, permissions, and mapping the service actually uses.

Also preserve the previously working Ollama package. A rollback is much faster when the old signed installer or archive and its manifest are already inside the isolated environment.

Windows: Update Without Reconnecting The PC

Windows operators have two main choices.

Option 1: Use The Signed Desktop Installer

Stage the exact OllamaSetup.exe, verify its SHA-256 and Authenticode signature, transfer it through the approved path, quit the Ollama tray application, and run the installer locally.

The desktop installer is convenient for an existing desktop installation, but convenience does not change the network rule. Keep the target disconnected or under the same deny-egress policy throughout the install. Afterward, review whether the desktop updater remains enabled and confirm that it cannot reach the public update endpoint.

Do not assume the install succeeded because a window closed without an error. Verify the new version, service process, model directory, local API, and network behavior.

Option 2: Replace A Standalone CLI Deployment

For a service-style deployment, stage the documented ollama-windows-amd64.zip and any required companion archive. Prefer versioned directories, such as an internal layout that keeps the old and new runtime side by side, then change the service path only after the new files pass local inspection.

Ollama's Windows documentation says prior directories should be removed when upgrading the standalone package. In a controlled environment, translate that into a rollback-safe operation: stop the service, retain or snapshot the old directory, place the new complete directory, preserve the service account and environment, validate permissions, and only then restart. Do not merge a partial new archive into an old dependency directory.

Check that OLLAMA_MODELS still points to the intended location. A service running under another account may appear to have “lost” its models when it is actually reading a different home directory or lacks permission to the original store.

Linux: Update From A Staged Archive

Ollama's Linux guide documents manual updates by downloading and extracting the appropriate .tar.zst archive. On an air-gapped host, perform the download on the connected staging system and transfer the verified archive; do not run the documented curl command on the protected computer.

Before replacement:

  1. Confirm the architecture and GPU package.
  2. Record ollama -v, ollama ls, service status, and service overrides.
  3. Stop the Ollama service cleanly.
  4. Snapshot or preserve the old binary and library directory.
  5. Inspect the archive layout before extraction.
  6. Remove or replace old runtime libraries in the controlled manner your package procedure requires.
  7. Restore ownership and permissions if needed.
  8. Start the service and inspect its logs.

The official Linux page warns that old Ollama libraries should be removed when upgrading. That prevents an unreviewed mixture of old and new libraries, but it also makes rollback preparation essential. Do not delete the only working copy before the new archive and recovery path are both present inside the isolated domain.

If you use containers, mirror a digest-pinned image and its required layers into an approved internal registry. A tag alone is mutable; preserve the image digest, manifest, signature or attestation if available, and the old image needed for rollback.

Prove The Air Gap Stayed Closed

An update is not complete when the version number changes. It is complete when the new runtime works and the isolation claim still holds.

Run the following acceptance tests with synthetic content:

  1. Version: ollama -v returns the approved version.
  2. Inventory: ollama ls shows the expected local models.
  3. Local API: the expected client can reach http://localhost:11434 or the approved internal address.
  4. Inference: one known local model answers a harmless prompt.
  5. Persistence: restart the Ollama service and repeat the inference test.
  6. GPU path: logs or approved monitoring confirm the expected accelerator rather than an accidental CPU fallback.
  7. No pull: the test does not trigger a model download.
  8. No fallback: the front end does not switch to a hosted provider when the local call fails.
  9. No public egress: firewall, router, proxy, DNS, or network-sensor evidence shows no successful public connection from the target.
  10. Rollback: the operator can identify the exact procedure and files needed to restore the prior version.

Negative evidence matters. A successful local response proves that one local workflow works; it does not prove the machine had no other outbound path. Use the network control that enforces the air gap or isolated enclave, then verify the control's state and logs independently of Ollama.

Our earlier guide explains how to block Ollama update checks without breaking local models. For a true air-gapped update, preserve that denial throughout maintenance rather than temporarily relaxing it.

Common Offline-Update Mistakes

Reconnecting The Target For Five Minutes

This is an online update, not an offline one. It exposes the target to routes, DNS, update services, and any other process able to use the connection. It also makes the claim “the computer never regained internet access” false.

Trusting Only The Filename

OllamaSetup.exe and ollama-linux-amd64.tar.zst are predictable names. Verify the exact bytes and release. A familiar filename does not identify a version or publisher.

Comparing A Hash From The Same Untrusted Copy

A digest stored on the same removable drive catches accidental corruption only if the expected digest was trustworthy before transfer. Preserve the approved digest through the release record or a separate internal control.

Forgetting GPU Dependencies

A missing ROCm, MLX, JetPack, CUDA-related, or platform package may cause a failure or different execution path. Inventory the current runtime and select the complete matching release bundle.

Assuming Models Are Automatically Backed Up

An installer may leave models untouched while a changed account, environment variable, permission, or storage mount makes them inaccessible. Record the real model path and test it after restart.

Testing Only ollama -v

A correct version string does not prove that a model loads, a GPU works, the front end stays local, or egress is denied. Test the complete request path.

Does An Offline Ollama Update Preserve Privacy?

It preserves one important property: the protected machine does not need a public connection to acquire the new runtime. That reduces exposure and avoids the update check and download occurring from the target itself.

It does not prove that the entire AI workflow is private. A local Ollama server can be paired with:

Ollama's local-only controls and the network boundary are separate. See how to verify Ollama local-only mode and why using Ollama does not make every workflow automatically local.

Where OpenVeil Fits—And Where It Does Not

OpenVeil is a hosted, privacy-focused AI workspace for adults who want chat, private search, files, voice, images, video, and custom personas without maintaining local model packages, GPU dependencies, removable-media workflows, or rollback repositories.

Normal OpenVeil chat history and custom personas are stored in the user's browser rather than kept as a normal server-side chat-history record. OpenVeil does not use prompts, uploaded files, images, audio, selected browser-local history context, or AI outputs to train foundation models.

OpenVeil is not fully offline. Active requests still require processing by OpenVeil and necessary providers, including AI, search, upload-processing, hosting, routing, security, billing, and infrastructure providers. It is not anonymous, zero-log, an air-gap product, a patch-management service, or a replacement for self-controlled inference when active prompts must never leave your hardware.

If a hard requirement says the active request cannot leave the isolated machine, keep the tested local Ollama deployment. If you want hosted convenience with browser-local normal history and no foundation-model training on your prompts or files, compare OpenVeil and Ollama and try OpenVeil.

Frequently Asked Questions

Can Ollama be updated with no internet connection on the target computer?

Yes. Download the exact installer or archive on a connected staging system, verify it, move it through an approved transfer process, and install it locally while the target remains disconnected or denied public egress.

Which Ollama file should I download for an offline Windows update?

Use OllamaSetup.exe for the desktop application or the matching standalone Windows archive for a service-style deployment. Ollama currently publishes separate AMD64, ARM64, ROCm, and MLX assets. Choose the package set that matches the existing host and approved GPU path.

How do I verify an Ollama installer before transferring it?

Compare its SHA-256 with the value pinned from the exact GitHub release. For OllamaSetup.exe, also inspect the Authenticode signature and signer. Ollama's current installer script requires a valid signature from Ollama Inc..

Will updating Ollama delete downloaded models?

The runtime and model storage are separate, and Ollama documents a configurable OLLAMA_MODELS path. Still, record and back up the actual model path, permissions, and configuration. An account or path change can make intact models appear missing.

Can I use the Ollama Linux install script offline?

Not as written. The documented script and manual command download files from the internet. Use them on a staging system to identify or acquire a pinned release, then transfer the verified archive and apply it locally through your approved package procedure.

Is a USB drive safe for updating an air-gapped Ollama server?

Not automatically. Removable media bridges security domains and can carry malicious or unauthorized content. Use approved media, scanning, custody, direction-of-transfer, and sanitization controls. Prefer an approved cross-domain solution or internal repository where available.

Should I update to the newest Ollama release immediately?

Not without assessing it. Select a version based on security, compatibility, model support, GPU requirements, and organizational approval. Test it on a representative isolated system and keep a rollback package.

How can I prove the computer never reconnected during the update?

Use independent network evidence: physical topology, switch or firewall state, deny rules, interface state, and sensor logs. Then show that the local API and known model worked while public connection attempts remained unsuccessful. Ollama's version output alone cannot prove the network boundary.

The Bottom Line

Updating Ollama offline is practical, but the safe unit of work is larger than an installer. Pin one release, collect every required platform dependency, verify hashes and signatures, control the media transfer, preserve models and rollback files, install without changing the network boundary, and test both local inference and denied egress.

The strongest result is not “the update installed.” It is: the approved Ollama version runs the expected local model, the old version can be restored, and the protected computer never regained public internet access.

When privacy, account control, uploads, and search matter, OpenVeil gives you a private AI workspace designed for that job.