Restormel Keys

Testing uses Keys for logical model resolution and BYOK-aligned execution when you run judge-backed goals. Deterministic browser goals (URL + DOM) do not call Keys.

CI reality check: Many first suites are fully deterministic (e.g. URL + data-testid). Those runs need no RESTORMEL_KEYS_* in GitHub Actions. Add Keys when you introduce judge_rubric or other resolution that hits the Keys HTTP API. See Keys in CI (checklist).

Hosted credentials (optional): In the Keys dashboard you can store encrypted provider keys under Connections and use Restormel Testing (/keys/dashboard/testing) for RESTORMEL_PROJECT_ID and environment IDs. End-to-end guide: Keys + Testing onboarding (repo: docs/keys-testing-onboarding.md).

MVP integration points:

  • Resolve a primary (and optionally vision) model through Keys for judge_rubric steps.
  • Store opaque references (ref:restormel-keys:…) in Testing config; keep raw provider secrets out of YAML — in CI use secrets, or use hosted encrypted keys in Keys plus Gateway auth for resolve.
  • Do not bypass Keys by default; avoid building a second credential-management system.

Process env read by the Testing CLI (values are never printed; see repo .env.example and docs/testing/config-reference-mvp.md):

  • RESTORMEL_KEYS_API_BASE_URL — Keys API origin.
  • RESTORMEL_KEYS_API_TOKEN — Gateway key bearer (or set RESTORMEL_KEYS_API_TOKEN_ENV to another var name).
  • RESTORMEL_PROJECT_ID — project UUID (Restormel Testing hub in the Keys dashboard).
  • RESTORMEL_TESTING_OPENAI_FALLBACK=1 — opt-in use of OPENAI_API_KEY when Keys is unset or resolution fails.

Canonical docs: Restormel Keys documentation (environment vocabulary, resolve flow, dashboard workflows).

Local context: How it fits together · Configuration · Keys + Testing (from Testing docs)