ODS V3 ships an installer that pulls code straight from the main branch

The Linux and macOS install is curl piped into bash

The whole Linux and macOS first run is one line:

curl -fsSL https://install.osmantic.com/ods.sh | bash

The only stated prerequisite is that Docker is installed and running. ODS then installs the stack, picks a model sized for your hardware, starts the services and hands you a local web UI.

What that line hides is the interesting part. The endpoint is described as hosted and as proxying the current bootstrap from the repository main branch, and reviewed merges reach it automatically after an edge-cache refresh. So the script you execute is whatever main holds at the moment of the request, not a fixed artifact. The docs offer two outs: ODS_REF selects a compatible repository checkout, and the installer trust page explains how to inspect the script or install an audited commit by hand. No release has yet qualified for the verified channel, so the verified installer preview stays separate.

That is the core bargain of this project, stated plainly.

Windows is not a native install but a WSL2 install with six prompts

Windows users get a different document entirely. The PowerShell block downloads the public ODS source ZIP for main and hands the work to Ubuntu under WSL2:

$ProgressPreference = "SilentlyContinue"
$odsSrc = Join-Path $env:TEMP ("ods-install-" + [guid]::NewGuid().ToString("N"))
$odsZip = Join-Path $odsSrc "ods-main.zip"
New-Item -ItemType Directory -Path $odsSrc | Out-Null
Invoke-WebRequest "https://github.com/Osmantic/ODS/archive/refs/heads/main.zip" -OutFile $odsZip
Expand-Archive -LiteralPath $odsZip -DestinationPath $odsSrc
$odsEntry = Join-Path $odsSrc 'ODS-main\install.ps1'

The installer then does six things in order: it checks for 40 GB of free disk and hardware virtualization, offers to enable WSL2 and install Docker Desktop through winget (which needs administrator permission and one restart), offers to download Ubuntu 24.04 and asks you for an Ubuntu username and password in PowerShell, starts Docker Desktop and checks that Ubuntu is connected to it, installs ODS inside Ubuntu with --pixel --no-hermes, then verifies Pixel and Portal and opens Portal in the browser.

Run it in a normal PowerShell window, not as administrator. There is no fallback to Hermes or to a native Windows installer, and existing native installations are neither migrated nor deleted.

ods update touches container images, not code

Two update paths exist and they do different amounts of work. Re-running the installer is what existing installations use to pick up code fixes. The CLI command ods update refreshes container images only.

That split is the operational detail worth remembering. If you thought a single command brought you to the latest source, it does not, and a stack left on ods update alone can run old code against new images.

The published tags tell you how fast the surface moves: v2.5.3 shipped on 2026-05-26 with a proxy owner-card readiness note, v2.6.0 on 2026-07-28, and v3.0.0, labelled as the V3 pre-release, on 2026-09-24. The project's own status block states the installers install the current main branch, that this branch receives fixes continuously and is not a signed release, and that v3.0.0 is the latest published source release. It also advises checking the security advisories before pinning a version, which is advice worth taking on a project whose install path runs remote code.

Two interfaces on two ports, and a loaded dashboard proves nothing

After installation Portal opens at http://localhost:3001/pixel. Separately, http://localhost:3000 is Open WebUI, which the docs insist is a different interface. The Windows installer opens Portal for you and prints the exact URL.

The verification advice is unusually blunt: confirm Portal is available and send a message, because a loaded dashboard alone does not prove Pixel is ready. That is a good warning to internalise. A control dashboard in this project manages models, services, setup, GPU status and extensions, so it has plenty of ways to render perfectly while the inference path underneath is unusable.

If Portal is degraded, the route is the Windows Quickstart checks rather than a reinstall. On NVIDIA machines, the README says to update the Windows driver to 570 or newer first.

The network boundary is documented down to each outbound call

The privacy claim is specific rather than absolute. No cloud required, no subscriptions required, inference, chat history and files stay on the machine, and ODS collects no telemetry. By default it goes online for three named reasons: downloading models and container images, checking GitHub for ODS releases, and running the web searches the Portal agent makes on your behalf. A FAQ anchor explains each one and how to turn it off. Cloud and hybrid API modes exist as opt-ins.

Two of those three are worth noticing for what they say about offline use. Model and image downloads are part of the normal path, and the release check means the stack contacts GitHub by default, though the FAQ explains how to turn each of these off.

The voice, agents and workflows feature is where that boundary becomes visible. Automations that listen, speak, call tools and get work done, plus a Portal agent that runs web searches for you, are the parts most likely to cross it.

Five components assembled for you instead of wired by you

The pitch is that you should not have to assemble Ollama, Open WebUI, n8n, ComfyUI and privacy tools by hand. Local model inference runs open models on your own hardware. The ChatGPT-style web UI is the browser front end. The control dashboard handles models, services, setup, GPU status and extensions. Voice, agents and workflows cover the automation side. RAG and search connect local documents, private search and retrieval workflows. Image generation runs local image tools without sending prompts to a hosted API. Privacy and ops keeps service auth, secrets, observability and diagnostics in one local stack.

The repository layout explains how thin the wrapper is. The root holds the README, install.sh, install.ps1, the security policy and CI workflows, plus ARCHITECTURE.md, SECURITY_AUDIT.md and a .gitleaks.toml. Everything that is the product lives under ods/: services, installer phases, compose files, dashboard, CLI, tests and operator docs.

Image generation also has a standalone path. If another device runs your ODS model gateway and the Windows box only needs image generation, a separate ComfyUI installer keeps its own Docker project and data, so it will not collide with a full ODS installation.

What a pre-release with a moving install path will not give you

Three limits are structural rather than temporary.

First, there is no reproducible install. The Linux and macOS path executes a script proxied from main, and the docs state plainly that no release has qualified for the verified channel yet. If your environment needs an audit trail, the answer is the manual path: pick a commit, use ODS_REF, and read the installer trust page first.

Second, the hardware floor is real. Windows needs 40 GB free, hardware virtualization, WSL2, Docker Desktop, Ubuntu 24.04 and a driver at 570 or newer for NVIDIA. Linux and macOS need Docker running before the single command works at all. A host without those cannot be rescued by configuration.

Third, the component set is not chosen by you. Ollama, Open WebUI, n8n and ComfyUI are wired together by the installer. And with the repository's homepage being a Discord invite link rather than documentation, operator docs under ods/docs are the only durable reference.

Editorial conclusion

Pick ODS when you want a working local AI box this week and accept that the installer tracks a branch rather than a signed release. Do not pick it for a machine where unsigned remote code from the main branch, a 40 GB disk floor, a WSL2 detour and mandatory admin prompts are unacceptable, and do not expect a pinned v3.0.0 to behave like a frozen build. Before installing, read the security advisories, inspect the bootstrap script as the installer trust document describes, and confirm your GPU path (NVIDIA driver 570 or newer on Windows, Docker already running on Linux and macOS) actually works on your hardware.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes