Everyone expects their homelab to be safe. After all, it’s sitting on your own hardware, behind your own firewall, running software you control. You’re not some bootcamp kid pushing .env files to GitHub. You know better.
Except when you don’t. And that’s the entire problem with credential leaks in version control — they don’t happen because you’re reckless. They happen because you’re human, you’re tired, and you’re one subdirectory deeper than your .gitignore rules are watching.
The Setup That Felt Bulletproof
Two years of beautiful infrastructure. Servers named after astronomical phenomena. Everything running smoothly, automated, well-organized. The kind of homelab you’d actually be proud to show someone. Then came the moment: a git add . command, typed from the /infra subdirectory instead of the root. A push to main. The way developers have destroyed security postures since Git became popular.
What got committed? The Authelia user database. Every TOTP secret for every service. A complete authentication event log with timestamps. All 311,296 bytes of it, encrypted as binary and wrapped up in a cheerful git log message: “add: 2fa formalized.”
Here’s the thing about .gitignore: it works great when you’re in the directory that has it. The root .gitignore said *.sqlite3. The root .gitignore was not consulted when I cd’d into /infra and typed git add . like a person who has never made a mistake before.
That’s not a bug. That’s how Git actually works—and nobody tells you this until it’s too late.
Why Your .gitignore Is Lying to You
Most developers think .gitignore is a security feature. It’s not. It’s a convenience feature. A way to say, “Don’t bother tracking these files.” But it only works when you’re in the repository root. The moment you cd into a subdirectory and run git add ., you’ve bypassed the entire safety net.
This is one of those design decisions in Git that makes perfect sense for version control (let subdirectories have their own rules) but catastrophic sense for security. Because you’ll never think about this until you’ve already committed credentials.
The problem cascades. You don’t realize what you’ve pushed until someone else clones the repo. Or worse—until you notice that your git log contains a readable history of every secret you ever stored. Even if you delete the file later, it’s still there in the commit history, waiting for anyone with repository access to check out that specific commit and extract your 2FA seeds.
And if that repository was ever public, or shared across a team, or synced to a backup service? The clock just started on when someone discovers those credentials.
Is a Five-Second Hesitation Enough?
The author mentions three things that actually save you: a .gitignore in the subdirectory where you’re working, the five-second pause before pushing to main, and—most importantly—all three at once.
But let’s be clear about what that pause actually is. It’s not a security mechanism. It’s just a moment where your brain catches up to your fingers and asks, “Wait, did I mean to commit this?” It’s the human equivalent of a compiler warning, and it only works if you’re paying attention.
The subdirectory .gitignore is better. It’s an actual barrier. But it’s also something else you have to remember to create, and something that can get out of sync as your infrastructure grows. What works today breaks when you reorganize your repo structure next month.
Here’s what actually protects you: treating secrets like they’re radioactive. They shouldn’t live in Git at all—not in a .gitignore, not in a subdirectory, not anywhere. Secrets belong in a secret management system (HashiCorp Vault, AWS Secrets Manager, even Bitwarden if you’re bootstrapping). Your Git repository should only contain references to where those secrets live, never the secrets themselves.
But that requires infrastructure. It requires discipline. It requires not committing the credentials file while you’re tired at 11 PM and just trying to get the automation working.
The Real Cost of Complacency
The homelab owner is counting days. One day and counting. Which is a way of saying: we don’t actually know when this gets discovered, or if it already has been. That’s the creeping dread of credential leaks. You could have been compromised for months. Someone could be using your TOTP secrets right now, and you wouldn’t know until they wanted to.
This isn’t a failure of the homelab owner. It’s a failure of the tooling. Git’s design decisions were made in 2005 when security consciousness was lower and private repositories weren’t the default. We’ve built enormous infrastructure on top of a version control system that treats credentials like any other file, as long as you remember to ignore them.
And we’ve normalized the stories. The “oops, I committed my AWS keys” tales get shared as funny anecdotes in Slack channels. Meanwhile, the actual damage—rotated credentials, access revoked, systems offline while you remediate—gets brushed aside as “lesson learned.”
The scarier part? This person built a homelab, which means they probably understand security better than 95% of developers. If they got caught by this, so will you. Probably already have.
What Saves You Going Forward
Don’t rely on .gitignore. Build secrets management into your deployment pipeline before you ever touch Git. Use git secret, sealed-secrets, or something equivalent that encrypts credentials at rest and only decrypts them in your CI/CD environment. Make it impossible to commit secrets, not just forgettable to exclude them.
Second, assume the worst about your Git history. Any secrets that ever made it to a commit should be rotated immediately, even if you think the repository is private. Check your GitHub search history. Check your backups. Check any CI/CD logs that might have printed environment variables.
Third, stop treating credential leaks as edge cases. They’re the norm. Every developer has done this at least once. The only question is whether your infrastructure catches it before it matters.
The homelab is still running, for now. But it’s running on borrowed time—the time it takes for someone to find those TOTP secrets in the git log and start using them. That could be tomorrow. That could be in five years. That’s the thing about version control: your mistakes have an expiration date, and there’s no way to know when someone will open that particular file and find what’s inside.
FAQs
Should I rotate all my credentials if I’ve ever accidentally committed them to git? Yes. Immediately. Assume that any credentials ever in version control have been compromised, even if the repository is private. Check your git history going back months, and rotate anything you find.
How do I remove secrets from my git history?
Tools like git-filter-branch or BFG Repo-Cleaner can rewrite history, but they don’t guarantee the old commits are gone from backups, forks, or cached copies. Prevention is better than remediation. Use a secrets management system instead.
Will .gitignore protect me from committing secrets? No. It’s a convenience tool, not a security tool. It only works from the repository root and can be bypassed by working in subdirectories. Use pre-commit hooks, secrets scanning, or secret management systems instead.
