Verda Cloud

Clanker supports Verda Cloud (formerly DataCrunch), a European GPU/AI cloud focused on H100 / H200 / A100 / B200 / L40S / V100 / A6000 instances, Instant Clusters with Slurm or Kubernetes orchestrators, serverless containers and jobs, and managed inference endpoints. All operations run against Verda's REST API directly — the verda CLI binary is optional.

---

Authentication

Verda uses OAuth 2.0 Client Credentials. You need a client_id / client_secret pair (scope cloud-api-v1) plus an optional project_id.

Obtaining credentials

1. Log in to the Verda Cloud Console.
2. Go to Account → API Keys (console.verda.com/account/api-keys).
3. Generate OAuth2 credentials with the cloud-api-v1 scope.
4. Copy the client_id and client_secret — the secret is shown once.

---

Configuration

Clanker resolves Verda credentials in this order:

1. Values in ~/.clanker.yaml under the verda: block
2. VERDA_CLIENT_ID / VERDA_CLIENT_SECRET / VERDA_PROJECT_ID environment variables
3. ~/.verda/credentials (written by verda auth login)
4. Clanker backend credential store (when a backend API key is configured)

Option 1 — ~/.clanker.yaml

verda:
  client_id: ""
  client_secret: ""
  default_project_id: ""
  default_location: "FIN-01"
  default_ssh_key_id: ""
  ssh_key_path: "~/.ssh/id_ed25519"

Option 2 — Environment variables

export VERDA_CLIENT_ID="..."
export VERDA_CLIENT_SECRET="..."
export VERDA_PROJECT_ID="..."      # optional

Option 3 — The Verda CLI

Install the verda binary and let it manage credentials under ~/.verda/credentials:

brew install verda-cloud/tap/verda-cli
verda auth login

Clanker reads the file directly — no extra config needed.

Option 4 — Clanker backend

Store credentials centrally so other machines pick them up automatically:

clanker credentials store verda \
  --client-id "$VERDA_CLIENT_ID" \
  --client-secret "$VERDA_CLIENT_SECRET"

clanker credentials test verda    # hits /v1/balance to confirm they work

---

Prerequisites

The Verda CLI is optional. Clanker talks to the REST API directly, so you only need the binary for:

• verda auth login if you prefer the CLI's credentials file over env vars
• verda skills install to pull agent skills into your editor

If the CLI isn't installed, the clanker verda subcommand still works for every operation — only REST calls are used.

---

Querying Verda

Explicit flag

clanker ask --verda "what GPU instances are running?"
clanker ask --verda "how much am I spending this month?"
clanker ask --verda "show me my instant clusters"

Automatic routing

Questions that mention verda, datacrunch, or Verda-specific terms route automatically:

clanker ask "list my verda clusters"
clanker ask "any datacrunch instances running"

Static commands

clanker verda list instances
clanker verda list clusters
clanker verda list volumes
clanker verda list instance-types
clanker verda list locations
clanker verda list containers         # serverless container deployments
clanker verda list jobs               # serverless job deployments
clanker verda list secrets
clanker verda balance                 # human-readable + raw JSON

clanker verda get instance <uuid|hostname>
clanker verda get cluster <uuid|hostname>
clanker verda action start <uuid|hostname>
clanker verda action shutdown <uuid|hostname>
clanker verda action delete <uuid|hostname>   # destructive, requires confirmation

---

Supported Services

Clanker covers Verda's full primitives surface:

• Instances (GPU / CPU virtual machines)
• Clusters (Instant Clusters with Slurm or Kubernetes orchestrator)
• Volumes (NVMe, HDD, Shared FS / SFS)
• SSH Keys and Startup Scripts
• Container Deployments (serverless containers with autoscaling)
• Job Deployments (serverless batch jobs)
• Secrets and File Secrets (for container deployments)
• Container Registry Credentials
• Images (instance and cluster OS images)
• Locations (datacenters: Finland, Iceland, etc.)
• Balance and Long-term pricing periods

---

Maker Pipeline

Verda plans use a verda-api verb so execution goes through the REST client directly, with no dependency on the verda binary. Placeholder bindings (<INSTANCE_ID>, <SSH_KEY_ID>, etc.) chain commands together.

# Generate a plan
clanker ask --verda --maker "spin up one H100 in FIN-01 with my default ssh key" | tee plan.json

# Apply an approved plan
clanker ask --apply --plan-file plan.json

# Multi-step plans compose via bindings
clanker ask --verda --maker "create an SSH key, then launch an H100 instance using it" | tee plan.json
clanker ask --apply --plan-file plan.json

Destroyer mode

Destructive operations — DELETE, instance action=delete|discontinue|force_shutdown|delete_stuck|hibernate, cluster action=discontinue — are blocked unless --destroyer is passed:

clanker ask --verda --maker --destroyer "delete the test instance" | tee plan.json
clanker ask --apply --plan-file plan.json

Plan shape

Verda plans use REST-native commands rather than shelled-out CLI invocations:

{
  "version": 1,
  "provider": "verda",
  "commands": [
    {
      "args": ["verda-api", "POST", "/v1/instances", "{\"instance_type\":\"1H100.80S.22V\",\"location_code\":\"FIN-01\",\"image\":\"ubuntu-22.04-cuda-12.4-docker\",\"hostname\":\"gpu-1\",\"description\":\"training\",\"ssh_key_ids\":[\"<SSH_KEY_ID>\"]}"],
      "reason": "Create the instance",
      "produces": { "INSTANCE_ID": "$.id" }
    },
    {
      "args": ["verda-api", "PUT", "/v1/instances", "{\"action\":\"start\",\"id\":\"<INSTANCE_ID>\"}"],
      "reason": "Boot it"
    }
  ]
}

---

Kubernetes (Instant Clusters)

Verda doesn't expose a managed Kubernetes control plane API, but its Instant Clusters ship with Kubernetes preinstalled. Clanker registers a verda-instant provider under the K8s agent that:

1. Provisions an Instant Cluster via POST /v1/clusters with a Kubernetes-labelled image.
2. Polls until the cluster reaches running.
3. SSHes to the head node using verda.ssh_key_path and reads /root/.kube/config.
4. Rewrites the server: URL to the public IP so kubectl can reach it from outside Verda's private network.

From the Clanker Cloud desktop app, click the kubeconfig → button on any Verda cluster in the resource list to see a ready-to-paste ssh | sed one-liner.

---

MCP

Verda is exposed over MCP so MCP-compatible agents (Claude Desktop, Cursor, Zed, …) can reach the same surface:

clanker mcp --transport http --listen :39393

Tools:

• clanker_verda_ask — natural-language query answered via the configured AI provider
• clanker_verda_list — list any Verda resource type (instances, clusters, volumes, containers, jobs, secrets, registry-creds, instance-types, locations, balance, images, availability, …)

---

Rate Limits and Retry Behavior

Verda enforces 500 requests/minute per project and 60 requests/minute per method+path. Clanker honours the Retry-After header on 429 responses and retries 5xx responses with capped exponential backoff (250 ms, 750 ms, 2 s). Context cancellation (Ctrl-C) interrupts pending waits.

---

Error Handling

Clanker decodes Verda's {code, message} error body into typed errors. Notable codes you may see in the output:

• insufficient_funds (HTTP 402) — add credit in the console before retrying
• service_unavailable (HTTP 503) — usually means the region/GPU combination is out of capacity; try another location
• rate_limit_exceeded (HTTP 429) — Clanker retries automatically; if you see this, it exhausted the attempt budget
• unauthorized_request (HTTP 401) — credentials expired or scope mismatched; check cloud-api-v1 scope and refresh via verda auth login