Skip to main content
The keys.yaml file is the central vault for Open Next Router. It manages both the pool of API keys you hold with upstream LLM providers, and the access tokens you issue to your clients.

​
Upstream Provider Keys

These are the credentials you use to authenticate with external services like OpenAI or Anthropic. ONR groups credentials by provider, allowing it to load-balance across multiple keys automatically within a single provider namespace. 
providers:
  openai:
    keys:
      - name: "key-billing-a"
        value: "sk-proj-prod..."
        # (Optional) You can redirect a specific proxy key to an alternate base url
        # base_url_override: "https://my-openai-azure-proxy.com"
        
  anthropic:
    keys:
      - name: "haiku-cluster"
        value: "sk-ant-... "
To avoid committing sensitive keys to version control, providing an empty value allows environment variables to fulfill them. ONR automatically maps keys.yaml entries to environment variables.
  • Using a named key: ONR_UPSTREAM_KEY_<PROVIDER>_<NAME>
  • E.g., ONR_UPSTREAM_KEY_ANTHROPIC_HAIKU_CLUSTER=sk-ant-1234 onr run -c onr.yaml

​
Encrypted Upstream Keys

To store credentials directly in GitHub without exposing them, you can employ built-in AES-256-GCM encryption. You can encrypt an API key using the ONR Admin CLI: 
echo -n 'sk-xxxx' | onr-admin crypto encrypt
This will produce a ciphertext like ENC[v1:aesgcm:<base64(nonce+ciphertext)>]. Simply paste this string into keys.yaml. At runtime, start the server with your symmetrical unlock key: ONR_MASTER_KEY=your-32-byte-secret onr run -c onr.yaml

​
Downstream Access Keys (Client ACL)

To control access to your ONR proxy, you issue Access Keys to your downstream clients. 
access_keys:
  - name: "client-a"
    value: "ak-onr-client-001"
    comment: "Internal Analytics Dashboard"
A client provides this access token when calling ONR: Authorization: Bearer ak-onr-client-001
  • Using a named key: ONR_ACCESS_KEY_<NAME>
  • E.g., ONR_ACCESS_KEY_CLIENT_A=ak-onr-client-001