Where to Store API Keys: A Secure Setup Guide

A key in the wrong place can turn a routine code push into an account takeover or an unexpected bill. Where to store API keys depends on who or what needs each one, so give every environment a separate, controlled source. Here’s a setup you can put in place without burying secrets in code or build files.

We analyzed 44 comments from Reddit and YouTube about the secure storage of API keys and found that 45% mentioned environment variables.

Step 1: Identify Where Each API Key Is Used

Start with an inventory. An API key is a credential that lets software access an API. Many keys are bearer credentials, which means anyone who gets a working key may be able to use it with the permissions attached to that key.

Write down each key’s purpose, owner, environment, and every system that reads it. Include local apps, deployment jobs, scheduled tasks, serverless functions, and any service that calls an outside API. A key with no known owner is hard to rotate safely. A key used by both staging and production can make a small test setup a path into live systems.

For each entry, record the provider, permission scope, storage location, and last known use. Note whether the provider supports separate keys, expiration dates, usage limits, or restrictions on where a key can be used. If a key is shared by a developer and a CI job, split it when the provider allows it. Separate credentials make it easier to see which workflow caused unexpected use.

Keep the inventory out of source code. A record should identify a secret without copying its value. A name such as payments-prod-api tells the team what to review without exposing the credential itself.

This is also the time to check whether an API key is the right credential. For a service-to-service task, your cloud platform may support short-lived credentials or workload identity instead. Those options can reduce reliance on long-lived keys, though they require a suitable setup. For common handling rules, see these API key security practices.

Milestone: You should have a list of keys, their owners, and every known consumer before changing storage.

Step 2: Choose a Secure Storage Location for Each Environment

Choose storage based on where the key is used. Local development, CI/CD, and production have different access needs. A local .env file may suit one developer’s machine when Git ignores it. Shared production credentials need controlled access and a clear path into the running app.

• Local development: Use environment variables or a local .env file that isn’t tracked by Git. For a team, a managed source can keep approved values in sync without sending them through chat.
• CI/CD: Use the pipeline’s encrypted secret store or connect it to a secrets manager. Give each workflow access only to the values it needs.
• Production: Use your hosting platform’s secret controls or a dedicated secrets manager. Deliver the value at runtime rather than putting it in code or a deploy artifact.

A cloud-native vault can fit well when your apps already use that cloud’s identity and access controls. AWS Secrets Manager, Azure Key Vault, and Google Secret Manager are examples of managed services. A team that needs shared environment files across local work and pipelines may prefer a .env-focused manager. The right choice is the one your team can secure and operate consistently, following secrets management best practices for storing, distributing, rotating, and auditing credentials.

Keep development, staging, and production separate. A staging app should not need the production payment key. Set permissions around the work being done, not just a person’s job title. Review who can read each environment’s secrets, and remove access when a role or project changes.

EnvManager centrally manages encrypted, version-controlled .env files with role-based access. It can sync secrets to local machines and CI/CD pipelines, which can cut down on manual copying between systems.

Milestone: Every key should have one approved source for each environment, with access limited to its consumers.

Step 3: Store Local Development Keys Outside Source Code

For local work, put secrets in environment variables or a local .env file, not in a source file or a configuration file that Git tracks. The app can read the value when it starts. The repository can stay safe to share.

Add local secret files to .gitignore before creating them. For example:

.env
.env.local
.env.*.local

Commit a template such as .env.example with variable names and harmless placeholders. That shows a teammate what the app needs without giving them a working credential. Check that the real file isn’t already tracked; adding a path to .gitignore does not remove a file Git is already tracking.

Don’t put a private API key in browser code. Build tools may copy certain environment variables into JavaScript files sent to every visitor. A browser can’t keep a secret from its user. Instead, have the browser call your server, then let the server use the secret to call the outside API.

Keep local files out of other artifacts too. A Docker build can copy files from its build context unless you exclude them with .dockerignore. Avoid printing environment variables during debugging, since logs can be stored or shared beyond your machine. And don’t paste keys into tickets, chat, or screenshots.

When multiple developers need the same project secrets, a shared controlled source is safer than sending files around. EnvManager is built to manage and sync team .env files, with role-based access for who can reach them. You can also use a command to provide a selected value to a process instead of copying it into a script:

