How to Fix 'authentication failed in production' in LlamaIndex (TypeScript)

By Cyprian AaronsUpdated 2026-04-21
authentication-failed-in-productionllamaindextypescript

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 patternFixed pattern
Uses env var implicitly and assumes it existsValidates env var before creating clients
Fails later inside ServiceContext / Settings / query callFails fast at startup with a clear error
Hard to debug in production logsEasy 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.local exists 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

  1. 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,
    });
    
  2. 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 OpenAI but see something else, your app wiring is wrong.

  3. 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);
    
  4. 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

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

Related Guides