How to Fix Railway API Key Exposure (2026)

A Railway app with a leaked OpenAI key can burn through your API credits within hours. The most common cause is a variable prefixed with VITE_ or NEXT_PUBLIC_: those prefixes tell the build tool to embed the value directly into your client JavaScript, where anyone who opens DevTools can read it.

This guide walks through finding the leak, rotating the key, scrubbing git history if needed, and fixing the root cause so it does not happen again.

Step 1: Find the Exposed Key

Before rotating, confirm exactly what is exposed and how.

# Find any secret-looking variables with public-facing prefixes
grep -r "VITE_" . --include="*.env*" --include="*.ts" --include="*.tsx" --include="*.js"
grep -r "NEXT_PUBLIC_" . --include="*.env*" --include="*.ts" --include="*.tsx"

git log --all --full-history -- .env
git log --all --full-history -- .env.local
git log --all --full-history -- .env.production

Step 2: Rotate the Exposed Key Immediately

Do not try to fix the root cause first. The key is already exposed. Rotate it now.

Step 3: Remove from Git History (if committed)

If your audit found a .env file in git history, you need to scrub it. The key is still visible in any clone of the repo even if you deleted the file in a later commit.

# Install git-filter-repo (preferred over filter-branch)
pip install git-filter-repo

# Remove .env from all history
git filter-repo --path .env --invert-paths
git filter-repo --path .env.local --invert-paths

After scrubbing, push with force to all remotes and notify any collaborators to re-clone. If the repo was public at any point, assume the key was copied and rotate regardless.

Also add .env to your .gitignore if it is not already there:

echo ".env" >> .gitignore
echo ".env.local" >> .gitignore
echo ".env.*.local" >> .gitignore
git add .gitignore
git commit -m "chore: ensure .env files are gitignored"

Step 4: Fix the Root Cause

Rotating is not enough if the underlying pattern sends the key to the client on every build.

The VITE_ and NEXT_PUBLIC_ Problem

Vite embeds every variable prefixed VITE_ into the client bundle at build time. Next.js does the same for NEXT_PUBLIC_. This is by design: these prefixes exist to make values available in browser code.

The fix is to remove the prefix and access the variable only from server-side code.

Wrong (key ends up in browser bundle):

// vite app: this sends OPENAI_API_KEY to every visitor's browser
const client = new OpenAI({ apiKey: import.meta.env.VITE_OPENAI_API_KEY });

Right (key stays server-side via an API route):

// server/api/chat.post.ts (Nuxt) or pages/api/chat.ts (Next.js)
// OPENAI_API_KEY is accessed here, server only, never in the browser bundle
const client = new OpenAI({ apiKey: process.env.OPENAI_API_KEY });

export default defineEventHandler(async (event) => {
  const body = await readBody(event);
  const response = await client.chat.completions.create({
    model: "gpt-4o",
    messages: [{ role: "user", content: body.message }],
  });
  return response.choices[0].message.content;
});

The client code calls /api/chat on your own domain. Your server calls OpenAI. The key never leaves your server.

Railway Variable Naming

In Railway's Variables tab, name your secret without any public prefix:

Then update your server-side code to use process.env.OPENAI_API_KEY. Railway injects it into the runtime environment where only your server code can access it.

Step 5: Use Railway Private Networking for Internal Services

If your Railway project has multiple services (for example, a web app and a PostgreSQL database), connect them using Railway's private network instead of the public URL.

Private URLs end in .railway.internal and only work within your project. The database is not reachable from the public internet at all.

In your Railway Variables tab, set:

DATABASE_URL=postgresql://postgres:password@postgres.railway.internal:5432/railway

Instead of the public URL that looks like:

DATABASE_URL=postgresql://postgres:password@containers-us-west-XX.railway.app:XXXXX/railway

With private networking, even if someone extracted your DATABASE_URL from source code, they could not connect to the database from outside Railway's network.

Step 6: Prevent Future Leaks

Pre-commit Hook with Gitleaks

Gitleaks scans for secrets before each commit:

# Install gitleaks (macOS)
brew install gitleaks

# Test your current repo
gitleaks detect --source . --verbose

# Add as pre-commit hook
cat > .git/hooks/pre-commit << 'EOF'
#!/bin/sh
gitleaks protect --staged --verbose
if [ $? -ne 0 ]; then
  echo "Gitleaks found potential secrets. Commit blocked."
  exit 1
fi
EOF
chmod +x .git/hooks/pre-commit

Railway Build Argument Warning

If you are using Docker on Railway and passing secrets as ARG values in your Dockerfile, those values are stored in the Docker layer cache and can be extracted from the image. Use Railway's runtime Variables tab instead of build arguments for secrets.

# Wrong: secret visible in image layers
ARG OPENAI_API_KEY
ENV OPENAI_API_KEY=$OPENAI_API_KEY

# Right: access process.env.OPENAI_API_KEY at runtime
# No ARG/ENV for secrets in Dockerfile