API Key Vault: Set Up and Secure It

An API key copied into a repo or chat can outlive the task it was meant to support. An API key vault gives your team one controlled place to store credentials and deliver them to the right app or workflow.

Use these five steps to plan the vault, set access rules, add keys, connect development workflows, and test recovery. EnvManager can help teams manage encrypted .env files and sync secrets to local machines and CI/CD pipelines.

Step 1: Inventory Your API Keys and Define Vault Requirements

Start with a list of credentials and every place that uses them. A vault won't fix secret sprawl if your team doesn't know which keys exist or which services still need them.

Search active repos, deployment settings, local .env files, CI/CD workflows, and shared team documents. Record each key's owner, purpose, environment, and consumers. Don't copy the secret value into the inventory. A key name such as STRIPE_KEY is enough to identify it safely.

Next, mark keys that are expired, unused, or shared across unrelated apps. A development key should not be the same credential used by production. Where an API provider supports separate keys and scopes, create credentials with only the permissions each app needs.

Define the requirements before picking the vault setup. Decide who can add or read secrets, how local developers will get them, how CI jobs will authenticate, and what records you need for reviews. Map where key material is processed or stored, then choose controls based on the application's security needs.

Keep the inventory useful, not sensitive. Track a secret's owner and intended use, then store the value only in the approved vault. Teams comparing different storage patterns can use this overview of API key management tools to frame their requirements.

By now, you should have a list of active keys, their consumers, and clear rules for development, staging, and production. Pick one low-risk app for the first setup.

Step 2: Create the Vault and Set Access Policies

Create a separate boundary for each environment, either as distinct vaults or as clearly separated projects and environments inside your chosen system. The goal is simple: a developer working on a test build shouldn't be able to pull a production credential by mistake.

Use a unique identity for each person, app, and CI job. Avoid shared team logins. When access is tied to a specific identity, you can remove one person's access without changing everyone else's workflow.

Set permissions by role and purpose. For example, a developer may read development secrets but have no access to production values. A deployment job may read only the credentials needed by its app. A vault administrator can manage membership and policies without using that elevated access for routine coding.

Keep write access narrower than read access. Limit who can add, change, or remove a key, and set an approval step for production changes if your process calls for one. Review access when a teammate changes roles or leaves. Remove old grants promptly instead of leaving them in place for convenience.

Where your vault supports them, restrict access with role-based permissions, monitor activity, and limit network access. Allow only approved identities and routes to reach sensitive values.

EnvManager is built around centrally managed .env files with role-based access, so teams can share environment values without sending a file around by hand. Keep the policy tied to the work: access should match the app, environment, and task.

By now, you should have a working vault with separate environment boundaries and named roles. Test one developer account and one app identity before adding the full team.

Step 3: Add API Keys and Protect Their Values

Add keys from their source system, not from a stale copy in a document or an old local file. If you can't confirm a value is current, issue a replacement through the API provider before moving on.

Use a clear, consistent name. Include the service and purpose, such as STRIPE_KEY or MAPS_READ_TOKEN, and keep environment labels in the vault's structure. Don't put the actual value in the name, description, ticket, or commit message.

Before saving a credential, check whether the provider lets you narrow its scope. A read-only key for a reporting job should not have write access. If the provider can create separate keys for separate apps, avoid one shared key that every service depends on.

Never place a live key in source code, a checked-in config file, or a command that saves it to shell history. Also check build output and application logs. A masked secret can still leak if a script prints the value or includes it in an error message.

Store API keys in a secrets vault instead of embedding them in application source code.

When you move values into the vault, update the app to use the vault-backed workflow. Then remove the old copies and check the repository history for exposed values. A deleted line can remain in earlier commits, so treat a key found in version control as exposed and replace it. EnvManager encrypts and versions managed .env files, giving teams a central place to track changes rather than passing values through chat.

By now, you should have current keys stored under clear names, with old copies removed or revoked. Verify the first app can read its secret without printing it.

Step 4: Connect the Vault to Local Development and CI/CD

