DEV Community: Doug Niccum

We kept leaking .env files across environments—here’s how I solved it

Doug Niccum — Thu, 25 Jun 2026 13:00:00 +0000

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.

Stop sharing your variables in Slack

Doug Niccum — Wed, 17 Jun 2026 03:58:42 +0000

Let's be real with ourselves for a moment: we don't like to be onboarded. Whether you are the person who is responsible for onboarding new employees, or you yourself are the one being onboarded into a new role; it's a painful process.

Onboarding sucks

The delicate balance of providing enough information so an employee feels informed while not having their brain explode from too much data can feel impossible at times. When I onboarded at Henry Schein One this past January, I cannot even begin to describe the stress and anxiety that came along with my first few days. Learning everybody's name, their role, who they report to, who reports to me, it was a lot. I do not mean to slight my co-workers in any way. They did a great job and my boss Jen provided that guiding hand when it was necessary. But despite all the back and forth of this process, things can be lost in translation. What's worse: this is just the human side of onboarding.

Minimum viable setup

The part that can be even more stressful than remembering your new computer password as part of your onboarding journey is configuring your development environment (queue the "dun dun duuuunnnn" sound effects). Let's assume for a second you are lucky enough to have decent documentation and tutorials that have been written by someone else in your organization to aid in your setup. You are still likely going to be missing some key pieces of information or files to complete your environment. This could be a backup of the database, API keys, OAuth token pairs, or SSL certificates. Whatever it is, handing these things off to people can be hard. So what do we usually do? Copy and paste or drag and drop these files and environment variables into the team's Slack channel. It's quick, it's easy, and at least it's more secure than sending them via email. Or is it?

Collaboration tools are a crutch

We are all guilty of using collaboration tools like Slack and Teams to share information with our teammates that is sensitive. Again, this could be a password, API key, or even an RSA secret. Everything in the workplace is about speed. Gotta get this done fast, send that faster, are you using AI like you should to code this feature faster? It's an endless cycle. But are we really that safe? GitGuardian’s State of Secrets Sprawl 2025 says 38% of incidents in collaboration tools were classified as highly critical or urgent, higher than in code repositories. Its 2026 report says ~28% of incidents now originate outside source code in tools like Slack, Jira, and Confluence, and more than half of those collaboration-tool incidents were critical. So despite the bullet-proof security provided to us by the folks in the IT closet and the guarantees from the guys at Salesforce (Slack is owned by Salesforce in case you didn't know 😜) and Microsoft, we are still susceptible to breaches. All because we need to share something quick!

The usual suspects just didn't cut it

