Shift Note: Keep API Keys Out of the Next Commit

An API key is a credential, not project content

An API key lets an application act against a service account. Depending on its permissions, that can mean spending credits, accessing data, or changing resources. Treat it like a password, even when it looks like an ordinary string in a configuration file.

Git records snapshots of your project. If a key enters one of those snapshots, deleting it from the latest file does not remove it from earlier commits. A private repository also is not a secret vault: collaborators, automation, backups, and compromised accounts can widen access.

Give the application a key without giving Git a copy

The basic separation is simple: commit the instructions for finding a key, but keep the actual key outside tracked files. A common approach is to have the application read an environment variable such as OPENAI_API_KEY instead of embedding the credential in source code.

For local development, many projects store variables in a .env file. That file is still plain text, not encryption. Keep it out of Git, restrict access to your machine, and use the framework’s supported configuration loader. A .env file does not load itself automatically in every application.

• Add .env and any other secret-bearing local configuration files to .gitignore before creating or filling them.
• Commit a .env.example file containing variable names and obvious placeholders, such as OPENAI_API_KEY=replace_me.
• Document which variables are required so teammates can configure their own credentials without asking for yours.
• Use your hosting platform’s secret store or a dedicated secrets manager for deployed applications.

Keep credentials on the server side. A variable included in browser JavaScript or a distributed mobile application can be extracted, even if it came from an environment variable during the build.

Check what Git already knows about the file

A .gitignore rule only helps with files Git is not already tracking. If .env was previously committed, adding it to .gitignore does not stop Git from tracking changes to it.

The command git rm --cached .env removes that file from Git’s index while leaving your local copy in place. Commit the removal and the ignore rule. This fixes future tracking, but it does not erase earlier copies or make an exposed key safe again.

Before each commit, inspect git status and git diff --cached. The second command shows the changes staged for the next commit. Check configuration files, notebooks, test fixtures, and copied debugging output rather than reviewing source files alone.

Put a scanner between mistakes and shared history

Secret-scanning tools can inspect staged changes, commits, or repository history for likely credentials. A pre-commit check can catch a mistake locally; repository-side scanning adds another checkpoint after code is shared.

Neither is a guarantee. Scanners can miss unfamiliar key formats and flag harmless examples. Use clearly fake placeholders, investigate alerts, and avoid bypassing a warning merely to finish a commit. Keep keys out of logs, issue reports, and screenshots too.

Rotate an exposed key before cleaning up Git

If you commit a real key, treat it as exposed. Revoke or rotate it first. Update the applications that need the replacement through your normal secret-delivery process, then review available usage and access records for unexpected activity.

Next, remove the credential from current files and assess whether repository history needs rewriting. Coordinate that cleanup with collaborators because rewritten history affects their clones and branches. Deleting a repository or force-pushing cleaned history cannot recall copies someone already downloaded.

Keep relay configuration separate from relay credentials

If your application needs access to several model families, Relay365 is a pay-as-you-go relay desk worth considering. Its API base is https://api.api365relay.com; OpenAI clients add /v1. The endpoint can usually live in shared configuration, but the account key should stay in your local environment or deployment secret store.

Create a Relay365 account if that setup fits your workload, then apply the same rule from the first request onward: share the configuration shape, never the credential. The next shift should find a runnable project and no live keys in its commits.