Managing Secrets in Dev Tools Without Getting Yelled At

Good day geeks! It has been a long time since I dropped my last article, so I thought about coming back with one that would actually be helpful to all sorts of developers.

So what’s this blog about?

If you are reading this, chances are that you have already understood what this is about just by glancing at the title. If not, well that’s what I am writing this about!

We developers have a bad habit of hard-coding secrets into our codebase, just o make sure that the bigger picture works. “It’s on dev, we’ll remove it before it hits our repository”, we say. And then, it turns out that we never really got rid of it. The hardcoded secrets hit our SCM, stays there unnoticed, and ultimately lands in the hands of a malicious actor.

Project onboarding is surely painstaking. We add a teammate, and now we have to send them the .env file – over email / discord / slack / teams, and sometimes even over messages. That’s not a very secure practice. And the problem doesn’t end there. What if we update the OPEN_AI_API_KEY? We would now need to broadcast this to the entire team, and also hand them the secrets. Our servers would need the latest values too, so that we don’t start hitting 500.

But why does it really matter?

You might be wondering that these are just stupid mistakes we developers do. That PR reviews should be more vigilant, that there should be to-and-fro communication whenever something fails. But hey, we are humans, and humans will make mistakes.

AI won’t be so stupid!

True, but what if the person sitting behind that prompts isn’t as experienced? What if they don’t understand how sensitive the contents of a .env are?

If you have read so far, that means I have been successfully able to glue your attention to the screen, and you might be expecting a solution. And in case you are not impressed, let me drop some numbers.

GitGuardian’s The State of Secret Sprawl 2025 quotes a whooping 23 million plaintext secrets detected in GitHub commits, 70% of which are valid and exists till date. And the numbers are still increasing! It shot up to 23.8M in 2024 from the 19.1M in 2023. The potential breaches resulting from such leaks can amount up to $4.4 million, as stated by IBM’s Cost of a Data Breach Report 2025.

As you can see, that’s enough to cripple an organization to its knees.

And now, the solution!

All’s not lost! Problems are why engineers exist in the first place, and this is where I would like to introduce you to Keyshade

Keyshade?

Yep! Keyshade is an open-source secret and configuration management platform, built with a security-first and developer friendly mindset.

But why would I store MY SECRETS somewhere else?

Good question! Well, there are a lot of reasons:

Forget “Hey bro, can you DM me the .env file?”. Keyshade helps you to stay in sync. You upload your configurations to your project, and your entire developer team taps into this project.
Data ownership is a big concern. Keyshade’s approach to solve this problem is unique. It uses public key encryption to store your secrets, which means even keyshade won’t be able to decrypt your secrets. You hold access to the private key, and you decide to share it with your teammates.
Your hosted applications get to use your configurations aswell! You could do so by using their platform-specific integrations or their CLI.
And the best part? It’s a drop-in replacement. You don’t need to change a single line in your codebase to adapt to keyshade. It just works.

They offer a generous free-tier for you to play around with.

Demo time!

Well, enough talking. Let’s see how it actually works. I would be using a simple NextJS application to demonstrate the platform.

First, head over to app.keyshade.xyz and get yourself an account.

You would land up in a page like this:

Here’s a bit on the terminology that keyshade uses:

Workspaces: Consider these as organizations.
Projects: This is what houses your secrets, variables, and environments
Secrets: Sensitive stuff from your .env file. These are always stored in an encrypted form. For example
Variables: Not so sensitive stuff. For example, port number.
Environments: Think of them as development environments. For example, dev, prod, stage, uat, etc.

Install the CLI

Keyshade has it’s dedicated CLI to perform all operations on the platform, and also to use your configurations in your local development environment. We would need that for our demo. Here’s how to install the CLI:

npm i -g @keyshade/cli

Once successful, you should be able to use:

keyshade -V

Setting up a profile

Profiles can be considered as your identity to access keyshade. The possibilities are many, but we will stick to the most basic use.

First stop, head over to Dashboard → Profile Dropdown → Profile → API Keys. Now, hit Add API Key and create a key for yourself. For demo purposes, select all the authorities.

Once generated, you should get an API key. Take a note of that.

Open up your favourite terminal, and issue the following command:

keyshade profile create -n my_key -a  --set-default

Once done, you should be able to see it using:

keyshade profile list

That’s it! You have now successfully logged on to keyshade from your local machine. To verify everything works, try listing your workspaces:

keyshade workspace list

The NextJS project

This is what I have in my project:

In src/app/page.tsx, I have the following content. You can replace yours with mine:

export default function Home() {
  return (
    <div className="bg-white h-screen w-screen text-center text-black flex flex-col">
      <div><span className="font-bold">Secret (NEXT_PUBLIC_API_KEY):span> {process.env.NEXT_PUBLIC_API_KEY}div>
      <div><span className="font-bold">Variable (NEXT_PUBLIC_PORT):span> {process.env.NEXT_PUBLIC_PORT}div>
    div>
  );
}

Things to note:

I don’t have a .env file
We are reading NEXT_PUBLIC_API_KEY and NEXT_PUBLIC_PORT from the environment.

If you fire up this project now using npm run dev, and head over to https://localhost:3000, you would see something like this:

Create a project

To start adding secrets and variables, we would first need to create a project. Head over to Dashboard → Create Project.

Access level: Defines who get to see this project. Since it’s just you who would be seeing it, set it to PRIVATE (default)
Store private key: This is what gives you ownership. Keyshade recommends you to not store your private key with them. Set the slider to off (default)
Environments: We won’t need too many environments, so this is good.

It should ultimately look like this:

After hitting Create Project, you would be greeted with a new dialog.

Copy the command
Head over to your local project
Fire up your terminal
Paste it and hit enter

Wallah! Now you have successfully tied up your local project with keyshade.

Creating secrets and variables

We are all set. The last lego block would be to add in the values for NEXT_PUBLIC_API_KEY and NEXT_PUBLIC_PORT. As the name suggests, the first one would be a secret (secure by nature), and the second is a variable (not so secure)

Adding `NEXT_PUBLIC_API_KEY`

Head over to your project
Click on Secret tab
Click on Add Secret
Set the name as NEXT_PUBLIC_API_KEY
Fill the Note if you want to, i’ll leave it blank
Enter abc as the value for default (the environment we selected when creating the project)
Hit Add Secret

You should see something like this:

Adding `NEXT_PUBLIC_PORT`

The steps are exactly the same, just that you would be adding this one under Variable tab. I’ll be using 1234 as the value for default. Once you are done, you should be able to see this:

Seeing the magic in action

To harness the power of keyshade, we need to use their CLI to run our scripts. So,

npm run dev

would now become

keyshade run -- npm run dev

You should see this in your terminal:

From the output, note that keyshade has fetched the secret and variable that we created in the project before:

ℹ️ INFO: Fetched 2 configurations (1 secrets, 1 variables)

So now, when you head over to https://localhost:3000, you get to see the actual values for your configurations!

Closing thoughts

I’m sure you might have found this article useful, especially if you and your team have been struggling with secrets management. Keyshade covers up for most of the problems we developers face in our day-to-day jobs.

When should you not use keyshade?

You might have got the intuition that this platform is pretty useless if you are a solo developer, working on a project locally. Keyshade also isn’t helpful if your are building CLI applications, or mobile applications, or anything that would be running on an external environment (the client’s device).

Source link