Node.js: Replace your .env file with this awesome tool at scale

When developing applications, handling sensitive information like API keys, database credentials, and configuration settings is crucial. Ensuring these environment variables are managed securely, efficiently, and in sync across the development lifecycle is a common challenge and let’s face it, .env files don’t cut it anymore, well, for many reasons.

In this article, I discuss the optimal way to manage environment variables for your Node application with Infisical at scale.

What is Infisical?

Infisical, an open-source, end-to-end encrypted secret management platform that you can store environment variables with. It’s fully self-hostable on your own infrastructure, well-documented, and insanely beautiful.

Its Node SDK lets you fetch back environment variables at runtime whether it be in local development or production.

Getting started

Before we can fetch environment variables back into your Node application, you need to add them to a project in Infisical Cloud or in a self-hosted instance of Infisical.

Okay, let’s get started.

First, install the infisical-node package in your project:

$ npm install infisical-node --save

Next, import the SDK and create a client instance with your Infisical Token:

import InfisicalClient from "infisical-node";

const client = new InfisicalClient({
  token: "your_infisical_token"
});

To ensure optimal performance, I’d recommend creating a single instance of the Infisical client and exporting it to be used across your entire app. The reason is because the Node SDK caches every secret and updates it periodically, reducing excessive calls; this built-in caching makes syncing environment variables seamless at scale.

I’d also recommend storing the Infisical Token in a .env file in local development or as the only environment variable in production. This way, you don’t have to hardcode it into your application and can use it to fetch the rest of your environment variables.

Now you can use the client to fetch secrets for your application on demand:

app.get("/", async (req, res) => {
  const name = await client.getSecret("NAME");
  res.send(`Hello! My name is: ${name.secretValue}`);
});

That’s it!

Now whenever your application needs an environment variable, it can request it from Infisical on demand. You’re now able to view all the environment variables for your Node application from one central place and avoid any missing environment variables.

I’d recommend reading into the documentation more to learn more about how to manage environment variables effectively.

But, you’re still using a .env file…

One question came up when I first posted this article being: “If the Infisical Token used to fetch other environment variables is stored in a .env file, then doesn’t that defeat the purpose of the tool?”

The answer is no.

As mentioned, a big point of using the recommended approach is to keep your environment variables in sync across your team. Oftentimes, new environment variables get introduced to a codebase and .env files don’t get updated across the team; as a result, applications crash. The issue compounds when your infrastructure gets big and a problem known as “secret sprawl” emerges. As such, Infisical provides you the ability to centralize your environment variables so you can update them in one place and have them delivered back to your team and infrastructure from development to production. This is different from what a lot of people do which is directly store dozens of environment variables in .env files.

Lastly, from a security perspective, leaking a revokable token is much better than leaking a dozen set of raw environment variables; you avoid leaving any direct traces in source control.

Conclusion

Infisical is an awesome platform to streamline environment variables for you and your team. Its open-source and has a handy Node SDK that can be used to fetch environment variables back to your Node applications on demand.

Comments

[Shreetesh M]

This looks like a pretty useful and convenient tool. Will try it out.

[Edgar Montano]

I wrote an article about utilizing .env in local development manually... however I think this is a great alternative for beginners who rather a GUI interface then managing a plain text file.

Vercel does something similar with environment variables, so its nice to see an open-source alternative to that feature. 👍

[taqi4]

Thanks for sharing, well written and explained could not be better.

[Raiyan Sarker]

BTW, how would you store the infisical token? If you go with hardcoding it, you just published all your secrets. And if you use .env file, infisical would be yet another dependency to manage!

[capcom6]

One way to store the token securely in a Docker or Kubernetes environment is to use secrets.

[Raiyan Sarker]

Then I don't see a need for infisical in the first place!

[BlackMagiq]

It depends on the environment. If you're referring to local development, then I'd store it in a .env file.

You're right that the Infisical Token could be leaked like the environment variables. However, you're forgetting that Infisical helps you always fetch the right set of environment variables to your application whereas if you stored your environment variables directly in a .env file then they may be out-of-sync.

It turns out this becomes even more useful when you have more environments from local development to CI/CD and production. With Infisical, you get to manage your environment variables centrally and know that the right variables will go to the right environment including local development.

This centralization and solution to the problem known as "secret sprawl" is the basis for the entire industry of secret management :)

[Federico "Edo" Granata]

I'm not sure if I'm missing something.
Usually when I work in a team on some software every devs has a local .env with it's own values.
To have something like that in Infiscal do we have to create a separate environment for each developer?