How to Remove an API Key From GitHub

If an API key was committed or pushed to GitHub, treat it as compromised, even if the repository is private or you quickly deleted the file. The safest order is to revoke or rotate the key with its provider first, remove it from the current project, then decide whether to rewrite Git history and request cleanup of provider-side copies.

1. Revoke or rotate the exposed API key immediately

Sign in to the service that issued the key and revoke it, disable it, or rotate it according to that provider's procedure. Create a replacement only if your application still needs one, and store it in the provider's approved secret manager or server-side configuration. Check usage and audit logs, and alert your security or platform team if required.

GitHub history cleanup does not deactivate a credential. A copied key may still work until its issuer revokes or replaces it, so do not wait for a force push, repository deletion, or cache cleanup before rotating it.

2. Remove the key from current files and prevent recommitting it

Replace the hard-coded value with a server-side environment variable or a secret manager. Do not put a private key in browser-facing code: variables bundled for a client application are visible to its users. Add local secret files to .gitignore, then inspect the repository state:

git status --short
git check-ignore -v .env.local

If the file was already tracked, adding it to .gitignore alone does not remove it from Git. If it should remain on your computer but no longer be tracked, remove it from the index with git rm --cached -- path/to/secret-file, then verify your local copy still exists and review the staged changes before committing. Never paste the live key into a search command, issue, chat, or cleanup file that could be shared.

3. Decide whether to remove the key from Git history

A new commit that deletes or replaces the key fixes the current files, but earlier commits may still contain the original value. If the commit never left your computer, you may be able to amend or rebuild local commits before publishing. If it reached GitHub, forks, collaborators, or automation, coordinate a history cleanup with the repository owner.

Rewriting published history changes commit IDs and affects every collaborator using the old history. Make a secure backup, pause pushes, agree on who will perform the cleanup, and prepare recovery instructions before replacing shared refs. Use git-filter-repo to remove a file or redact a value from all affected commits; choose the operation that preserves the rest of the file when needed.

For the detailed rewrite and coordinated push procedure, see how to remove secrets from Git history. Do not force-push rewritten history to a shared repository without the repository owner's approval and a plan for collaborators.

4. Check GitHub and other copies

After the key has been revoked and any approved history rewrite is complete, verify the current repository and coordinate with collaborators so old commits are not pushed back. Review whether the key appeared in branches, tags, forks, pull requests, releases, Actions logs, build artifacts, or other connected systems.

A force push cannot guarantee that every cached page, clone, fork, or log has been erased. Follow GitHub's current sensitive-data removal process and contact GitHub Support if the exposed value remains visible in cached views or references Git cannot remove. Keep the key revoked regardless of the cleanup status.

Prevent API key leaks in future commits

• Keep private credentials in server-side configuration or a dedicated secrets manager, never in client-side source code.
• Ignore local environment files and verify what is staged with git status and git diff --cached.
• Enable GitHub secret scanning and push protection where available; treat them as additional safeguards, not a replacement for revoking a leaked key.
• Limit key permissions and set expiration where the provider supports it.

API key removal from GitHub FAQ

Is deleting the GitHub repository enough?

No. It does not revoke the API key or guarantee that clones, forks, caches, and logs disappear. Revoke the credential with its issuer and handle Git and host-side cleanup separately.

Is changing the key in a new commit enough?

No. Earlier commits can still contain the exposed value. Revoke the original key, then assess and clean the history and any other locations where it was copied.