1Password Environments: The End of Plaintext .env Files?
I counted six .env files on my laptop last week. AWS keys, database URLs, API tokens for three different services. All plaintext. All “protected” by .gitignore. We all know this is bad. We do it anyway.
1Password has a new feature in beta called Environments that tries to fix this. I spent some time evaluating it for my Rails projects, and I have mixed feelings.
The trick with named pipes
You create an “Environment” in 1Password — call it staging or local or whatever — and fill it with key-value pairs. Your usual DATABASE_URL, AWS_SECRET_ACCESS_KEY, that sort of thing.
Then you mount it to a path like /path/to/project/.env. Here’s where it gets interesting: 1Password doesn’t write a file. It creates a UNIX named pipe. Your app reads it like a normal .env file, but the data never actually lands on disk. 1Password intercepts the read call and serves secrets straight from the vault, in memory.
The first time you read it, you get an authorization prompt. After that it stays unlocked until 1Password itself locks.
It’s a neat trick. I like the approach.
Works with your existing dotenv setup
This is the part that sold me on trying it at all. The named pipe is transparent to dotenv libraries:
- Ruby
dotenvgem — works - Python
python-dotenv(v1.2.1+) — works - Node.js
dotenv— works - Go
godotenv— works - Docker Compose — works
No code changes needed. Dotenv.load reads the pipe the same way it reads a file. Your app doesn’t know the difference.
Where I see the value
The team sharing angle is real. I’ve DMed .env files over Slack more times than I’d like to admit. With Environments, you share access to a named set of secrets instead. New person joins, you grant them the staging environment, done. No copy-pasting credentials in chat.
There’s also an AWS Secrets Manager sync — push from 1Password to AWS directly. And if you’re using Cursor for AI-assisted coding, it validates .env contents before the agent runs commands. Small thing, but I appreciate the paranoia.
The problems
Here’s where I cooled off.
Named pipes are single-reader. If your IDE reads .env at the same time as your Rails server, one of them might get nothing. In practice, with bin/dev running Puma + CSS + JS watchers, that “might” becomes “will, eventually.” I haven’t hit it yet in testing, but I can see it happening during a regular workday.
You’re also capped at 10 mounted .env files per machine. If you run a lot of services locally, that’s tight.
And the big one: 1Password desktop has to be running and unlocked. No headless mode. So this is strictly a developer laptop thing. Don’t even think about it for servers or CI.
Still beta, Mac and Linux only.
What I’m actually using instead
For my own projects, I’ve stuck with op run:
op run --env-file=.env.tpl -- rails server
You write a template file with 1Password references instead of real values. At launch, op resolves them and passes actual secrets as environment variables. Nothing on disk. No named pipe concurrency issues. It’s been stable for months.
Environments would be worth switching to if I had a team of five people who all needed the same secrets and I was tired of managing who has what version of which .env file. For solo work or a two-person team, op run does everything I need.
My take
Good idea, too early. The named pipe approach is genuinely clever, and the dotenv compatibility means you could adopt it without touching application code. But the concurrency limitation is a real problem for local development, and the 10-file cap feels arbitrary.
I’ll check back when it’s out of beta. For now, op run does the job.