How to Hide API Keys Before Deploying Your App

Local development happens on your machine — if a key is in the wrong place but never pushed to GitHub or deployed, the risk is contained. The moment you deploy, you create a public URL. And the moment you push to GitHub, bots start scanning.

Fixing key exposure after the fact requires more steps: rotating credentials, cleaning Git history, and verifying no unauthorized usage occurred. Fixing it before deploy is a much smaller task.

This checklist is designed to be completed in under an hour for most apps. Do it once before your first production deploy. It also makes future deploys safer because the infrastructure is correct from the start.

Open your code editor and use project-wide search (Cmd+Shift+F on Mac, Ctrl+Shift+F on Windows). Search for patterns that look like API keys: sk-, pk-, Bearer, api_key, apiKey, secret, password, and any specific key prefixes you know your providers use.

Also search for actual key values you have seen — if your OpenAI key starts with sk-proj-abc, search for that prefix. Check every file type: .js, .ts, .jsx, .tsx, .py, .env (to confirm it exists), config files, and any README or documentation files.

If your AI tool generated the project, pay special attention to generated integration files, configuration modules, and any file that imports an external SDK. AI tools sometimes embed real values in the initial setup code to make things work quickly.

For every hardcoded key you found, create a corresponding entry in your .env file. In the source code, replace the literal value with an environment variable reference: process.env.OPENAI_API_KEY in Node.js and Next.js, os.environ['OPENAI_API_KEY'] in Python and Django, import.meta.env.OPENAI_API_KEY in Vite (for non-secret values only).

Test locally after each change to confirm the app still works. The environment variable name must match exactly — these are case-sensitive. If your .env has OPENAI_API_KEY but your code reads process.env.openai_api_key, it will be undefined.

Pay attention to where the code runs. If your AI tool made API calls directly from a React component, the call needs to move to a backend route (a Next.js API route, a serverless function, or a separate server) so the key stays on the server and never reaches the browser.

Open .gitignore in your project root (create it if it does not exist). Verify that .env appears on its own line. Save the file.

Then confirm the change worked: run git status or look at GitHub Desktop's file list. Your .env file should not appear as a tracked, modified, or new file. If it still appears, there is a problem — .env may already be tracked from a previous commit. In that case you need to untrack it: git rm --cached .env.

Common variations to also ignore: .env.local, .env.development.local, .env.test.local, .env.production.local. Many framework templates include these patterns already — check your existing .gitignore against your framework's recommended defaults.

.env.example is a safe, committed file that documents what environment variables your app needs. It uses placeholder values instead of real ones: OPENAI_API_KEY=your_openai_key_here, DATABASE_URL=your_database_url_here.

Copy your .env file to .env.example. Go through every line and replace the real value with a descriptive placeholder. Keep the variable names identical — they are the important part. Commit .env.example to GitHub.

Future collaborators and your future self will use .env.example as a checklist. When someone clones the project, they copy .env.example to .env and fill in real values. Without this file, the app is a mystery to anyone who did not set it up originally.

If a key appeared in source code at any point — even briefly — assume it may have been seen or copied. This is especially true if you pushed to GitHub, shared the code, or deployed to a public URL before today.

Rotation is fast: open the provider's API dashboard, revoke the current key, generate a new one, update your local .env, and add the new value to your hosting environment variables. The old key is invalid immediately.

Check the provider's usage logs for unexpected activity after rotating. Look for unusual request volumes, requests from unfamiliar locations, or operations you did not initiate. Report significant anomalies to the provider.

After moving keys to environment variables, restart your local development server to reload the .env file. Verify that every feature requiring an API key still works. Check the browser console and server logs for missing variable errors.

A common failure pattern: the variable name in .env and the variable name in code do not match. STRIPE_KEY in .env and process.env.STRIPE_SECRET_KEY in code will leave the app reading undefined. Match them exactly.

If you have automated tests, run them now. Any test that was previously passing with hardcoded values will continue to pass with environment variables — if the values are actually being loaded correctly.

Your .env file stays on your development machine. The hosting platform needs the same variable names with production key values. Log into your hosting dashboard and navigate to the environment variables section.

On Vercel: Project → Settings → Environment Variables. On Railway: your service → Variables tab. On Render: Environment section of your service. Add each variable from .env.example and provide the real production value.

If you have separate staging and production environments, add variables to each. Consider using test or sandbox keys in staging where providers offer them. After adding variables, trigger a new deployment so the running app inherits the latest values.