Install
oshal runs on one machine with Docker — cockpit, database, mesh, vector store and the bot fleet — and the installer refuses to tell you it worked until it has verified that it did. No cloud account, no API key to begin with, nothing to compile.
Before you start
docker command, docker compose version, and a running daemon, and stops if any is missing. On Windows it can install Docker Desktop for you through winget.
Three ways in
Downloads the installer and runs it. It asks you three things (which mode, which bundle of apps, and an email for the first account), then does the rest.
curl -fsSLO https://raw.githubusercontent.com/emeraldcoastsystemsgroup/oshal/main/scripts/oshal-install.sh
bash oshal-install.sh
For a machine with no terminal. Download the launcher and double-click it; it fetches the PowerShell installer and runs the same flow, asking only for an email. Windows SmartScreen will warn that the file is unsigned — choose More info → Run anyway.
Install-OSHAL.bat
A prebuilt archive carries the images so the install needs no registry and no network. Both installers detect an archive sitting next to them, or you can point at one explicitly. The archive is several gigabytes and is self-hosted rather than attached to a GitHub release.
bash oshal-install.sh --from-archive ./oshal-images.tar
What it does
Worth reading once, because it explains why an oshal install either works or tells you exactly which capability is missing — rather than leaving you with running containers and a blank page.
Docker present, Compose v2 present, daemon actually running. Each is a hard stop with a named reason rather than a failure three minutes into a pull.
.env with fresh random secretsDatabase password, session secret, service secret, remote-client secret — generated per install from the system random source. If a .env already exists it keeps yours and says so. This file is the one thing a fresh clone cannot start without.
Bundles resolve their dependencies and deduplicate, so choosing full and choosing a themed bundle never stage the same package twice.
Infrastructure first and waits for healthy; then the controller, waiting for it to be genuinely up rather than merely answering; then the bot fleet in small batches with a settle between them. Ordering is the difference between a stack that comes up and one that half-starts.
A postflight check asks the readiness endpoint for its named legs — model access, bots, credentials, catalogs, voice in and voice out, database — and reports which one is not ready. A green container count is explicitly not treated as success. If the verifier itself cannot be fetched, the installer says the install is unverified rather than claiming success.
At http://localhost:35457/welcome. That is the first-run path — the cockpit itself lives at /cockpit/ once you are through it.
After it finishes
35457OSHAL_API_PORT.55433 / 55434127.0.0.1 only.5638058001585298444If something is wrong
docker compose up on a fresh clone will not startDeliberately. There is no session secret and no default identity mode in a clean checkout, and the controller refuses to boot rather than come up insecure. Run the installer, or write a .env first — that single file is the gap between a clone and a running box.
127.0.0.1 but not localhostA stale Windows relay process squatting on the IPv6 loopback. Restarting Docker Desktop does not clear it; killing that process does. The repo carries a runbook for it.
Bring the stack up with the ordered script rather than a bare compose command. After an engine restart containers auto-start in the wrong order, and the controller can come up without its database while still passing a shallow health check.
The kernel bundle runs the platform without the full bot fleet. You can install app packages onto it afterwards one at a time.
Next
54 applications are installable from the catalog, and adding your own takes a conversation rather than a codebase.