DEPLOYMENT¶

Hosting environments and provisioning for RUNE.

Mode 1: CLI-Only (Standalone)¶

The CLI runs every workflow in-process. No server or database required.

cd ~/Devel/rune
. .venv/bin/activate

export RUNE_BACKEND=local
export RUNE_OLLAMA_URL=http://localhost:11434

# Verify CLI is functional
python -m rune --help

# Run a benchmark
python -m rune run-benchmark \
  --model llama3.1:8b \
  --question "Why is the cluster unhealthy?"

When to use: Quick iteration, unit testing, local debugging.

Mode 2: Docker Compose (Development)¶

A self-contained stack with API, UI, docs, Ollama, and SeaweedFS (S3). Defined in ~/Devel/rune/docker-compose.yml.

cd ~/Devel/rune

# Build and start the full stack
docker compose up -d --build

# Verify services
curl -s http://localhost:8080/healthz   # rune-api
curl -s http://localhost:3000/healthz   # rune-ui

# View logs
docker compose logs -f rune-api

Services and Ports¶

Service	Port	Description
`rune-api`	8080	Core API server
`rune-ui`	3000	HTMX frontend
`rune-docs`	8000	Documentation site
`ollama`	11434	LLM inference server
`seaweedfs`	8333	S3-compatible object storage

Teardown¶

docker compose down -v   # -v removes volumes (clean state)

When to use: End-to-end testing, UI development, integration testing without Kubernetes.

Mode 3: Kubernetes via Kind (Testing)¶

A local Kubernetes cluster using Kind, deployed with Helm charts from ~/Devel/rune-charts/.

cd ~/Devel/rune-charts

# Create cluster
kind create cluster --name rune-test

# Deploy
kubectl create namespace rune-test
helm install rune ./charts/rune --namespace rune-test --wait --timeout=2m
helm install rune-operator ./charts/rune-operator --namespace rune-test --wait --timeout=2m

# Verify
kubectl -n rune-test get pods

# Port-forward for local access
kubectl -n rune-test port-forward svc/rune-api 8080:8080 &
curl -s http://localhost:8080/healthz

# Clean up
kind delete cluster --name rune-test

When to use: Testing Helm charts, operator behavior, CRD validation, Kubernetes-specific features.

Mode 4: Kubernetes (Production)¶

The API server runs as a Kubernetes Deployment via the rune Helm chart. Tokens passed via Helm are securely hashed (SHA-256) by the application before being stored in memory.

helm install rune ./charts/rune \
  --set rune.api.authDisabled=false \
  --set rune.api.tokens="myteam:mytoken" \
  --set rune.s3.enabled=true

Components¶

rune-api: Python API server handling jobs.
SQLite: Persistent volume for job storage.
S3 Sink: Results pushed to S3/SeaweedFS.
rune-operator: Cron-based job scheduling via Custom Resources.
Vault: Optional secret injection via Vault Agent.

Infrastructure Dependencies¶

Dependency	Required for	Notes
Ollama	All modes	Inference server (local or provisioned)
Vast.ai	GPU provisioning	Cloud GPU rental; requires `VAST_API_KEY`
Kubernetes	Modes 3 and 4	Target cluster for operator and HolmesGPT
S3-Compatible Storage	Result persistence	SeaweedFS (compose) or any S3 endpoint
Kind	Mode 3	Local Kubernetes for testing
Helm	Modes 3 and 4	Chart-based deployment