# Provider Onboarding v1

This is the simplest provider flow that feels logical to a new operator and
matches the current worker runtime.

## Public flow

1. Register as a provider on the website.
2. Copy the returned `providerId` and `INSTAI_PROVIDER_API_KEY`.
3. Download the installer from Resonara.
4. Run the installer so it fetches the provider worker bundle.
5. Choose a node backend setup.
6. Run the local setup script. It should auto-detect the local backend and
   hardware, so operators should normally only need to provide the provider ID
   and API key.
7. Restart the worker container.
8. Open the provider dashboard and verify the node is online.

## What the website should show after signup

- provider ID
- provider API key
- gateway URL
- installer download:
  `curl -fsSLo install-provider-node.sh https://resonara.one/downloads/provider/install-provider-node.sh`
- installer run:
  `bash install-provider-node.sh`
- setup command:
  `INSTAI_PROVIDER_ID=prov_ops INSTAI_PROVIDER_API_KEY=... bash infra/docker/setup-provider-node.sh`
- restart command:
  `bash infra/docker/deploy-provider-worker.sh restart`
- status command:
  `bash infra/docker/deploy-provider-worker.sh status`
- direct downloads for advanced operators:
  - `/downloads/provider/provider-worker.compose.yaml`
  - `/downloads/provider/setup-provider-node.sh`
  - `/downloads/provider/deploy-provider-worker.sh`
  - `/downloads/provider/guide.md`

The website should not ask the provider for public capacity controls such as
`maxWorkers`. That stays an internal trust and operations setting.

## Backend lanes

### Ollama lane

This is the supported public lane today.

Suggested operator sequence:

1. install Docker on the node
2. download the provider installer from Resonara
3. run `bash install-provider-node.sh`
4. start the local Ollama setup for that machine
5. run `bash infra/docker/setup-provider-node.sh`
6. run `bash infra/docker/deploy-provider-worker.sh restart`
7. check `docker logs -f instai-worker`

Example for an AMD Vega 56 host running Ollama in Docker:

```bash
docker run -d \
 --name ollama \
 --restart always \
 --device /dev/kfd \
 --device /dev/dri \
 -v ollama:/root/.ollama \
 -p 11436:11436 \
 -e HSA_OVERRIDE_GFX_VERSION=9.0.0 \
 ollama/ollama:0.1.27-rocm
```

Quick smoke tests after the container is up:

```bash
docker exec -it ollama ollama run llama3
docker exec -it ollama ollama run qwen2.5-coder:7b
```

If you use this exact container shape, point the provider worker at
`http://127.0.0.1:11436` instead of the default `11434`.

Why this is the default:

- it matches the current worker adapter
- it is easy to support remotely
- it keeps onboarding short

### vLLM lane

This is the intended next lane for larger or more specialized hosts such as
multi-GPU providers.

Recommended product stance for now:

- keep vLLM visible as a planned or advanced lane
- do not make it the default public onboarding flow yet
- add it once the worker has a dedicated vLLM adapter and health/bootstrap path

That keeps the provider journey simple while still leaving room for larger
machines like the `7x CMP90hx 10GB` host to get a better-tailored deployment.

## What `setup-provider-node.sh` should handle

- default to the public live gateway unless explicitly overridden
- ask for `providerId` only if it was not passed through env
- ask for `INSTAI_PROVIDER_API_KEY` only if it was not passed through env
- auto-detect local backend lane when possible (`ollama` first, then `vllm`)
- suggest `nodeId` and `workerId` automatically from the hostname
- auto-detect local backend URL and basic hardware values when possible
- write bundle-root `.env`
- write an optional generated worker JSON config for reference

The operator should not have to hand-edit multiple files before first start.