How to Fix 'authentication failed in production' in LlamaIndex (TypeScript)
What this error usually means
If you see authentication failed in production while using LlamaIndex in TypeScript, the SDK is telling you the upstream provider rejected your credentials. In practice, this usually shows up when your OpenAI, Anthropic, Azure OpenAI, or other LLM key is missing, malformed, loaded from the wrong environment, or not valid for the model you’re calling.
The failure often appears only after deployment because local .env values work, but your production runtime does not have the same environment variables or secret manager wiring.
The Most Common Cause
The #1 cause is simple: your provider key is not available at runtime in production, even though it works locally.
With LlamaIndex TS, this usually happens when you instantiate OpenAI or OpenAIEmbedding without verifying that process.env.OPENAI_API_KEY exists in the deployed environment.
Broken vs fixed
| Broken pattern | Fixed pattern |
|---|---|
| Uses env var implicitly and assumes it exists | Validates env var before creating clients |
Fails later inside ServiceContext / Settings / query call | Fails fast at startup with a clear error |
| Hard to debug in production logs | Easy to trace to missing secret |
// broken.ts
import { OpenAI } from "@llamaindex/openai";
import { Settings } from "llamaindex";
Settings.llm = new OpenAI({
model: "gpt-4o-mini",
apiKey: process.env.OPENAI_API_KEY,
});
const response = await Settings.llm.complete("Hello");
console.log(response);
// fixed.ts
import { OpenAI } from "@llamaindex/openai";
import { Settings } from "llamaindex";
const apiKey = process.env.OPENAI_API_KEY;
if (!apiKey) {
throw new Error("Missing OPENAI_API_KEY in production environment");
}
Settings.llm = new OpenAI({
model: "gpt-4o-mini",
apiKey,
});
const response = await Settings.llm.complete("Hello");
console.log(response);
In real deployments, the error often surfaces as something like:
- •
AuthenticationError: Incorrect API key provided - •
401 Unauthorized - •
Error: 401 Invalid Authentication - •
OpenAI API error: authentication failed
If you’re using a hosted platform, check whether the secret was added to the correct environment:
- •Vercel Preview vs Production
- •Docker container env vs local shell env
- •Kubernetes Secret mounted into the right namespace
- •AWS Lambda environment variables
Other Possible Causes
1. Wrong provider key for the client you instantiated
A very common mistake is passing an OpenAI key into an Anthropic client or vice versa.
// wrong
import { Anthropic } from "@llamaindex/anthropic";
const llm = new Anthropic({
model: "claude-3-5-sonnet",
apiKey: process.env.OPENAI_API_KEY,
});
// right
import { Anthropic } from "@llamaindex/anthropic";
const llm = new Anthropic({
model: "claude-3-5-sonnet",
apiKey: process.env.ANTHROPIC_API_KEY,
});
2. Azure OpenAI config is incomplete
Azure OpenAI needs more than just a key. You need endpoint, deployment name, and API version configured correctly.
import { AzureOpenAI } from "@llamaindex/openai";
const llm = new AzureOpenAI({
apiKey: process.env.AZURE_OPENAI_API_KEY!,
endpoint: process.env.AZURE_OPENAI_ENDPOINT!,
deploymentName: "gpt-4o-prod",
apiVersion: "2024-06-01",
});
If any of these are wrong, you’ll often get a generic authentication-style failure even though the real issue is configuration mismatch.
3. Environment variable is present locally but not in the production runtime
This happens a lot with Next.js, serverless functions, and Docker images built without runtime secrets.
// This can work locally and fail in prod if env isn't injected there.
console.log(process.env.OPENAI_API_KEY);
Check these cases:
- •
.env.localexists locally but never made it into CI/CD - •Docker image was built with build-time env only
- •Next.js client code tries to access a server-only secret
- •Secret manager is attached to staging but not production
For Next.js specifically:
- •Server code can read
process.env.OPENAI_API_KEY - •Browser code cannot use private keys
- •Anything prefixed with
NEXT_PUBLIC_is exposed to clients and should not be used for LLM credentials
4. Key restrictions or account policy blocks
Some providers restrict keys by IP, referrer, project, or organization. A valid-looking key can still fail in production if traffic comes from an unapproved network.
Example symptoms:
- •Works on your laptop
- •Fails only on cloud-hosted infra
- •Error looks like auth failure but root cause is policy enforcement
Typical fix:
- •Regenerate the key under the correct project/org
- •Remove IP restrictions temporarily to confirm diagnosis
- •Check provider dashboard for blocked requests
How to Debug It
- •
Log which provider client is actually being created
Don’t guess. Print the resolved config at startup without leaking secrets.
console.log({ hasOpenAIKey: Boolean(process.env.OPENAI_API_KEY), hasAnthropicKey: Boolean(process.env.ANTHROPIC_API_KEY), nodeEnv: process.env.NODE_ENV, }); - •
Confirm the request reaches the expected provider
If you’re using LlamaIndex’s
Settings, make sure you didn’t override it elsewhere in app startup.import { Settings } from "llamaindex"; console.log(Settings.llm?.constructor?.name);If you expected
OpenAIbut see something else, your app wiring is wrong. - •
Test the raw provider call outside LlamaIndex
Strip LlamaIndex out of the equation. If raw SDK auth fails too, the problem is not LlamaIndex.
import OpenAI from "openai"; const client = new OpenAI({ apiKey: process.env.OPENAI_API_KEY }); const res = await client.responses.create({ model: "gpt-4o-mini", input: "ping", }); console.log(res); - •
Check deployment secrets and runtime scope
Verify where the code runs:
- •server action
- •API route
- •worker queue consumer
- •edge function
Then confirm that environment variables are available in that exact runtime. A secret present during build time does not guarantee it exists at request time.
Prevention
- •
Validate required secrets at process startup and fail fast with explicit errors.
const required = ["OPENAI_API_KEY"]; for (const name of required) { if (!process.env[name]) throw new Error(`Missing ${name}`); } - •
Keep provider config centralized.
Don’t scatter
new OpenAI(...)across handlers and jobs. Create one config module and import it everywhere. - •
Add a smoke test in CI/CD that calls each provider once with production-like env vars.
Catch auth failures before traffic hits your app.
Keep learning
- •The complete AI Agents Roadmap — my full 8-step breakdown
- •Free: The AI Agent Starter Kit — PDF checklist + starter code
- •Work with me — I build AI for banks and insurance companies
By Cyprian Aarons, AI Consultant at Topiax.
Want the complete 8-step roadmap?
Grab the free AI Agent Starter Kit — architecture templates, compliance checklists, and a 7-email deep-dive course.
Get the Starter Kit