A vault is useful only when the right process can retrieve the right value at the right time. Connect local development and deployment jobs through approved identities or integrations, not through a shared master key pasted into config.

For local work, give developers a clear way to sync only the environment they need. Keep production values out of a routine local pull. If someone needs production access for a specific task, make the request deliberate and time-bound where your tools support it.

For CI/CD, assign each workflow a distinct identity and scope its access to the app it builds. A test workflow should not be able to fetch credentials for unrelated production services. Keep secret retrieval separate from code so you can change a key without editing or rebuilding the application source.

EnvManager syncs managed .env files to local machines and CI/CD pipelines. It also connects to platforms such as Vercel, Dokploy, and Coolify. The command runs a task with one selected secret:

envmanager run --only STRIPE_KEY -- npm run seed

That command shows the value's role in the process without placing it in the command text. Check your own tool's setup steps before adapting it. Microsoft recommends managed identities for applications running in Azure, which can remove the need to keep a separate credential in code.

Run the same test at each boundary: local development, CI, and deployment. Confirm the app works, the secret stays masked in output, and an identity without permission gets denied. Keep the workflow repeatable so a new teammate doesn't need a private .env file sent by hand.

By now, you should have one verified local retrieval path and one verified CI/CD path. Run a deployment test using the least-privileged identity.

Step 5: Rotate Keys, Monitor Access, and Test Recovery

Rotation is a change to a live dependency, so plan the handoff before revoking the old value. First, confirm which apps and jobs use the key. Then create a replacement and store it in the vault under the right environment.

Where the provider allows two active keys at once, keep the old key live while you update each consumer. Test the app and watch for failed requests. Once all known consumers use the replacement, revoke the old key. If a provider doesn't support overlap, schedule a short maintenance window and make the rollback path clear.

Set a rotation trigger based on your risk and provider controls. Rotate immediately if a key appears in a public repo, a log, or an unintended message. For planned changes, set an owner and a due date. A calendar reminder alone isn't a rotation plan unless someone can verify every consumer has moved.

Monitor reads and changes. Review which identity accessed a secret, which value changed, and whether the event fits the work underway. Alert on denied access or unusual access patterns where your vault supports alerts. Test logging changes outside production and monitor audit logging health.

EnvManager versions changes to managed environment files, which helps teams trace edits and restore an earlier version when a change breaks an app. For a rotation runbook, use this API key rotation workflow to plan overlap, validation, and rollback. Keep recovery steps separate from the secret itself.

Test recovery before an incident. Pick a non-production key, revoke or replace it through the documented process, and confirm the app recovers. Then verify that the audit record shows the expected change. If recovery depends on one person or one laptop, write down the missing handoff and fix it.

By now, you should have an owner, rotation path, access review, and recovery test for each important key. Schedule the next review before closing the task.

Frequently Asked Questions

What is an API key vault?

An API key vault is a controlled system for storing credentials and granting approved people or apps access to them. Instead of leaving values in source code, chat, or scattered files, teams keep them in one managed place. A useful setup also separates environments and records changes or access events.

Can I store API keys in a .env file?

You can use a .env file for local app configuration, but don't commit live secrets to version control or share the file through chat. Keep the source value in a vault and use a controlled workflow to sync it to the local machine. Limit access to the environment the developer needs.

How should I give API keys to CI/CD?

Give each pipeline an identity with access only to the keys its job needs. Retrieve secrets through the vault or an approved integration during the workflow, and avoid putting values in source files or logs. Test that an unauthorized job is denied before using the setup for production releases.

How often should I rotate API keys?

Set rotation timing based on the provider, the key's permissions, and your team's risk rules. Rotate a key right away if it may have been exposed. For a planned change, identify every consumer first, test the replacement, then revoke the old key after the app works with the new one.

Conclusion

Build the vault around least privilege and a tested path from storage to each app. Start with one low-risk service, move its key, then verify local access, CI/CD access, and recovery. EnvManager can manage encrypted .env files centrally and sync them to team workflows; choose one app and run the first migration.