Where Should I Put API Keys in an AI-Built App?

API keys are secrets. Secrets must only exist in places that are not readable by the public. That means: not in source files, not in Git history, not in the browser, and not in screenshots or Notion pages.

The two safe locations are: a local .env file on your development machine (excluded from Git), and your hosting platform's environment variables panel (injected at runtime, never stored in code).

Everything else in this guide flows from that rule. If a key ends up anywhere else, it is in the wrong place — regardless of whether your AI coding tool put it there.

A .env file is a plain text file in your project root. Each line is a variable name and value: OPENAI_API_KEY=sk-proj-abc123. Your app reads it at startup. Locally, this file works as your private configuration store.

The .env file must be listed in .gitignore — a one-line addition (.env) that tells Git to skip this file forever. Verify this before your first commit. If you can see .env in GitHub Desktop's changed-files list, it is not yet ignored.

Create a companion file called .env.example that lists the same variable names with fake placeholder values (OPENAI_API_KEY=your_key_here). Commit .env.example to GitHub — it documents what variables the app needs without exposing real secrets. Anyone cloning the project copies .env.example to .env and fills in real values.

When you deploy, your .env file stays on your laptop. The hosting platform has no access to it. You need to paste each variable name and its production value into the platform's environment variables interface.

On Vercel: Project → Settings → Environment Variables. On Railway: your service → Variables tab. On Render: Environment → Environment Variables. On Netlify: Site settings → Environment variables. Each platform injects these values at runtime, so your app can read them through process.env or os.environ — exactly as it reads them locally from .env.

Use production API keys in production and test or sandbox keys locally wherever providers offer them. Stripe, for example, provides test keys (sk_test_...) for local development. This limits damage if a development machine or .env file is ever compromised.

When you hardcode a key in a .js, .ts, or .py file, it gets saved to Git history on the first commit. Even if you delete it later, the value remains readable in every commit that predates the deletion. Bots continuously scan GitHub for known key patterns.

Source code is also often shared. You send snippets to teammates, paste them into error reports, or use them in documentation. A real key embedded in code becomes a liability every time that code moves.

AI coding tools sometimes write keys directly into source files as part of generated integrations. Always review generated code for string literals that look like secrets (long random strings, anything starting with sk-, pk-, eyJ, or similar provider-specific prefixes).

Frontend code — React components, Vue templates, plain JavaScript in the browser — runs on your users' machines. There is no way to hide a value in frontend code. Anyone can open browser DevTools, view the network panel, or read your bundled JavaScript source.

Secret API keys must only ever appear in backend code: Next.js API routes, a Node.js server, a Django view, a serverless function. The backend receives requests from your frontend, makes the authenticated API call with the secret key, and returns only the safe result.

Some providers offer keys designed for browser use: Stripe's publishable key for checkout, Supabase's anon key with row-level security. These have limited permissions. Even then, read the provider's documentation carefully before trusting a key in the browser. When in doubt, proxy through a backend route.

Next.js and Vite expose environment variables to the browser only when they start with NEXT_PUBLIC_ or VITE_. This is intentional for non-sensitive values like your app's public URL or a publishable API key.

The trap: AI tools sometimes generate code like NEXT_PUBLIC_OPENAI_API_KEY=sk-proj-... because the frontend component that calls OpenAI needs to access the variable. This sends a secret key to every browser that loads your page.

The fix is to move the API call to a backend API route or server action. The frontend calls your own endpoint (like /api/chat), your backend reads process.env.OPENAI_API_KEY (without the NEXT_PUBLIC_ prefix), makes the OpenAI request, and returns the response. The secret never leaves the server.

GitHub is public by default and even private repositories carry risk — collaborators, forks, accidental visibility changes. Never commit API keys under any circumstances.

Your .gitignore file should include .env on its own line. Many framework starter templates include this, but verify it is present. If your AI tool generated a project without .gitignore, create one before your first git add.

If you suspect a key was already committed, do not just delete the file and commit again — the value remains in Git history. The right response is to rotate the key immediately with the provider, then optionally clean up history. Rotation is the non-negotiable step; history cleanup is secondary.

Search your project folder for strings that look like secret values: sk-, pk-, Bearer, api_key=, apiKey:, and any values you know are real keys. Most code editors have a project-wide search (Cmd+Shift+F or Ctrl+Shift+F). If any appear in source files rather than .env, move them.

Open .gitignore and confirm .env appears in it. Then open GitHub Desktop or run git status — if .env is listed as an untracked or changed file, it is not ignored and could be committed accidentally.

Check that your deployed app is reading the right values. Test a feature that requires an API key. If it works locally but fails in production, the hosting platform is missing that environment variable.