Skip to content

Set up the deploy config without the export

Fill in the spec.deploy.config block of your arena config without the dashboard’s Export deploy profile action. The deploy tutorial covers the export.

  • The editor role in the target workspace.
  • The promptarena CLI and the Omnia adapter (promptarena deploy adapter install omnia).
  • An arena config (arena.yaml unless you pass --config) with spec.deploy.provider: omnia.

Browser login requires the dashboard to run in OAuth mode and API-key creation to be enabled. A dashboard that uses the read-only file key store cannot mint the token.

  1. Set api_endpoint under spec.deploy.config to your dashboard URL.

  2. Run the login:

    Terminal window
    promptarena deploy login --provider omnia

    The CLI opens your browser. If you are not signed in, the browser goes through the dashboard’s OIDC login.

  3. Choose the target workspace on the workspace picker (/cli/select).

The dashboard returns a token and a deploy profile in the adapter’s config shape: api_endpoint, workspace, and each of the workspace’s Ready llm-role Providers as a {name, ref, role} binding, one of them named default. The CLI merges the profile into spec.deploy.config and stores the token in ~/.promptarena/credentials, not in the config file.

The profile carries no skills, because login has no picker. To bind a SkillSource, add a skills entry with a source naming it, as in Set up by hand, or use the dashboard export.

The token is workspace-scoped and short-lived. It expires after one hour by default. Set dashboard.auth.cliTokenTtlSeconds in the Helm values to change that.

See Browser-login autoconfigure for the endpoints behind the flow.

  1. Go to Settings → API keys, create a key restricted to the workspace and copy the omnia_sk_ value. The value is shown once.

  2. Set api_endpoint to your dashboard URL and workspace to the workspace name.

  3. Open the Providers and Skills pages in the dashboard. Fill in providers and skills with the exact names of the Ready resources. The deploy profile offers only llm-role Providers, though the plan accepts any supported role. The binding named default is the agent’s primary provider:

    spec:
    deploy:
    provider: omnia
    config:
    api_endpoint: https://omnia.example.com
    workspace: team-acme
    api_token: omnia_sk_...
    providers:
    - { name: default, ref: claude-sonnet, role: llm }
    skills:
    - { source: policies }

A Provider ref that names no Provider in the workspace comes back from the deploy plan as a provider_not_found diagnostic. See Diagnostic codes.

Plan the bindings against the workspace before you deploy. The plan endpoint is read-only and takes the same deploy.config bindings:

Terminal window
curl -s -X POST https://omnia.example.com/api/workspaces/team-acme/deploy/plan \
-H "Authorization: Bearer omnia_sk_..." \
-H "Content-Type: application/json" \
-d '{"deployConfig": {
"providers": [{"name": "default", "ref": "claude-sonnet", "role": "llm"}],
"skills": [{"source": "policies"}]
}}'

A config that resolves returns "resolved": true on every provider and skill and an empty diagnostics array:

{
"providers": [{ "name": "default", "ref": "claude-sonnet", "role": "llm", "resolved": true }],
"toolRegistry": { "mode": "none", "resolved": true },
"skills": [{ "source": "policies", "resolved": true }],
"diagnostics": []
}

Each diagnostic names the field in path, for example deploy.config.providers[0].ref. The deploy-intent reference describes the response.

If the dashboard uses a read-only API-key store, Export deploy profile still exports the discovery menu. It leaves api_token as a placeholder:

<mint a token in Settings → API keys>

The dashboard cannot create keys in this mode. Provision a key in the Kubernetes Secret that backs the store, as described in Durable API keys, and paste it over the placeholder.