Home / Guides / I committed an API key to GitHub. What do I do?

I committed an API key to GitHub. What do I do?

Revoke or rotate the key first. Deleting the file or the commit doesn't make it safe, because the key stays in git history, clones and forks. Step-by-step from GitHub's own docs.

Check your live site

Run the free ShipLatch scan on your own site without leaving this page.

Uses 1 of your 3 free scans today; a site scanned in the last 24 hours answers from that scan. Passive and read-only: we only look at what any browser can see. Only check sites you own or may test.

Revoke or rotate the key first, before you touch the repo. GitHub's own docs say that when the sensitive data is a secret, the first step is to revoke or rotate it, and that once it's revoked it can no longer be used, which may be enough on its own (GitHub Docs).

Deleting the file in a new commit does not remove the key. It stays in your git history, and even after a history rewrite, copies can survive in clones, forks, cached views and pull requests (GitHub Docs).

If that key was also in a VITE_ variable, or your host serves /.git/, it's on your live site too. Scan free.

Plain steps

  1. Rotate the key at the provider. Create a new key, update your app to use it, then revoke the old one. For example, OpenAI says to rotate immediately from the API Keys page if you believe a key leaked (OpenAI Help Center), and ElevenLabs describes rotation as: create a new key, switch your apps over, delete the old key (ElevenLabs docs).
  2. Check for misuse. Look at the provider's usage or billing page for activity you don't recognize since the commit.
  3. Move the key out of your code. Put it in an environment variable or your host's secrets store, and add .env to .gitignore (GitHub Docs).
  4. Decide whether to rewrite history. GitHub documents using git-filter-repo --sensitive-data-removal followed by a force push, then contacting GitHub Support to clear cached views and pull request references (GitHub Docs). It warns of side effects: changed commit hashes, broken PR diffs, and the data coming back if a collaborator pushes an old clone. GitHub Support only helps when rotating the credential can't fix the risk (GitHub Docs). For most solo builders, rotation is the fix and the rewrite is optional.
  5. Check your live site too. If the same key was also in a VITE_ or NEXT_PUBLIC_ variable, it shipped in your frontend bundle as well (Vite docs). And if your host serves /.git/, your whole history may be downloadable.
  6. Stop it happening again. GitHub suggests a pre-commit hook with a tool like gitleaks, and push protection, which blocks pushes that contain secrets (GitHub Docs, GitHub push protection).

Did GitHub already catch it?

Maybe. For your own account, push protection is on by default and stops you pushing secrets to public repositories, but you can bypass it (GitHub push protection). GitHub also scans public repositories for known secret formats and sends matches to partner providers (GitHub partner program). Some providers then disable the key automatically: ElevenLabs says a key committed to a public GitHub repo is automatically disabled when third-party disabling is allowed for that key (ElevenLabs docs). Don't rely on this. Rotate it yourself either way.

Copy-paste into your AI builder
I committed an API key to git. Find every place a secret is hardcoded or stored in a committed file. Move each one to an environment variable without a VITE_/NEXT_PUBLIC_ prefix, read it only in server-side code, add .env* to .gitignore, and list every key I need to rotate. Don't rewrite git history.

FAQ

The repo is private. Do I still need to rotate?
Yes, to be safe. OpenAI notes that private repositories are more secure, but a breach can still leak keys stored in them (OpenAI Help Center).

I deleted the commit and force-pushed. Am I fine?
Not yet. GitHub says the commit can still be reachable in forks, clones, cached views and pull requests (GitHub Docs). Rotate the key.

Is git rm enough?
No. That removes the file from future commits only. The old commit still has it.

How do I know the new key isn't on my live site?
Scan the deployed site after you redeploy. A re-scan proves the key is gone from what your site serves; it can't prove the old key was revoked, so revoke it at the provider yourself.

Check yours

GitHub covers your repo. ShipLatch checks what your live site serves: leaked keys in your page, JavaScript and public source maps, plus exposed /.git/HEAD and /.git/config. Free, passive, no signup. Scan your app free at shiplatch.com. To block the next commit, the free Guard Kit sets up gitleaks as a pre-commit hook and GitHub Action.

Related: How to check if your .env is exposed · Leaked Stripe secret key

Sources (all fetched 2026-10-28)

  1. GitHub, Removing sensitive data: https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/removing-sensitive-data-from-a-repository
  2. OpenAI, API key safety: https://help.openai.com/en/articles/5112595-best-practices-for-api-key-safety
  3. ElevenLabs, API Keys: https://elevenlabs.io/docs/overview/administration/workspaces/api-keys
  4. Vite, Env Variables and Modes: https://vite.dev/guide/env-and-mode
  5. GitHub, Push protection: https://docs.github.com/en/code-security/secret-scanning/introduction/about-push-protection
  6. GitHub, Secret scanning partner program: https://docs.github.com/en/code-security/tutorials/secret-scanning-partner-program

Want the whole pre-launch process in one place? Get App Security for Vibe Coders, our $9 PDF playbook. See what's inside.

More guides