Providers Overview

Aurora supports 14 provider types out of the box. Providers are auto-discovered from environment variables: set the env var, restart Aurora, and the provider and its default model list appear at /v1/models. You can also register providers dynamically through the admin API or define them in config.yaml.

Provider matrix

Multiple instances of the same provider

Underscores in the env var name become hyphens in the provider name. This is how you run parallel providers for regional, quota, or failover reasons:

OPENAI_EAST_API_KEY=sk-...
OPENAI_WEST_API_KEY=sk-...
ANTHROPIC_PROD_API_KEY=sk-ant-...
ANTHROPIC_STAGING_API_KEY=sk-ant-...

You now have providers openai-east, openai-west, anthropic-prod, anthropic-staging. Use them in aliases, pools, and workflows.

Custom base URLs

For corporate proxies, regional endpoints, or self-hosted gateways that look like an OpenAI-compatible API, override the base URL:

OPENAI_BASE_URL=https://my-corp-openai-proxy.example.com/v1
ANTHROPIC_BASE_URL=https://anthropic-proxy.example.com/v1

Any provider that does not require a base URL accepts one anyway — use this to redirect traffic without changing your code.

Configured model lists

By default Aurora uses upstream discovery. To force a specific list:

OPENAI_MODELS=gpt-4o,gpt-4o-mini,o3-mini
GROQ_MODELS=llama-3.3-70b-versatile,llama-3.1-8b-instant

CONFIGURED_PROVIDER_MODELS_MODE controls the behavior:

• fallback (default) — use the configured list only when upstream /models is unavailable.
• allowlist — expose only the configured list, never the auto-discovered models.

See Model Management.

Provider-specific extras

A few providers need extra fields beyond the API key:

• Azure — AZURE_API_VERSION (e.g. 2024-10-21) is required; deployment names are configured per deployment.
• OpenRouter — OPENROUTER_SITE_URL and OPENROUTER_APP_NAME are optional but recommended for ranking.
• Ollama — OLLAMA_BASE_URL is the only required setting; no key is needed unless you set one on your Ollama server.
• vLLM — same as Ollama; point VLLM_BASE_URL at your python -m vllm.entrypoints.openai.api_server instance.
• Oracle — OCI GenAI requires a base URL, an API key, and a compartment OCID embedded in the request.
• Jina — Jina is not a first-class provider type in Aurora. You reach it through the OpenAI-compatible provider by setting OPENAI_BASE_URL=https://api.jina.ai and your Jina key in OPENAI_API_KEY. Aurora detects the jina.ai host and strips the jina-ai/ namespace from model IDs before the upstream call. See the Jina guide for the full activation pattern.

See each provider's dedicated guide for the full configuration and gotchas.

Provider passthrough

Beyond translating to OpenAI/Anthropic format, Aurora forwards native upstream APIs at /p/{provider}/*. This is useful for endpoints Aurora does not implement — images, audio, fine-tunes, batch management. Enable with ENABLE_PASSTHROUGH_ROUTES=true (default) and restrict the allow-list with ENABLED_PASSTHROUGH_PROVIDERS. See Passthrough API and API: Passthrough.

Verifying a provider is healthy

After starting Aurora, the dashboard Providers page shows a per-provider health badge and an error count. The admin API exposes the same data:

curl -s http://localhost:8080/admin/api/v1/providers/status \
  -H "Authorization: Bearer $AURORA_MASTER_KEY" | jq .

A provider that is configured but not showing models usually means the API key is wrong, the base URL is wrong, or the upstream is unreachable from the Aurora host.

What if a provider is missing?

Two options:

1. Use a generic OpenAI-compatible provider — set OPENAI_BASE_URL and OPENAI_API_KEY to the upstream's endpoint. Most third-party gateways expose an OpenAI-shaped API.
2. Register the provider dynamically via POST /admin/api/v1/providers with type: "openai", a custom name, base URL, and API key.