.env and the Consequences of Its Usage

.env and the Consequences of Its Usage

Daily short news for you
  • For a long time, I have been thinking about how to increase brand presence, as well as users for the blog. After much contemplation, it seems the only way is to share on social media or hope they seek it out, until...

    Wearing this shirt means no more worries about traffic jams, the more crowded it gets, the more fun it is because hundreds of eyes are watching 🤓

    (It really works, you know 🤭)

    » Read more
  • A cycle of developing many projects is quite interesting. Summarized in 3 steps: See something complex -> Simplify it -> Add features until it becomes complex again... -> Back to a new loop.

    Why is that? Let me give you 2 examples to illustrate.

    Markdown was created with the aim of producing a plain text format that is "easy to write, easy to read, and easy to convert into something like HTML." At that time, no one had the patience to sit and write while also adding formatting for how the text displayed on the web. Yet now, people are "stuffing" or creating variations based on markdown to add so many new formats that… they can’t even remember all the syntax.

    React is also an example. Since the time of PHP, there has been a desire to create something that clearly separates the user interface from the core logic processing of applications into two distinct parts for better readability and writing. The result is that UI/UX libraries have developed very robustly, providing excellent user interaction, while the application logic resides on a separate server. The duo of Front-end and Back-end emerged from this, with the indispensable REST API waiter. Yet now, React doesn’t look much different from PHP, leading to Vue, Svelte... all converging back to a single point.

    However, the loop is not bad; on the contrary, this loop is more about evolution than "regression." Sometimes, it creates something good from something old, and people rely on that goodness to continue the loop. In other words, it’s about distilling the essence little by little 😁

    » Read more
  • Alongside the official projects, I occasionally see "side" projects aimed at optimizing or improving the language in some aspects. For example, nature-lang/nature is a project focused on enhancing Go, introducing some changes to make using Go more user-friendly.

    Looking back, it resembles JavaScript quite a bit 😆

    » Read more

Issue

There's advice that any configuration that can change depending on the deployment environment should be turned into environment variables (OS Environment). Typically, we use a .env file to store these variables. The .env file is usually placed in .gitignore and is only created when deploying the application to the Internet environment or running it locally. A .env file may look like this:

DB_HOST=localhost
DB_PORT=5432
DB_USER=postgres
DB_PASSWORD=password
...

However, sometimes we need more flexibility with .env, where it can change based on an environment variable passed in. For example, it could change through the NODE_ENV variable. In that case, we have .env.local, .env.development, .env.production, and when running, you only need NODE_ENV=local node index.js, and .env.local will be automatically used.

Another solution besides using .env is to store configuration in any file format such as JavaScript, JSON, yml... using it is similar to .env, but it allows nested configurations for clearer configuration partitioning. However, both methods still create files to store environment variables.

Currently, I'm still using .env in some of my projects, and I can't deny its convenience. However, .env is not without its drawbacks.

Firstly, there's the issue of security. .env files are no different from unencrypted text files, so anyone can read them. People often copy or send .env files directly to each other through messaging apps, potentially exposing or intentionally leaking the content.

Secondly, .env files don't have access control, meaning anyone with permission can access them. This inadvertently reveals the content of all variables. For example, if a fellow developer requests permission to start a project locally pointing to the staging environment, we may have to send the entire .env content for the staging environment.

Since .env is considered sensitive, it's usually not committed to Git. This makes it difficult to track changes to variables in .env through this tool. Instead, we often add a file like .env.example to store the possible values in .env. However, this approach only provides insight into the structure of .env without managing its content. Adding a new variable and forgetting to update it in other environment files can lead to application errors.

It can be disastrous if we accidentally commit .env to the project or forget to exclude it in .dockerignore. This is a human error but is one of the issues that can cause security leaks if not detected early.

So, do we have a better solution?

Alternative to Traditional .env

With the existing advantages mentioned above, we naturally have many alternative solutions to efficiently manage environment variables. One such solution is Azure Secrets Manager or Vault. However, these tools seem more suitable for complex configurations and future scalability. If you need a simpler tool focused on managing security variables, Infisical is a much easier and time-saving solution.

Infisical is an open-source end-to-end encryption solution that can be used to synchronize environment variables within a team and infrastructure. By using Infisical, we can address most of the issues mentioned at the beginning of the article.

The source code of Infisical can be found at Infisical Github, and we can deploy our own server using various methods such as Docker, AWS, DigitalOcean, etc. Alternatively, Infisical provides a completely free Cloud service with some limitations. Interested readers can sign up at Infisical Signup.

Infisical

Infisical supports many Cloud services like AWS, Vercel, Netlify, or Frameworks/Libraries like React, Vue, SvelteKit, etc.

For example, in Node.js, after adding environment variables to Infisical, you can start a Node.js project by:

$ infisical init
$ infisical run -- npm start

At this point, environment variables will be passed into the Node application.

To see a full list of integrations and usage in other projects, readers can check Infisical Integrations.

Conclusion

.env is one of the ways to manage environment variables when deploying applications to different environments. However, the approach via .env is somewhat outdated and can lead to various issues. Infisical can be considered a simple and more efficient solution compared to Vault or Azure Secrets Manager.

Premium
Hello

5 profound lessons

Every product comes with stories. The success of others is an inspiration for many to follow. 5 lessons learned have changed me forever. How about you? Click now!

Every product comes with stories. The success of others is an inspiration for many to follow. 5 lessons learned have changed me forever. How about you? Click now!

View all

Subscribe to receive new article notifications

or
* The summary newsletter is sent every 1-2 weeks, cancel anytime.

Comments (1)

Leave a comment...
Avatar
Ẩn danh1 year ago

Hay lắm a ơi. Mong a ra tiếp những bài viết hữu ích. Cảm ơn a

Reply
Avatar
Xuân Hoài Tống1 year ago

Cảm ơn e, nhớ ghé thăm blog thường xuyên nhé :D