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.
Prerequisites
Section titled “Prerequisites”- The
editorrole in the target workspace. - The
promptarenaCLI and the Omnia adapter (promptarena deploy adapter install omnia). - An arena config (
arena.yamlunless you pass--config) withspec.deploy.provider: omnia.
Sign in from the CLI
Section titled “Sign in from the CLI”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.
-
Set
api_endpointunderspec.deploy.configto your dashboard URL. -
Run the login:
Terminal window promptarena deploy login --provider omniaThe CLI opens your browser. If you are not signed in, the browser goes through the dashboard’s OIDC login.
-
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.
Set up by hand
Section titled “Set up by hand”-
Go to Settings → API keys, create a key restricted to the workspace and copy the
omnia_sk_value. The value is shown once. -
Set
api_endpointto your dashboard URL andworkspaceto the workspace name. -
Open the Providers and Skills pages in the dashboard. Fill in
providersandskillswith the exact names of the Ready resources. The deploy profile offers onlyllm-role Providers, though the plan accepts any supported role. The binding nameddefaultis the agent’s primary provider:spec:deploy:provider: omniaconfig:api_endpoint: https://omnia.example.comworkspace: team-acmeapi_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.
Verify
Section titled “Verify”Plan the bindings against the workspace before you deploy. The plan endpoint
is read-only and takes the same deploy.config bindings:
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.
Use a read-only key store
Section titled “Use a read-only key store”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.