So if it's soo easy to compromise these pieces of information, why don't we do it more often? Other than laziness (I can say that because I'm guilty of it too), credential storing processes usually take time to set up and maintain, not to mention the DX (developer experience) is garbage. Sure, there is AWS Secrets Manager and HashiCorp has their solution. These are all viable, but again, their flexibility is also what makes them difficult for most developers. When retrieving a list of secrets, everything is returned in JSON. Most frameworks do not leverage JSON as their method of secret management. Configuration and customization: absolutely. But the source of truth is usually a DotEnv file or .env located in the code base that needs to be written and formated in a special way.

I didn't like the options I had in front of me. For a while I used some self-hosted open source tools, and they worked. But as soon as the maintainer abandons the project and the application goes into deprecation hell, you are screwed. Like I said above, there are enterprise solutions. However, these require some time to set up, can be insanely costly even for a small implementation, and can lack the developer experience that I also referenced. This is why I wanted to come up with my solution, something that I knew would answer this question that I knew was important.

This is why I developed SecretStash.

My own solution

SecretStash is a developer-first platform that helps developers securely manage and share environment variables across teams, applications, and environments. This can easily and quickly be done by installing one of the first-party CLI packages and begin interacting with the zero-knowledge cloud service; all within about 1-2 minutes. This ensures your credentials are securely stored away and cannot be retrieved, even in the event of a data breach. You can then invite your teammates to reference the same variables across environments to ensure you are all in sync.

Click here to get started for free.

It's hard, I get it

Being a developer myself, I know how hard secret management can be. These hardships double and even triple when you begin to look at how the CI / CD process will be impacted by rotating tokens. These things should be easy, or at least that's what I thought. But after some research and failed open source projects, I came to the tough realization that I was going to have to solve this "secret sharing issue" myself. SecretStash was the result.

So in the future, stop uploading your .env files into Slack or Teams, just use SecretStash. Your IT team will appreciate the added security as well.

Staying vigilant in the AI coding gold rush: from generation to delivery

Doug Niccum — Fri, 12 Jun 2026 22:10:34 +0000

Being developers and managers with boots on the ground, we owe it to our customers and users to be the voice of reason and stability when deploying AI-generated assets. Despite what is being asked of us from leadership.

For those who haven't worked inside the corporate world, the continuous tango of "look at metrics, adjust; look at metrics, adjust" is a never-ending cycle that we, as mid-level managers and directors, must both endure and champion for our reports. These metrics can be used to analyze almost anything about our personal performance and that of our teams. As the organizations we work for grow larger and more complex, context and awareness (of the application and situation) usually diminish. This awareness is replaced by a focus on delivering features and meeting financial and velocity goals.

🤔
What's ironic is "context" is one of the pillars that quality AI prompts and commands are built on. The more it knows, the better the result.

You might be asking yourself, "What metrics am I talking about?" I'm referring to productivity metrics, DORA metrics, but more specifically: lines of code generated. It would seem logical to equate lines of code written with productivity, right? The more code written, the more is delivered to the customer—making the application better, allowing more features to be sold, which means more money. Again, on the surface this makes sense and has been a point of emphasis in my experience. But the more I think about it, just because we are writing more code with AI are we actually more productive? I am not entirely convinced.

Let's dive into it.

A quick story

Recently I have attended a series of management meetings where the subject of AI metrics and its usage have been a topic of discussion. Further debates about which models work in which situation, and token-spend among others dominate the forum. Likely a pretty standard "corporate AI" meeting. However one point of discussion always seems to surface again and again: usage. The overwhelming common sentiment between each meeting is the ever-increasing lines of code being generated by our agents. The accompanying narrative being paired with this analysis is:

Our teams have never been more productive. We are writing more code than we ever have and we are shipping more features than any other point in the company's history.

Sounds like a pretty successful and celebratory conclusion eh? Initially I thought so. Code makes our applications function, functions create features, features means more money; so more code must be good right? But the more I got to thinking, there are other elements that go into code and features. Things like code reviews, security audits, unit tests, and so on. Technically you could use AI to perform these tasks, but (other than the unit tests) you really shouldn't. These things take time, more time to do it right, and even more time when you include multiple people in the process.

I recognize I am just one manager/developer, one lowly manager/developer. I also recognize that my opinion is just one small grain of sand in the desert that is the AI efficiency discussion. But I cannot help my skepticism of these MASSIVE gains surrounding the deployment of AI in software development practices.

More isn't always better

As a small disclaimer, I am basing a bulk of my argument with the assumption your company is following standard development processes, like writing unit tests, performing code reviews and such. If you aren't doing these things and just deploying AI-generated code to production without even the slightest review, then God's speed to you. Hope you have good insurance when your data gets ransomed.

Now let's continue.

When we leverage AI to rapidly generate code, it's hard to not be in awe of the speed and accuracy it is able to do so. Some outlets are reporting developers are seeing as much as a 55% percent increase of productivity, with a reduction of lead time for tasks by as much as half. More often than not, the code that is generated is pretty accurate and clean; especially if your agent guidelines are clear and actionable. The magic of typing a prompt and getting a working output will inevitably lull you into this result-driven comatose. It certainly has for me. The ease and luxury provided to you by your coding agent of choice makes it very easy to simply bypass the processes and protocols you would normally follow for your own code: unit tests, user-acceptance testing, quality assurance, security analysis, and so on. If the code works, why would I change it and why would I test it?

The "mechanism of structural decay"

If you have worked with AI long enough, you are likely to notice the trend of: write, create, write, append, write, refactor. The agent's immediate response to a prompt is to write code, regardless if you need it to or not. According to a study done by GitClear and Sonar citing:

an 8-fold increase in the frequency of code blocks containing five or more duplicated lines, confirming a significant decline in code reuse. Furthermore, 2024 was the first year where the number of copy/pasted lines exceeded the number of moved (refactored) lines.

What this crazy statistic ultimately points to is ever-growing code bases that are discarding the DRY (Do not Repeat Yourself) principles that were drilled into us as junior developers. What this also means is our code is growing larger and thus reducing efficiency and long-term maintainability. This quote from Sonar's article says it beautifully, "structural debt arises because LLMs prioritize local functional correctness over global architectural coherence and long-term maintainability." So despite the numerous additions and augmentations to our code, we could be only making it worse and thus damning our application to the pits of volatility.

Instability at the cost of insatiable productivity

According to a Google 2025 DORA Report, the folks over at Google found a 90% increase in AI-generated code also brought about a 9% increase in reported bugs and over a 150% increase in pull/merge request size. If you take these numbers at face value, there are a few big things that should jump out at you:

Our code bases are growing at an alarming rate. I recently reviewed a merge request in GitLab that included 388 lines of net new code (not changes or deletions). Let's assume the developer of this merge request does this four more times over the course of a week. In a month, this means a single developer will have introduced 13,580 net new lines of code into the project, in a single month. If that amount of new code is being written and merged into the repository at that rate, I would have some genuine concerns over the amount of duplicated code, and code that is just unnecessary.

The number of bugs will grow as well. On the surface, a 9% increase of reported bugs does sound like a lot, but I believe it is so much worse than that. All developers know all bugs are not created equal. They require time to analyze and troubleshoot, and even more time to fix regardless if you use AI or not. As the code base grows, the introduction of bugs is inevitable no matter the amount of testing or QA is done to prevent them (unless your company's name is Linear. Those guys know how to produce a clean product; props). But I digress.

Let's go back to the example we were using above. Let's assume for every three merge requests, one bug is introduced. In addition to this, another bug is introduced for every 5,000 lines of code. This means, keeping to the cadence of this developer's AI-powered productivity, in one month, our developer would have introduced around eight bugs. Now, as I was hinting at earlier, these issues could be very simple and depending your CI/CD process, a resolution could be deployed in a matter of minutes. No harm, no foul right? However some of these issues could be debilitating outages, causing lost progress and lost revenue for your business; all from a single developer.

🤨
Please know, the numbers that I used above are not actual numbers from me or any of my team. They are simply just examples.

This code needs to be tested and reviewed. If you are following prototypical development processes, we are probably aligned in the fact of code should be tested by both a human (QA) and a machine (automated unit/feature testing). All of these things takes time, even testing that has been automated. Depending on the size of the code base and testing coverage you have for your application, these tests take time to run. And if you are running these tests on dedicated resources, they also cost money. Code reviews by humans also cost money. Yes, it takes time for another developer to review, test, and smoke check the code. This has a cost. But what people don't think about is the productivity that is also lost due to that developer not coding. So in essence, every code review costs twice of what a developer costs during that same timeframe.

The cost of doing it right

For those of us in the tech and software industry, you are likely aware of the meme: "You can have it good, fast, or cheap, but it cannot be all three." Quality, at speed, comes with a cost. This also applies to testing, but even more so when it comes to AI generated code.

A 2025 study showed that senior engineers spend an average of 4.3 minutes evaluating AI-generated suggestions, versus 1.2 minutes for code written by humans. Meanwhile, teams that rely heavily on AI are delivering substantially more pull requests. Faros AI examined data from over 10,000 developers and found a 98% rise in PR volume. Consequently, PR review time increased by 91%, even though the code generation process itself became faster. A Qodo survey found that 68% of senior engineers report quality improvements from AI, but only 26% would ship AI-generated code without review (I'm surprised its that high).

So lets play this out. Lets assume you have a development team that makes the following hourly rates:

Junior/intermediate developers: about $50 per hour (or $0.83 per minute)
Mid-level developers: about $100 per hour (or $1.67 per minute)
Senior/lead developers or architects: about $180 per hour (or $3.00 per minute)

If you were to have these developers review human code at their hourly rate it would cost:

Junior/intermediate developers: about $1 per code review
Mid-level developers: about: $2 per code review
Senior/lead developers or architects: $3.60 per code review

If these same developers were to review AI-written code at their same hourly rate, it would cost:

Junior/intermediate developers: about $3.57 per code review
Mid-level developers: about: $7.01 per code review
Senior/lead developers or architects: $15.48 per code review

It is worth mentioning these numbers do not account for the lost productivity of the code reviewer as well, much like I mentioned above. Another item that is worth considering is the time added to timelines and lead times for features that can increase your company's bottom line. You will also need to keep an eye on the code bloat and potential regressions, as these can obviously affect these numbers too.

When you think about it...

Keep in mind, the numbers that I have provided are very much an approximation and estimate of your team's productivity. There are a fair amount of other caveats like language, code size, complexity, current technical debt, etc. But I think you get my point when you start to think of productivity and output in dollars and cents. As I also mentioned above, I myself have seen the benefits in my own work and undoubtedly you have as well. But with the security risks, bloat, and code duplication AI usage can introduce, AND you combine that with the increased code review time and associated costs with the potential delays and regressions; is it worth it?

As leaders, we have a direct responsibility to make decisions, and to put our teams into the best possible places/opportunities to succeed. This includes selecting tools and services to use. However when we are being pushed by our bosses and their bosses to use AI to optimize our work, I believe we owe it to our reports and the companies that we represent to at least take a second and really think about the outcomes of our decisions. We are very likely to not see the long-term effects for quite some time, but months and even years from now, are our AI-driven decisions going to really make our work better? Probably, but I am highly skeptical it will be this "slam dunk" we are being told it will be.

To put a bow on it

The AI coding gold rush is real — but so are the risks of mistaking generation for delivery. As organizations scale, context and awareness often get compressed into simplistic metrics. Lines of code and raw output from AI tools can feel like progress, but they are a poor proxy for actual customer value, reliability, and long-term maintainability.

To stay vigilant, treat AI as an amplifier, not a replacement, for disciplined software delivery. Anchor decisions in outcome-oriented metrics (customer impact, lead time, MTTR, change-failure rate), maintain strong feedback loops, and preserve human oversight across design, review, and deployment. Invest in observability, automated testing, security scanning, and provenance tracking so generated code is verifiable and safe to ship. Foster a culture that rewards quality, learning, and shared context—document assumptions, keep prompts and models auditable, and run blameless postmortems when things go wrong.

Practical steps:

Prioritize outcome metrics over LOC; use DORA metrics thoughtfully and complement them with product and user metrics.
Require tests, code review, and CI/CD for all AI-generated code before it reaches production.
Capture context: rich prompts, architectural notes, and intent annotations so AI output is traceable and maintainable.
Automate safety checks (security, license, performance) and monitor runtime behavior post-deploy.
Train teams on effective prompting, model limits, and how to validate AI outputs.

In short: harness AI to accelerate engineering, but measure and manage what actually matters—delivery, quality, and customer value. Vigilance, not hype, will determine who benefits from this gold rush.