Accidentally Pushed .env to GitHub? Do This First
If you accidentally pushed a .env file to GitHub, the very first thing to do is remove the file from the repository history and rotate every secret it contains—do not just delete the file and commit. Treat every API key, password, and token as compromised because GitHub may have already indexed and cached it, even if you delete it quickly.
Why This Is an Emergency
A .env file typically holds environment variables that your application needs to run: database credentials, API keys, OAuth tokens, and secret keys. Once pushed to a public GitHub repository, that file becomes part of the repository’s history. Even if you delete it in a later commit, the file remains accessible in the commit history. GitHub also scans public repositories for secrets and may alert third-party services, and services like gitleaks or trufflehog can find it too. The window between your push and your realization could be minutes or hours—enough time for automated bots to scrape and exploit the exposed secrets.
Immediate Steps to Take
- Revoke and rotate every secret in the .env file. Go to each service (database, cloud provider, API, payment gateway) and generate new credentials. Do this before anything else—it is the only action that truly neutralizes the leak.
- Remove the file from the repository history using a tool like
git filter-repoor the BFG Repo-Cleaner. A simplegit rmonly removes it from future commits; the old commit still contains it. - Force-push the cleaned history to GitHub. This rewrites the repository, but you must coordinate with any collaborators to avoid losing their work.
- Check GitHub’s secret scanning alerts (if enabled) and review the repository’s forks—forks may have already copied the file.
- Add a .gitignore rule for
.envfiles to prevent future accidents.
How to Remove the File from History
The most reliable method is git filter-repo. First, install it, then run:
git filter-repo --invert-paths --path .env
This rewrites the entire commit history, removing the .env file from every commit. After that, force-push with git push --force --all. If you cannot install filter-repo, the BFG Repo-Cleaner is a simpler alternative: bfg --delete-files .env. Both tools rewrite history, so make sure you have a backup of the repository first.
If the repository is shared, you must notify all collaborators—they will need to re-clone the rewritten repository. Any existing clones still contain the old history, so treat those as compromised too.
What About GitHub’s Secret Scanning?
GitHub automatically scans public repositories for known secret patterns (like AWS keys, GitHub tokens, and Slack tokens) and notifies the relevant service providers. If you rotate the secrets quickly, the notification is harmless. However, if you do not rotate, the service provider may revoke the secret automatically or leave it active—both are risky. GitHub’s secret scanning does not scan for arbitrary strings, so a custom API key might not be detected. That is why rotating everything is essential, regardless of scanning.
Common Mistakes to Avoid
- Deleting the file and committing the deletion—this leaves the secret in history.
- Only changing the file locally—the remote still has the old version.
- Assuming private repos are safe—even private repos can be accessed by anyone with read access, and the secret is still exposed to collaborators.
- Forgetting to rotate secrets that were in the file—even if you remove the file, the secret is already out there.
- Not checking forks—a fork made before you cleaned the history still contains the secret.
How to Prevent This in the Future
Add .env to your .gitignore file immediately. Use environment-specific files like .env.local and keep them out of version control. Consider using a secrets manager (like AWS Secrets Manager or HashiCorp Vault) for production. For local development, you can use .env.example with placeholder values that you commit, and actual .env files that you never commit. Also, enable Git’s pre-commit hooks with a tool like pre-commit that scans for secrets before each commit.
Frequently Asked Questions
Can I just delete the repo and recreate it?
Yes, but only if you are certain no one has forked or cloned it. If you delete the repository, all forks are deleted too, but any local clones still exist. The safest approach is still to rotate secrets and clean the history, because you cannot guarantee that someone hasn’t already copied the file.
What if the repo is private?
Private repos are less exposed, but the secret is still visible to anyone with access. If the repo is private and you have not shared it, you might be safe with just rotating the secret and deleting the file from history. However, if you have collaborators, they see it too, so treat it as compromised.
Does GitHub automatically delete secrets from history?
No. GitHub does not automatically remove secrets from commit history. It only scans for known patterns and alerts the provider. The secret remains in the history until you rewrite it.
How do I know if my secret was already used?
You cannot know for sure. Check your service’s access logs for unusual activity, but the only reliable way to be safe is to rotate the secret immediately. Do not wait for evidence of misuse.
What if I don’t have the .env file anymore?
If you lost the file, you still need to rotate every secret that was in it. You can often reconstruct the list from your deployment configuration or by checking the commit history of the file before you deleted it.
Is it enough to use git revert?
No. git revert creates a new commit that undoes the changes, but the original commit with the secret remains in history. You must rewrite history with git filter-repo or BFG.
Related
Method: the standard formula for this calculation, rounded as each result states. See how the calculators work or report an error.