envmanager run --only STRIPE_KEY -- npm run seed

Keep the command free of secret values. It names the variable, while the managed environment supplies its value.

Step 4: Inject Keys into CI/CD and Production Securely

CI jobs and production apps need secrets at run time, but the pipeline file and deploy package don’t. Store each key in the CI platform’s secret store or connect the job to a secrets manager. Then pass the value to the process that needs it. Never place the value in a workflow file, container image, or build log.

Scope access to the job and environment. A test workflow should not receive production credentials. For releases that need production access, use the platform’s environment controls and approval rules when available. Keep secrets out of command arguments where process logs or job output might reveal them.

For containerized apps, supply credentials when the container runs rather than baking them into the image. For Kubernetes or serverless deployments, use the platform’s approved secret injection method or a connected secrets manager. The precise setup depends on the platform, but the rule stays the same: the deployed workload gets the secret, not the build artifact.

AWS recommends storing each API key as its own secret and limiting retrieval to the specific secrets an application needs. Its guidance also describes a rotation flow that creates a replacement, tests it, then promotes it after validation. AWS’s API key security guidance shows how to apply those controls in AWS Secrets Manager.

EnvManager can sync managed environment values to CI/CD pipelines, giving a team a central place to update the values used by its workflows. Whatever delivery path you choose, check that the application receives the intended value in the intended environment. A successful build alone doesn’t prove that a key stayed out of logs or artifacts.

Before release: Confirm the job can read only its required secrets, then inspect its output for accidental values.

Step 5: Restrict Access, Rotate Keys, and Check for Leaks

Storage is only one control. Give each key the smallest permission set that lets its consumer do its job. If a reporting task only reads data, don’t give its key permission to change account settings. Use separate credentials for different apps or environments when the provider supports them.

Set a rotation plan that matches the provider’s options and your team’s risk. A safe rotation has an owner, a test, and a way to recover if the new key fails. Where two keys can remain active at once, create the replacement first, update and test consumers, then revoke the old key. If a key may have leaked, revoke or disable it promptly and replace it before cleaning up copies.

Google advises restricting API keys to reduce the ways they can be used, keeping only keys that are active, and monitoring usage for unauthorized activity. It also recommends stronger alternatives, such as IAM policies and short-lived service account credentials, for many production workloads.

Check usage records for unexpected activity. Look for calls from an unfamiliar location or service, changes in request volume, and use outside the key’s expected schedule. A central audit trail can help answer who accessed or changed a secret. EnvManager’s team-managed environment files include role-based access and audit logs, so teams can review secret changes without relying on chat history.

Run secret scans on code and repositories, including past commits when you suspect a leak. If a key lands in Git, deleting the visible line is not enough; the value may remain in commit history. Revoke it first. Then clean up the repository history and check build logs or artifacts for other copies. Remove unused keys rather than leaving old credentials active.

Make this a routine review, not a once-a-year scramble. Pick an owner for each credential and set a calendar reminder to check its scope, use, and rotation status.

Frequently Asked Questions

Should I store API keys in a .env file?

Yes, for local development, if the file stays out of version control and deployment artifacts. Add it to .gitignore before storing a key. For shared use or production, prefer a managed secret store or a platform’s encrypted secret controls, then inject the value when the app runs.

Can I put an API key in frontend code?

No, not if the key is private. Anything shipped to a browser can be read by the person using it, including values embedded in a JavaScript bundle. Keep private keys on a server and let the browser call that server. Use a deliberately public key only when the API provider says it’s meant for client-side use.

What should I do if I committed an API key?

Revoke or disable the key first, then create a replacement and update its consumers. Removing the value from the current file doesn’t remove it from Git history. After revocation, clean the history and check logs, build artifacts, and other copies. Treat the exposed key as compromised even if the repository was private.

How often should I rotate API keys?

Use the schedule required by your security policy and the key provider, then rotate sooner if exposure is suspected or access changes. A schedule alone isn’t enough. Test the replacement with the application before revoking the old key, and assign someone to confirm every consumer has switched.

Conclusion

Keep local keys outside Git, inject CI/CD and production secrets at runtime, and separate credentials by environment. Start by inventorying one service’s keys and consumers, then move them into an approved store. EnvManager can help teams manage shared .env files and sync values to local development and pipelines.