Running locally

Install

On macOS and Linux:

curl -fsSL https://veox.ai/install.sh | bash

On Windows, in PowerShell:

irm https://veox.ai/install.ps1 | iex

The two are the same program in two shells: same download root, same channel manifest, same digest-then-signature policy, same container name and port, same refusal to start an image whose loaded id is not the one the release names.

If you would rather run the Docker steps yourself, the release names its own version and the channel is where to read it:

# VERSION, and the tar's digest, come from here
curl -fsSL https://downloads.neverhuman.org/jain/latest.json

curl -fsSLO https://downloads.neverhuman.org/jain/$VERSION/jain-cpu-$VERSION.tar.gz
curl -fsSLO https://downloads.neverhuman.org/jain/$VERSION/jain-cpu-$VERSION.tar.gz.sha256
sha256sum -c jain-cpu-$VERSION.tar.gz.sha256

docker load -i jain-cpu-$VERSION.tar.gz
docker rm -f ai-veox-jain
docker run -d --name ai-veox-jain --restart unless-stopped \
  -p 127.0.0.1:8369:8080 jain/workspace:$VERSION

No page here names a version, and that is deliberate: a number printed in documentation can only ever be a claim about the past. latest.json is the release saying what it is, and the digest check is what the two installers do for you.

The installer checks Docker is present and its daemon reachable, verifies the download against the release manifest, verifies the signature if you have cosign, loads the image and starts it. It refuses to install anything whose digest does not match.

If Docker is not reachable

The installer checks Docker before it downloads anything, and stops there rather than leaving you a half-installed workspace. What it means depends on where you are running it.

WSL, on Windows

This is the common one, and it does not mean Docker is missing. Docker Desktop runs the engine on the Windows side, and a WSL distro can only reach it once WSL integration is switched on for that distro. Until it is, the docker your shell finds is Docker Desktop's Windows shim, inherited through the Windows PATH — it resolves, so it looks installed, and every call fails. The tell:

command -v docker
# /mnt/c/Program Files/Docker/Docker/resources/bin/docker  ->  integration is off
# /usr/bin/docker                                          ->  integration is on

Switch it on in Docker Desktop → Settings → Resources → WSL Integration, enable your distro, and Apply & Restart. Then open a new shell — or run wsl --shutdown in PowerShell and reopen — and run the installer again.

Two things not to do on the way. You do not need the docker group: in integration mode the socket is proxied in from Docker Desktop and usermod -aG docker answers group 'docker' does not exist, which is correct and not the problem. And do not install Docker Engine inside the distro alongside Desktop — that is a second engine, not a fix. If your distro is not offered in the integration list, wsl -l -v in PowerShell will show it still on version 1; wsl --set-version <name> 2 moves it.

Linux

Either the daemon is not running or your user cannot reach its socket:

sudo systemctl start docker
sudo usermod -aG docker "$USER"   # then log out and back in

macOS and Windows

Start Docker Desktop and let the whale icon stop animating before running the installer again. On a first install it can take a minute to come up.

Open it

It comes up on http://localhost:8369 — a port of our own rather than 8080, which is the most contended port on a developer machine. Sign in with the same account you use in the browser.

Everything after that is the workspace you already know: upload a table, choose the column to predict, watch the search, take the model and the report.

What binding to localhost means

The workspace binds to 127.0.0.1, so only your machine can reach it. That is deliberate: the container holds a live session for whoever can reach it, so exposing it to the network is a decision you make on purpose with --bind, not one the image makes for you.

It is also why a notebook can drive it. Anything on your machine that can make an HTTP request can run a session — see Drive it from Python.

Managing it

# follow the log
docker logs -f ai-veox-jain

# stop it, or remove it and its image and cache
curl -fsSL https://veox.ai/install.sh | bash -s -- --stop
curl -fsSL https://veox.ai/install.sh | bash -s -- --uninstall

Limits are the service's, not the container's

What your account may do is enforced by the service on every request, not by the copy of the workspace on your machine. There is nothing in the image to patch — it holds no model, no engine and no entitlement of its own.