After you install ollama

By Herd Latch editorial team · Last verified September 17, 2026 · Current release, published September 14, 2026

After you install the runner, open a new terminal so PATH picks up the CLI. Run ollama --version and confirm the tray app or service is present before you pull models.

Prove the install with a small chat: ollama run llama3.2 or another tiny tag. Send one short prompt. That single prove step catches broken PATH entries and half-finished Setup runs.

Opening doors

Note free disk space for the local model library. Large pulls fail late when the volume is nearly full. Shared lab images should document where models live.

Pick one update door and write it down: winget upgrade for the verified winget id, brew upgrade --cask ollama-app, or a newer Windows Setup.exe from GitHub Releases.

Skip exposing the API beyond loopback until local chat works and your network policy is clear. Day-one success is a local prompt, not a public URL.

Prove steps

Windows desks should confirm Windows Setup.exe or winget finished without SmartScreen confusion. Mac desks should confirm the app is in Applications when using the dmg path.

Linux desks should confirm the service or binary responds after install.sh. Offline tar.zst installs should document the extract path for the next admin.

Related: first run, for this computer, home.

Room notes

If ollama run hangs on the first pull, check network and proxy settings before you reinstall. Reinstall rarely fixes a blocked download.

Create a short allow-list of model tags for the room. Random multi-gigabyte experiments belong on a scratch account, not on the golden image.

Optional Modelfiles can wait until the default chat path is boringly reliable. Teach the prove command first.

When students report “it does nothing”, ask for ollama --version output and the exact command they typed. Most tickets are PATH or offline DNS problems.

Prove commands

ollama --version

ollama run llama3.2

ollama list

Windows update door

winget upgrade -e --id Ollama.the runner

Lab checklist habits

Write the installer door beside the machine name before you image a room. Include whether winget, the Windows Setup executable, the Homebrew cask, or the Linux install script was blessed for that ring. Substitutes should not guess under pressure during the first week of term.

Prove one short CLI chat after every reimage. That single step catches vanished PATH entries, truncated downloads, and adware shortcuts that reappear from old browser folders. Keep a spare copy of the current Setup on trusted media when catalogs are flaky.

• Record the GitHub tag used for the golden image.
• Note free disk space before large model pulls.
• Keep the local API on loopback until network review says otherwise.

Support tickets that resolve faster

Ask for the operating system build, the door used, and the exact CLI error text. Vague reports that only say artificial intelligence feels wrong waste a day. Attach version command output when the user can copy it.

Proxy desks should test one model pull on a clean path once, then document any required exception. Offline classrooms should pre-stage weights on a well-connected machine instead of launching twelve simultaneous downloads on demo day.

Update and rollback notes

Pick one update door per room and stick to it for a semester. Mixing winget, Setup, and brew without notes creates version drift tickets. Keep the previous Setup on trusted media so rollback is a file copy, not a scavenger hunt.

After an upgrade, prove a small chat again before you seal the image. Large experimental model tags belong on scratch accounts, not on the shared golden profile. Maintenance windows should remove stale tags so libraries do not grow without limits.

Related reading on this guide: the home install panel, the first-hour checklist, and the guides hub.