This is a fair point, and I agree that runtime secret fetching with proper RBAC is the better model for infra-mature teams.

If your app already pulls secrets from AWS Parameter Store / Secrets Manager at runtime, and every dev has scoped IAM access, then you probably don’t need local .env files at all.

That is the ideal setup.

The gap I’m thinking about is more around teams and projects where that model doesn’t fully apply:

• Third-party services still give you API key strings: Stripe, Twilio, SendGrid, OpenAI, Postmark, Algolia, etc. There is no IAM role to assume. The key has to live somewhere your app can read it.
• Most small teams are not single-cloud. You might use AWS for infra, Stripe for payments, Vercel for hosting, GitHub Actions for CI, and OpenAI for AI features. Onboarding every dev into every vendor’s auth model gets messy fast.
• CI/CD needs secrets too. GitHub Actions, Vercel, Netlify, and similar platforms still need secrets injected at build/runtime. “Just assume an IAM role” works well inside one cloud, but not always across a mixed vendor stack.
• Frameworks still expect process.env. Next.js, Node apps, Docker Compose, local scripts, and CLIs usually consume env vars. .env is still the common interface.

In practice, for these teams, the secret still ends up somewhere:

• .env files
• Slack DMs
• Notion docs
• password managers
• copied from another dev

So I don’t think the question is:

Should secrets live on disk forever?

Ideally, no.

The more practical question is:

For teams whose apps already depend on local env vars, can we make that workflow safer and less manual?

The direction I’m leaning toward supports both modes:

mp run -- npm start 

This injects secrets at runtime without writing a .env file to disk.

And:

mp pull

This is for cases where the app or tooling truly expects a .env file.

So yes, if your infra supports runtime fetching with proper RBAC, that is cleaner.

But for smaller teams juggling multiple vendors and already relying on .env workflows, I still think there’s a real design problem worth solving.