Credentials#
To securely provide your API keys, you have four options.
- Browser: Store them in your browser’s local storage.
- Database (Secrets): Save them encrypted in the Phoenix database.
- Database (Custom Providers): Configure named providers with specific credentials.
- Environment Variables: Set them as environment variables on the server.
For built-in providers (e.g., selecting “OpenAI” directly), Phoenix resolves credentials in this order: Browser > Database (Secrets) > Environment Variables. Custom Providers (Option 3) are selected explicitly and use their own configured credentials.
Option 1: Store API Keys in the Browser#
API keys can be entered in the playground application via the API Keys dropdown menu. This option stores API keys in your browser’s local storage.
Option 2: Save Secrets (Encrypted) in the Database#
You can save your API keys persistently in the Phoenix database. Navigate to the Settings page, select the AI Providers tab, and click the edit icon for a provider. In the dialog, toggle the view to Secrets and enter your keys. Keys are stored encrypted at rest in the secrets table. If you change the server’s PHOENIX_SECRET environment variable, these entries will become unreadable and must be updated.
Option 3: Custom Providers#
Custom providers let you store provider credentials and routing settings on the server and reuse them across the playground and prompt versions.
For detailed instructions on configuring custom providers, see the Custom AI Providers settings page.
Using Custom Providers in the Playground and Prompts
Custom providers appear in model selection menus as their own provider group. When you select one:
- The model list mirrors the built-in model list for that SDK.
- Routing fields (base URL, Azure endpoint, AWS region) are pulled from the custom provider config.
- You can still add request-level custom headers from the model configuration panel.
Prompt versions and evaluators use custom providers when a prompt version is saved with a custom provider selection. If you do not select a custom provider for a prompt, Phoenix falls back to environment variables or saved secrets for the built-in provider.
Option 4: Set Environment Variables on Server Side#
If the following variables are set in the server environment, they’ll be used at API invocation time.
| Provider | Environment Variable | Platform Link |
|---|---|---|
| OpenAI | - OPENAI_API_KEY | https://platform.openai.com/ |
| Azure OpenAI | - AZURE_OPENAI_API_KEY - AZURE_OPENAI_ENDPOINT - OPENAI_API_VERSION | https://azure.microsoft.com/en-us/products/ai-services/openai-service/ |
| Anthropic | - ANTHROPIC_API_KEY | https://console.anthropic.com/ |
| Gemini | - GEMINI_API_KEY or GOOGLE_API_KEY | https://aistudio.google.com/ |
| AWS Bedrock | - AWS_ACCESS_KEY_ID - AWS_SECRET_ACCESS_KEY - AWS_SESSION_TOKEN - AWS_BEARER_TOKEN_BEDROCK | https://aws.amazon.com/bedrock/ |
| Cerebras | - CEREBRAS_API_KEY | https://cloud.cerebras.ai/ |
| Fireworks | - FIREWORKS_API_KEY | https://fireworks.ai/ |
| Groq | - GROQ_API_KEY | https://console.groq.com/ |
| Moonshot | - MOONSHOT_API_KEY | https://platform.moonshot.ai/ |
| MiniMax | - MINIMAX_API_KEY | https://platform.minimax.io/docs |
| DeepSeek | - DEEPSEEK_API_KEY | https://platform.deepseek.com/ |
| xAI | - XAI_API_KEY | https://console.x.ai/ |
| Perplexity | - PERPLEXITY_API_KEY | https://www.perplexity.ai/settings/api |
| Together | - TOGETHER_API_KEY | https://api.together.xyz/ |
| Z.ai | - ZAI_API_KEY | https://docs.z.ai/ |
| Meta | - META_API_KEY | https://dev.meta.ai/docs/ |
| Ollama | - OLLAMA_BASE_URL (no API key) | https://ollama.com/ |
The OpenAI-compatible built-in providers (OpenAI, DeepSeek, xAI, Ollama, Cerebras, Fireworks, Groq, Moonshot, MiniMax, Perplexity, Together, Z.ai, and Meta) also read a <PROVIDER>_BASE_URL variable, for example DEEPSEEK_BASE_URL or META_BASE_URL, to point the provider at a different endpoint such as a proxy or a regional API. For Ollama this variable is required, since there is no default endpoint.
For Azure, you can also set the following server-side environment variables: AZURE_TENANT_ID, AZURE_CLIENT_ID, and AZURE_FEDERATED_TOKEN_FILE to use WorkloadIdentityCredential.
AWS Bedrock Authentication
When using AWS Bedrock, Phoenix leverages the standard boto3 credential chain or the AWS_BEARER_TOKEN_BEDROCK environment variable. This means if you are running Phoenix on an EC2 instance with an assigned IAM role, have ~/.aws/credentials configured, or have exported AWS_BEARER_TOKEN_BEDROCK, you do not need to explicitly provide credentials.
To use this fallback behavior, do not fill out the AWS credentials in the Playground settings. The client will automatically discover and use the available credentials from the environment.
Using OpenAI Compatible LLMs#
Option 1: Configure the base URL in the prompt playground#
Since you can configure the base URL for the OpenAI client, you can use the prompt playground with a variety of OpenAI Client compatible LLMs such as Ollama, DeepSeek, and more.\
If you are using an LLM provider, you will have to set the OpenAI api key to that provider’s api key for it to work.
OpenAI Client compatible providers Include
The built-in MiniMax provider uses the global endpoint by default. Set MINIMAX_BASE_URL=https://api.minimaxi.com/v1 to use the China endpoint.
Using the MiniMax Anthropic-compatible API#
To use the Anthropic-compatible API, open Settings, select AI Providers, and create a custom provider with the Anthropic SDK and your MiniMax API key. Set the base URL for the required region, then enter MiniMax-M3 or MiniMax-M2.7 in the model menu.
Use the base URL exactly as shown. The Anthropic SDK appends /v1/messages when Phoenix sends a request.
Option 2: Server side configuration of the OpenAI base URL#
Optionally, the server can be configured with the OPENAI_BASE_URL environment variable to change target any OpenAI compatible REST API.
For a Phoenix instance served over HTTPS, this may fail due to mixed-content restrictions. In that case, you’d see a Connection Error appear.
If there is a LLM endpoint you would like to use, reach out to mailto://phoenix-support@arize.com
OpenAI and Azure OpenAI support two API types: Chat Completions (chat.completions.create) and Responses (responses.create). Both built-in and custom providers now default to the Responses API. For built-in providers, override the API type per model from the model configuration panel in the Playground. For custom providers, set the API type in the provider configuration.
Custom Headers#
Phoenix supports adding custom HTTP headers to requests sent to AI providers. This is useful for additional credentials, routing needs, or cost tracking when using custom LLM proxies.
Configuring Custom Headers#
- Click on the model configuration button in the playground
- Scroll down to the “Custom Headers” section
- Add your headers in JSON format:
Set a Default Provider and Model#
You can choose which provider and model the Prompt Playground selects by default. Go to Settings → AI Providers and use the AI Provider Settings card to pick a default provider and model. The preference is saved in your browser and applied the first time the playground opens in a session, so you don’t have to reselect your usual model each time.
This is distinct from the playground’s “save as default” control in the model configuration panel: the Settings preference chooses the initial provider/model, while “save as default” makes a full model configuration (including invocation parameters) sticky across sessions.