Dot env vs Infisical: Which One Actually Scales Better

The scale of the problem isn't the .env file. It's what happens after.

Someone on a team I worked with force-pushed over a .env file into a public fork last year. We caught it fast, rotated the keys in twenty minutes, and moved on. But the number that actually stuck with me came later: GitGuardian's 2026 State of Secrets Sprawl report counted 29 million new hardcoded secrets on public GitHub in 2025, a 34% jump from the year before. That's not a rare mistake anymore. That's the default outcome of how most of us manage secrets, whether we admit it or not.

So when someone asks "should I switch from .env to Infisical," the honest answer is: it depends on what's actually leaking in your setup, not on which tool sounds more grown-up.

What .env is actually good at

.env files exist because they solve one problem extremely well: getting a project running on a new machine in under a minute. No account, no API calls at boot, no dependency on a third-party service being up. You clone the repo, copy .env.example to .env, fill in your keys, and you're running. For a solo project or an early-stage SaaS with one or two environments, that's not a weakness. That's the entire value proposition.

The problem is that .env was never designed to be a secrets manager. It's a local config convenience that got pressed into service as one. OWASP has been saying for years that environment variables aren't ideal for production secrets, because any process on the box can read them, and they show up in crash dumps, logs, and ps output more often than people expect.

Where it actually breaks

Three things compound as a team or a codebase grows:

Rotation doesn't happen. GitGuardian's data shows 64% of secrets leaked back in 2022 were still valid in 2026. Nobody forgot to rotate on purpose. Rotation across a .env file means touching every environment, every CI runner, every teammate's machine, by hand. That friction is why it doesn't happen until something breaks.

Git history doesn't forget. Deleting .env from your latest commit does nothing for the copy sitting in every earlier commit, every fork, every clone someone made six months ago. You need git-filter-repo and a full history rewrite, and even then, anyone who already cloned the repo still has the old secrets.

CI/CD is now the bigger attack surface than your laptop. GitGuardian found that 59% of compromised machines in 2025 were CI/CD runners, not developer laptops. If your .env values get copy-pasted into five different pipeline configs, you've multiplied your exposure by five, and you won't notice until one of those pipelines gets popped.

There's also a newer wrinkle worth naming directly: AI coding tools read your local files. Cursor was reported sending .env contents to its own servers for tab completion, even when the file was listed in .cursorignore. If you're pairing with an AI assistant that has filesystem access, a plaintext .env sitting in your project root is no longer just a risk between you and your team.

What Infisical actually adds, and what it doesn't

Infisical's MIT-licensed core gives you a real dashboard, a CLI, SDKs, a Kubernetes operator, and secret scanning, and you can self-host all of it for free. infisical run -- npm run dev replaces your .env file with secrets pulled at runtime, which means nothing sensitive sits on disk in plaintext.

But here's what the marketing pages gloss over:

• Pricing is per identity, and identities include machines. Pro is $18 per identity per month, and an identity is any human or service account, bot, or CI runner. Ten developers plus twenty machine identities lands you at $540 a month. That number sneaks up on bootstrapped teams who counted seats and forgot their pipelines count too.
• Self-hosting isn't all-you-can-eat. The free MIT core covers basic secrets management, but RBAC, secret versioning, and SSO beyond Google or GitHub require a Pro license key, even on your own infrastructure.
• No native dynamic secrets. If you want auto-rotating database credentials, that's Vault's territory. Infisical needs you to build the rotation logic yourself.
• RBAC is project-level, not secret-level. You can't hand someone access to three specific secrets in an environment. It's all or nothing per environment.
• Cross-environment references don't work. You can reference one secret inside another's value, but only within the same environment.

None of that makes Infisical bad. It makes it a tool with real tradeoffs, which is more than you can say for most of the comparison posts written by the vendors themselves.

The rule I actually use

Forget "which tool is better." Ask two questions: how many machine identities touch your secrets right now, and what happens the day one of them gets compromised.

If you're a solo builder with one staging environment and a handful of API keys, a disciplined .env setup with a pre-commit secret scanner like gitleaks and a real .gitignore will outperform an Infisical instance nobody bothered to configure properly. Add the scanner today:

gitleaks protect --staged --verbose

If your CI pipeline has more running identities than your team has people, or you're syncing the same keys across five environments by hand, the math flips. At that point Infisical's free tier (five identities, three projects, self-hosted) is worth setting up before you hit the Pro paywall, and the $18-per-identity jump is the price of not finding out about a leaked key from a Slack alert at 2am.

.env isn't the enemy here. Secrets that never expire are. Whatever you use to store them, the actual fix is treating every credential like it has a shelf life, and building the rotation habit before you need it, not after.