Secrets Manager Migration: My 58-Project Order (Simply Explained)

I found the same password copied into 14 different places

I run a lot of projects. My DTC fashion brand, the tools that keep it running, a stack of client systems, and a few things I built to solve my own problems.

One day I sat down to check how I was storing my passwords and access codes across everything. These are the secret keys that let my software connect to other services, the digital equivalent of house keys.

What I found was a mess. I had 76 separate files holding these keys, spread across 58 projects.

But that wasn't the scary part. The scary part was that the same key showed up in 14 different projects. And it wasn't even named the same way. In one place I called it one thing. In another, something else. Same key, five different spellings.

Here's the real problem. If I needed to change that key, I had no idea how many places it was hiding. If one project got hacked, I couldn't contain the damage, because I didn't even know how far it reached.

That's the actual failure. Not that a key might leak. The failure was not being able to answer a simple question: where does this key live, and what happens if someone steals it.

So I fixed it. Here's how.

Why copying keys everywhere is the real danger

Most people think the nightmare is one file leaking. One file, one project, one bad day.

That's not the nightmare. The nightmare is reuse.

Think of it like using the same key for your house, your car, your office, and your safe deposit box. If someone copies that one key, they don't get into one thing. They get into everything.

That's exactly what I had. One key powered six different apps. If it leaked, all six were compromised at once. And I couldn't lock down just one of them, because they all shared the same key.

The fix is giving every project its own unique key. Like giving every door in your life a different lock. Now if someone steals one key, they get into exactly one room. Nothing else.

Here's the part nervous business owners need to hear. If you've been burned before, your gut says moving all your keys around sounds risky. What if something breaks?

The opposite is true. The move is what shrinks the danger. Before, one leak meant everything. After, one leak means one project, sealed off from the rest.

The tool I picked and why

I looked at a handful of options before committing. I had four hard requirements.

First, it had to connect automatically to where my apps live. I never wanted to manually copy keys into a dashboard again.

Second, every project needed its own unique key, built in. Not something I had to bolt on later.

Third, clean separation between my testing environment and my live environment, so nothing got crossed.

Fourth, it had to work cleanly on my own computer without leaving a loose file lying around that I could accidentally share by mistake.

A tool called Doppler hit all four. It became my single locked cabinet where every key has exactly one home.

I rejected the alternatives. The big cloud providers locked me in and didn't play well across different platforms. Running my own server was more babysitting than I wanted to own. And storing encrypted files in my projects was risky, because if the master password leaked, everything was readable.

For most companies in the $1M to $50M range, Doppler was the cleanest path to one source of truth.

One name per key, so nothing slips through the cracks

The five-spelling mess wasn't an accident. It happened because I never had a rule. So before I moved anything, I wrote one.

The rule is simple. One service gets exactly one name everywhere. No more calling the same key three different things in three different places.

This sounds trivial. It is not. It's the difference between changing a key in one spot versus hunting through 14 projects hoping you caught them all.

To clean it up safely, I built a small program that previewed every change before making it. It showed me exactly what it would rename, I reviewed it, and only then did it run for real. A cleanup that quietly breaks something is worse than the mess it's fixing.

The five-step order that actually closes the danger

This is the part most people get wrong, and it's the part that matters most.

I started from a tough assumption. If a key has been copied into 14 places with no central control, it has probably already leaked somewhere. I just don't know where.

So step one is not to reuse the old key. It's to create a brand new one from scratch, then cancel the old one. The old key gets killed.

This is the whole trick. If you just relocate your old keys, you move the danger with them. Creating fresh keys closes the existing exposure. The cleanup becomes the fix, not a lateral shuffle.

Here's the full order I followed:

Create a fresh new key and cancel the old one. Assume the old one is already compromised.
Put the fresh key into the locked cabinet, under its one correct name.
Connect everything so apps pull the key automatically, each project with its own unique access.
Watch the live app come up clean on the new key. Test the live version and the testing version separately.
Only then delete the old loose files.

The rule that holds it all together: never delete first.

You always keep a working version until the new one is proven. If something goes wrong, you still have a backup and zero downtime.

I ran this across all 58 projects. The order never changed. Every key got replaced, every project got its own unique access, and not one live service went dark during the move.

Making new projects safe automatically

Here's the embarrassing truth about how I got into this mess. I set up every project by hand. New file, copy some keys, name them whatever felt right that day. Multiply that by 58 projects over a few years, and you get 12 names for one key.

The human step created the drift. So I removed the human step.

Now every new project starts already connected to the locked cabinet, with its own unique access and the naming rule baked in from the first line. There's no decision to get wrong, because there's no decision to make.

I'll be honest about the limit. This makes new projects safe by default, but it doesn't automatically fix every weird old project. Those still need a one-time manual pass. But going forward, the mess can't come back, because nobody is naming anything by hand anymore.

If you run a company, you probably already know your keys are scattered. The loose files, the shared keys, the one nobody has changed in two years because nobody knows what would break.

Your real fear isn't the mess. It's the fix. You're worried it breaks your live business.

It doesn't, because you always keep a working version until the new one is proven. Every step is reversible until the moment it's confirmed.

I don't take any of this near a client until I've run it on my own work first. I migrated all 58 of my own projects before I'd offer it to anyone. This isn't a quarter-long project. It's a weekend of focused work, fixed permanently.

The hard part isn't the tools. It's the order and the discipline. That's what I bring.

Ready to bring AI leadership into your company?

I work with a small number of companies at a time. If you're serious about AI, apply to work together and I'll review your application personally.

Apply to Work Together