Quick start

How do you go from no Stado state to one completed job? This page is the one happy path: install an exact release, create the minimal local configuration, start the local control plane, submit one job, and read its result. Local mode needs no cloud account, provider CLI, GPU, or Wisent production credential. Everything else — the other enrollment methods, failure guidance, attaching more machines — lives in onboarding, add-your-machine, and jobs.

Install an exact release

install-stado.sh at the repository root installs stado from one exact signed release; it never resolves a mutable release. Set the release identity, run it, and expose its binary directory:

export STADO_API_URL=<your-control-origin>
export STADO_RELEASE_VERSION=<exact-version>
./install-stado.sh
export PATH="$HOME/.stado/bin:$PATH"

The script requires an HTTPS STADO_API_URL, reads the platform from the machine (darwin-arm64 or linux-amd64), fetches the signed release's release.json and release.tar.gz from /api/release/object, checks the manifest's product, version, platform and source revision and the archive's size and SHA-256 against it, and installs the archive's one stado member. The binary lands in $HOME/.stado/bin (override with STADO_BIN_DIR), and the last two lines it prints are the platform and the installed path. stado bootstrap runs this same file on a remote host.

Create the minimal configuration

STADO_CONFIG selects the operator-owned deployment profile; without it, Stado uses ~/.stado/config.json, which the next command creates:

stado config init
stado config validate

config init prints the path to the new file and creates only a schema-versioned local queue profile: local compute, local primary and backup stores, one deployment identity, and a loopback dashboard — no Wisent service routes, cloud locators, or credentials. It never overwrites an existing file. config validate prints config ok (<path>). The keys themselves are documented in configuration.

Start the local control plane

stado serve --standalone --worker --kind local --poll-seconds 15 \
  --control-plane local --control-plane-interval-seconds 15 \
  --api --bind 127.0.0.1 --port 8765

One process runs the scheduler, the worker and the API listener and stays in the foreground. --standalone says this machine belongs to no fleet registry; the poll, the scheduling period and the port are yours to state.

Submit one job

From another terminal using the same config:

stado submit --run-id hello-from-stado "printf 'hello from Stado\n'"

submit puts the job on the queue and prints a Job ID. Use that ID below. --run-id is required: it is your own name for this run, and submitting the same run id with the same request again answers the job already queued instead of adding a second one.

Watch it run

stado status <job-id>

status shows the job's state; it progresses from queued or running to completed. The argument filters by job id (8 hex chars) or batch id substring.

Read the result

stado results <job-id> ./stado-result

results downloads the job's output into the named directory. The command output contains hello from Stado, and the result manifest records the artifact size and SHA-256. A failed job remains inspectable and may still publish logs and partial artifacts.

That is the whole path. To onboard more machines or operate a real fleet, continue with onboarding; to attach your own computer to a fleet someone else runs, read add-your-machine; for the full job contract — constraints, artifacts, secrets, verification — read jobs.