We kept leaking .env files across environments—here’s how I solved it
Sharing our secrets among our teammates and across our environments was becoming a liability. So I decided to take matters into my own hands.
A quick story
Last year when I onboarded a new developer on the team I was managing, I quickly ran into a couple issues with the onboarding process. First, I realized our documentation was pretty bad and scarce, but if you are in software development, chances are yours is too. The second issue was environment setup. He started asking questions about which database connection he should be using and which API key he should be using for this service. Naturally, his next question, "can you send me your environment file in Slack?" This happened three or four more times. So in a ten-minute period we had dumped a couple hundred environment variables into our team's chat without really thinking twice about it. What made the situation worse were we discovered several credentials were out of date or no longer active, forcing the entire team to drop what they were doing and help our new developer get unblocked.
It was at this point I realized we needed to change. Our onboarding experience needed to get better, our documentation needed to get written, but most importantly, our security HAD to get better.
In my recent other Slack and security-related post, I cited an interesting statistic from GitGuardian that:
38% of incidents in collaboration tools were classified as highly critical or urgent, higher than in code repositories.
Slack, Teams, Jira, Linear, and Clickup are all collaboration tools. So as it turns out, my false sense of security that I get by using Slack or Teams is just that: a false sense of security. Any sensitive information that I share with a co-worker could still be compromised no matter the protocols or safeguards that are in place by myself, the company, or those IT guys.
Using other solutions
If you have been around the software development industry long enough, you are sure to know there are many methods for storing secrets for your applications. If you use a cloud/serverless platform that is worth anything, they will have their own solution for storing secrets as well. So when it comes to securing your stuff in the cloud, you have options.
But the problem that I kept coming up against was when you are sharing keys and environment settings among your coworkers and peers.
Cloud-based secrets
Most platforms like AWS Secrets Manager are designed to keep your keys persistent and secure in a cloud environment. You are able to retrieve specific values, but that's assuming you have access to the AWS control panel and you know what you are looking for. Depending on your processes, those vaults could be unorganized and vague at best, not to mention the bloated overhead.
Password keychains
Credential managers like 1Password or Dashlane are more focused on authentication/credentials for websites, applications and servers. For a user name and password, or a one-time password, I would absolutely recommend one of those solutions. But for a Stripe API key with the accompanying OAuth callback URL and webhook settings, the user experience just doesn't align when you are trying to replicate an application configuration or environment from one machine to another.
What I wanted
Let me first say the solutions that I have referenced above are fine services. They are polished, secure, and proven platforms that tons of developers and organizations use to secure their secrets. However, I found that existing credential management solutions were not suitable for the way development teams create software.
Software engineers know you need more settings than just a username and a password to authenticate yourself against an API. Software engineers know it will take a fair amount of time copying 50 environment variables out of a web-based portal into a DotEnv (.env) file. This is usually why we resorted to pasting things into Slack!!! Despite my hours doing research, I was unable to find that one service that truly resonated with how I wanted environment variable management to go. This included:
Zero-knowledge architecture that places security in the hands of the user, not the platform.
A simple CLI that can be used to update/sync your environment with the cloud in a common DotEnv file format.
A collaboration-first approach that allows team members to quickly share and access application keys/secrets.
As I surveyed the internet for options for the criteria that I just listed, I started to realize that nothing existed. I did happen to find a couple of open source solutions, but these did not cover my entire wishlist and had been long abandoned. I soon realized that if I truly wanted a solution like this, I would have to create it myself. I spent a few days compiling some requirements, built a project plan, and then used Linear to help me break the plan up into tasks and got to work.
SecretStash was born a couple months later.
Why SecretStash is different
When I went about building SecretStash, I wanted to take the approach of building something developers want to use because it fits into their workflow. Again, I know there are other solutions out there, but they are subject to unnecessary enterprise bloat and are built for cloud architects that manage infrastructure, not building the software.
Visibility across environments
SecretStash's organization is broken down into applications and environments. When developers think of work, especially across multiple applications, the application is what groups the work and thus tasks to be done. Assuming you follow modern software practices, you probably have at least two environments: a local development environment and a live, production environment. These environments are very likely to be different in how they are configured, so that's why they are separate entities within your application.
Simple to reference
Sometimes you may not need an entire environment's worth of settings or variables, but just one. SecretStash enables you to simply copy values within the application interface. This brings the convenience of 1Password's interface-first approach into a developer-specific utility. When the "Copy" button is clicked, the encrypted value will be quickly retrieved from the server and then decrypted using a cipher stored in the browser's local storage. The decrypted value will then be applied to the device's clipboard. This ensures the value is never sent over an unencrypted channel and the server maintains a zero-knowledge state.
Secrets are better in groups
Where SecretStash really shines is when its features are used across multiple applications, and different team members. Each organization that you create within SecretStash can invite different sets of teammates to participate in the environment variable management process. The owner of the organization can manage the membership list by adding or removing users as needed. When a user is added to a SecretStash organization, that user will be given the ability to sync their own devices with the service to ensure their environment matches their colleagues. This also includes creating new applications, environments, and even importing their own .env files.
I wanted to solve my own problem
I created SecretStash because our messy onboarding and the small, thoughtless habit of pasting .env files into Slack were creating real security and productivity problems. SecretStash is built to remove that temptation and replace it with a simple, auditable, and developer-friendly workflow that keeps secrets out of chat and repos while making it effortless to get new teammates up and running.
At a glance, SecretStash solves the problem by:
Centralizing secrets in an encrypted store so credentials are never shared in plain text.
Keeping per-environment configurations (dev, staging, prod) separate and clearly labeled.
Enforcing access controls and least-privilege so people only see what they need.
Providing ephemeral, auditable sharing and onboarding templates so new hires get the right variables without interrupting the team.
Integrating with CI/CD, local dev tooling, and team workflows so secrets are injected securely where needed (and never manually copy/pasted).
Offering rotation, audit logs, and alerting so stale or leaked credentials are detected and remediated quickly.
The result is less frantic firefighting, fewer interrupted workdays, and a safer onboarding experience. SecretStash doesn’t aim to be one more barrier — it’s the simple muscle memory replacement for “paste the .env in Slack” so teams can move fast without sacrificing safety. If you’ve ever watched an onboarding session derail because of missing or leaked secrets, SecretStash is the small infrastructure change that prevents that from happening again.
If you think SecretStash would be worth a try, please do! Create an account and find out how easy it can be to keep you and your team secure.
